ALSO NOCHMAL

[Harlequin]

Yerf!

die Tatsache, dass die Formulare aus 1000 Feldern und mehr bestehen können ist kein Designfehler.

Es ist eine Software, keine poppelige Homepage.

Sowas sollte hier extra erwähnt werden, ansonsten geht man immer von ner 0-8/15 Webseite aus...

U.a. kann man damit Projekte verwalten. Der User kann SELBER angeben was für Felder er zu den Vorgängen sehen will - bis zu 50. Will er alle 50 sehen, dazu noch ein Vorgang der selbst 100 Untervorgänge hat sind wir sofort bei 5000 Feldern. Und davon sind einige Textfelder oder Areas.

DIese werden vermutlich per serverseitigem Automatismus erstellt, richtig?

Es kann mir keine einreden dass es nicht besser wäre wenn man auf html_special_chars verzichten könnte, ein Grund warum ich auf der Suche nach Alternativen bin ... wenn auch mit der Vermutung das ich da dann andere Steuerzeichen ersetzen muss und de fato nix gewonnen hab ... egal, eine Erfahrung wär's trotzdem.

Kenn mich jetzt mit PHP nicht aus, aber das bischen Überprüfung, was man gegen Code-Injection braucht sollte sich doch problemlos mit in die Automatismen der Formularerstellung integrieren lassen.

2. Grund.
   On-the-fly Quelltextänderung - sehr brisant wenn ihr mich fragt. Es ist, da das System einen Login verlangt nicht "einfach" möglich das System von außen mit Schrott zu füttern.
   Mit der Quelltext-Änderung im Browser via FireBug (u.ä.) ist das leicht möglich - und nach wie vor bin ich mir nicht im klaren wie ich mich dagegen vernünftig/effizient schützen kann.

Dies geht *nur* durch serverseitiges Prüfen der Eingaben. Ansonsten darf man keine Webanwendung verwenden sondern muss seinen eigenen Client schreiben (den man aber auch per Hex-Editor hacken könnte...)

Ein Szenario (siehe unten), welches man im übrigen beliebig verkomplizieren kann, sodass der Satz "Dann prüf doch ob die Daten valide sind" nicht mehr in vernünftigen Maßen erreicht werden kann.

Dann ist das Konzept falsch (s. unten).

Die Personenverwaltung, Ändern von Personendaten:

• In der DB sind 3 Angestellte, A, B und C, mit Pers_ID 1, 2, 3.

ok

• User öffnet Person B (Pers_ID = 2)

ok

• User "hacked" HTML Code und setzt Pers_ID (hidden-field) von 2 auf 3

Wieso steht die in einem Hidden-feld und nicht in der Session?

• submit -> falscher Datensatz wird geändert

selber schuld... siehe oben

Lösung: Vergleich von geladenem und empfangenem Datensatz - ja, kein Problem bei einem STATISCHEN hidden-field, und einem Datensatz.

Bei festem Wert: in der Session spoeichern, die kann der User nicht ändern
Bei variablen Werten: die Rückgabe des Users mit den erlaubten Werten, die man sich in der Session merkt abgleichen

Was aber wenn's mehrere hidden-fields sind, mehrere Datensätze und evtl. diese hidden-fields durch User-Interaktion VALIDE geändert werden. Dann reicht auch ein primitiver servereitiger Check nicht mehr - dann ist's keine Fleißarbeit mehr.

Hier muss halt ein entsprechendes Konzept her, wie man die Rückgabewerte valide hält, die Session kann dabei helfen, notfalls ein gegencheck mit Werten aus der datenbank (Berechtigungen nochmals prüfen usw.)

Ähnlich Problem tun sich bei read-only Feldern auf, die man plötzlich editieren kann.

Werte die der User eh nicht ändern können soll braucht man auch nicht wieder aus der Form lesen.

Was würdet ihr sagen, wenn man in eurem Betriebssystem einfach mal rechts-klicket auf einen gesperrten Button, und schwupps ist er klickbar.

Ich bleib dabei, das ist eine maßive Schwachstelle von HTML, das der USER das Programmverhalten beeinträchtigen kann.

Tjo... ich weiß auch nicht wer auf die Idee kam, man müsse alles über einen Browser erledigen können, wofür man vorher immer ne spezielle Anwendung installieren musste... HTML ist eben für *Text* da und nicht für GUIs, dann würde es ja HGML heißen...

Ist denn keiner meiner Meinung - sollte sowas tatsächlich erwünscht sein?

In HTML ist es erwünscht, wenn man damit eine Applikation schreiben will muss man damit zurechtkommen (das zustandslose HTTP ist ja eine weitere Hürde...)

Das bedeutet jedenfalls einen ERHEBLICHEN Mehraufwand beim Erstellen von Web-Applikationen, und ich glaube nicht dass das jeder Hersteller berücksichtigt hat.

Wer eine Webaplikation haben will muss den Mehraufwand in kauf nehmen... ist halt so...

Also, kennt jemand eine Alternative zum HTML-Forms, neben XForms und Flash?

Java-Applets.

Gruß,

Harlequin