<fom> mit HTML/Flash/???

[dr.colossos]

Hi,

ich möchte auf einer Web-Seite Formulare einsetzen.

Kein großes Ding ... meint man.

HTML bringt ja schon so einige Nachteile mit, z.B. keine Sonderzeichen (<>") in Eingabefeldern oder in anderen HTML-Elementen - klar, muss man halt ersetzen.

Es gibt noch andere Probleme, wie z.B. das Browser-Problem ... egal.

Ein SEHR großes Problem dass mir die Tage aufgefallen ist, ist die Firebug-Extension des Firefox, mit dem man lustig die ganze Seite umbauen kann. D.h. der User kann hidden-Fields löschen die man eigentlich für die Steuerung der Seite bräuchte, den Namen/Value des Submit-Buttons ändern, letzendlich das ganze Ding kaputt machen, und mein PHP/DB-Backend mit Schrott zu müllen.

Nun frage ich mich, wie kann ich mich gegen sowas schützen. Ich könnte die POST/GET Rückgaben validieren, ob das Formular so angekommen ist, wie es sein soll ... ooops, aber was ist wenn der Firebug-User nun auch noch das target und die method des forms geändert hat ... naja ... ihr seht, so unbedenklich ist das nicht.

Die Lösung?

• Flash ... kenn ich garnicht, weis aber seit ein paar Minuten dass man damit auch Formulare erstellen kann.

• ??? Gibt's noch andere Techniken um Formulare zu erstellen? Am besten wär's natürlich wenn ich damit auf das bestehende PHP-Backend zugreifen könnte, d.h. nur die GUI neu gemacht wird.

Vielen Dank für jeglich Inspiration

[dr.colossos]

Fataler-Typo, sorry.

Meinte natürlich <form> statt <fom>.

[dr.colossos]

Hi,

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

Es ist eine Software, keine poppelige Homepage.

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.

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.

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.

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.

Die Personenverwaltung, Ändern von Personendaten:

• In der DB sind 3 Angestellte, A, B und C, mit Pers_ID 1, 2, 3.
• User öffnet Person B (Pers_ID = 2)
• User "hacked" HTML Code und setzt Pers_ID (hidden-field) von 2 auf 3
• submit -> falscher Datensatz wird geändert
  Lösung: Vergleich von geladenem und empfangenem Datensatz - ja, kein Problem bei einem STATISCHEN hidden-field, und einem Datensatz.

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.

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

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.

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

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

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

Danke

[glan]

Hallo,
ich hab mir dein Ganzes Posting jetzt nicht erst durchgelesen, aber ich habe einen Tipp:
wxWidgets ist ursprünglich für C++ eine Window-Bibliothek, aber das gibbet jetzt auch für PHP: wxPHP.

MfG

[dr.colossos]

Danke für die Antworten.

@Harlequin: Ja, natürlich ist die SESSION den hidden-fields vorzuziehen, war auch nur ein Beispiel mit der Personen-Verwaltung.

Das mit den Zufallswerten klingt auch ganz gut, hab ich auch schon dran gedacht ... würde auch Requests von außen verhindern.

Aber nochmal dazu, dass ich mittels anderen Formularen beliebige Daten an das PHP-Script schicken kann.

Dazu ist eine gültige Session nötig, und deren Name ... wie käme man da dran um Requests über ein Fremdformular einzuschleusen?

Danke

[Harlequin]

Yerf!

Aber nochmal dazu, dass ich mittels anderen Formularen beliebige Daten an das PHP-Script schicken kann.

Dazu ist eine gültige Session nötig, und deren Name ... wie käme man da dran um Requests über ein Fremdformular einzuschleusen?

Man meldet sich an das System an und schaut nach, was im Session-Cookie steht. Diese Anmeldung muss natürlich nicht aus einem Browser heraus erfolgen, sondern kann auch von einem beliebigen selbstgeschriebenen Programm kommen, dass das HTTP-Protokoll beherrscht.

Gruß,

Harlequin

[dr.colossos]

Hi,

... mmmh, stimmt, hab ich gestern erst gesehen, hehe.

Ich brauch mehr Schlaf, hehe.

Aber wenn ich schau wo der Request herkommt (ich bewege mich auf unbekannterem Terrain), dann kann ich sowas ja unterbinden.

Werd mal ein bisschen rum testen.

Vielen Dank, freu mich über mehr!

[Harlequin]

Yerf!

Aber wenn ich schau wo der Request herkommt (ich bewege mich auf unbekannterem Terrain), dann kann ich sowas ja unterbinden.

Damit wäre ich vorsichtig... es gibt keinen verlässlichen Weg die Herkunft von Daten zu prüfen (Der zufällige Schlüssel der den Request identifizieren soll hilft hier nicht, da dieser ja ebenfalls von einem Tool gelesen und wiederverwendet werden kann). Eine Serverseitige Prüfung auf Gültigkeit der Daten ist leider das einzige was einem bleibt. Das ist aufwändig, aber eben der preis, den man zahlen muss, wenn die Anwendung *einfach so* in jedem Browser laufen können soll.

Ein Java-Applet wäre schwieriger zu knacken, allerdings ist auch das nicht ganz unmöglich (man könnte sich den Code per decompiler anschauen und die Kommunikation mit dem Server nachbauen). Außerdem setzt dies ein Java-Plugin beim User voraus.

Gruß,

Harlequin

[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

[_david]

Bei festem Wert: in der Session spoeichern, die kann der User nicht ändern

Was passiert denn, wenn der Benutzer verschiedene Datensätze in Tabs aufmacht?

[Harlequin]

Yerf!

Bei festem Wert: in der Session spoeichern, die kann der User nicht ändern
Was passiert denn, wenn der Benutzer verschiedene Datensätze in Tabs aufmacht?

Man könnte die Werte mit einem zufälligem Wert für den entsprechenden Request kennzeichnen um diese dann wieder zuordnen zu können. Alternativ ein Konzept wie es z.B. .NET verwendet und Daten in einem verschlüsseltem hidden-Feld ablegen.

Gruß,

Harlequin

[_david]

Man könnte die Werte mit einem zufälligem Wert für den entsprechenden Request kennzeichnen um diese dann wieder zuordnen zu können.

Das klingt schlüssig.

Alternativ ein Konzept wie es z.B. .NET verwendet und Daten in einem verschlüsseltem hidden-Feld ablegen.

Aber sobald der Nutzer hinter die Verschlüsselung käme, könnte er auch wieder manipulieren. Da finde ich die Methode mit dem Zufallswert schöner.

Gruß,
David

[Harlequin]

Yerf!

Alternativ ein Konzept wie es z.B. .NET verwendet und Daten in einem verschlüsseltem hidden-Feld ablegen.
Aber sobald der Nutzer hinter die Verschlüsselung käme, könnte er auch wieder manipulieren. Da finde ich die Methode mit dem Zufallswert schöner.

Ne vernünftige asynchrone Verschlüsselung mit serverseitig zufällig gewähltem (und gespeichertem) private Key sollte eigentlich sicher sein. (Keine Ahnung wie es Microsoft in .NET macht...)

Gruß,

Harlequin

[_david]

Die Personenverwaltung, Ändern von Personendaten:

• In der DB sind 3 Angestellte, A, B und C, mit Pers_ID 1, 2, 3.
• User öffnet Person B (Pers_ID = 2)
• User "hacked" HTML Code und setzt Pers_ID (hidden-field) von 2 auf 3
• submit -> falscher Datensatz wird geändert
  Lösung: Vergleich von geladenem und empfangenem Datensatz - ja, kein Problem bei einem STATISCHEN hidden-field, und einem Datensatz.

Lösung: Überprüfen, ob der User den Datensatz mit der Id "3" überhaupt verändern darf.

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

Du scheinst nicht zu begreifen, dass es vollkommen egal ist, ob der User mittels Firebug oder einer sonstigen Technik Dein Formular ändern kann. Er kann es einfach nach eigenem Gusto nachbauen. Hat er bei Dir eine gültige Session, wird auch sein Formular von Deiner serverseitigen Technik angenommen.

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

Ja und Ja. Validierung von Formulardaten ist ein MUSS und wird viel zu oft vernachlässigt. Wenn Du komplexe Formulare baust, brauchst Du auch komplexe Überprüfung. Warum verwendest Du nicht ein entsprechendes Framework oder fertige Klassen? Schau doch mal bei PEAR nach.

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

PDF-Formulare. Achtung: Das war ein Scherz! Und ändert nichts an Deiner Grundproblematik. Denn auch in diesem Fall kann jemand sein eigenes HTML-Formular (jaja) bauen, die Inputs mit den selben Feldnamen versehen und an Deinen Server schicken.

Gruß, David

[Johannes Zeller]

Hallo,

es mag sein, dass du mir jetzt vorwerfen wirst, dass ich dein Problem nicht verstehe. Dem ist nicht so, ich verstehe sehr gut, was du meinst - aber dein Hauptproblem liegt darin, dass du einen konzeptionellen Fehler hast, weil du versucht mit Web-Formularen wie bei einer "normalen" Anwendungssoftware zu arbeiten.

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

Es ist eine Software, keine poppelige Homepage.

Im Grunde macht es keinen wirklichen Unterschied, der Aufbau und die Anforderungen sind die gleichen. Lediglich die Komplexität ist bei dir anscheinend höher als bei den meisten Projekten.

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.

Doch, ist es. FireBug oder ähnliche Tools tun nichts, was der Benutzer nicht auch von Hand könnte. Um das zu Verstehen hilft es, sich den Vorgang der Formularverarbeitung einmal genauer anzusehen.

Dein Script, dass die Daten verarbeitet, erhält vom Client diese Daten geschickt. Es gibt dabei keine Möglichkeit, zu erkennen ob der Besucher die Daten von Hand eingetippt oder die Daten vom Browser oder von einem anderen Programm kommen, da alle Indikatoren beliebig gefälscht werden können.

Du musst also in deinem Script die Benutzereingabe auf jeden Fall überprüfen.

Dein Formular dient eigentlich nur dazu, dem Client zu sagen welche Daten und in welcher Form und an welches Script er sie schicken soll. Um es dem Benutzer bequemer zu machen, erzeugen normale Browser aus dem Formular eine Eingabemaske, die es dem Benutzer erlauben, die Daten einzugeben ohne sich um die technischen Details zu kümmern. Ob das auf der Client-Seite tatsächlich so oder komplett anders abläuft hat den Server nicht zu interessieren, er kann es, wie gesagt, auch nicht überprüfen. Deswegen hat ein Konzept, das derartige Informationen benötigt, prinzipielle Schwachstellen und sollte noch einmal überarbeitet werden.

Die Personenverwaltung, Ändern von Personendaten:

• In der DB sind 3 Angestellte, A, B und C, mit Pers_ID 1, 2, 3.
• User öffnet Person B (Pers_ID = 2)
• User "hacked" HTML Code und setzt Pers_ID (hidden-field) von 2 auf 3
• submit -> falscher Datensatz wird geändert
  Lösung: Vergleich von geladenem und empfangenem Datensatz - ja, kein Problem bei einem STATISCHEN hidden-field, und einem Datensatz.

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.

Wie gesagt, das Prinzip ist gleich wie bei einem hidden-Feld, lediglich die Komplexität ändert sich. Normalerweise löst man dieses Beispielproblem allerdings, indem man überprüft ob der Besucher berechtigt ist, Datensatz 2 zu bearbeiten. Falls dies der Fall ist: kein Problem (ein Besucher, der das Formular manipuliert sollte wissen, was zu tun ist. Der Server muss nur darauf achten, dass der Besucher nichts anstellen kann, wozu er nicht berechtigt ist.) Falls der Besucher keine Berechtigung hat, gibt's stattdessen eine Fehlermeldung.

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

Wie bereits weiter oben gesagt, Web-Formulare müssen programmiertechnisch anders behandelt werden als die GUIs bei lokalen Programmen (die sich übrigens auch manipulieren lassen, wenn auch nur mit deutlich höherem Aufwand.)

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

Das liegt daran, dass HTML ursprünglich nicht für Programme konzipiert wurde. Das Problem tritt aber in allen Fällen der Server-Client-Kommunikation auf, da der Server nicht überprüfen kann, wie genau ein Request auf der Client-Seite zustande gekommen ist.

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

Das mag sein. Dadurch öffnet er aber in seiner Anwendung erhebliche Sicherheitslücken. Diese Vorgehensweise ist also nicht zur Nachahmung zu empfehlen,

Johannes

[Klawischnigg]

Hi there,

Nun frage ich mich, wie kann ich mich gegen sowas schützen. Ich könnte die POST/GET Rückgaben validieren, ob das Formular so angekommen ist, wie es sein soll ... ooops, aber was ist wenn der Firebug-User nun auch noch das target und die method des forms geändert hat ... naja ... ihr seht, so unbedenklich ist das nicht.

All das musst Du ohnehin machen, wenn Du Usereingaben auswerten willst. Jeder kann Dein auswertendes PHP-Skript ja auch ohne Dein Forumular aufrufen, überleg Dir das einmal. Wenn Du das nicht für unbedenklich hältst kann ich Dir nur sagen, sehr fein, gut erkannt, willkommen in der Wirklichkeit...

[OhneName]

Hallo,

HTML bringt ja schon so einige Nachteile mit, z.B. keine Sonderzeichen (<>") in Eingabefeldern oder in anderen HTML-Elementen - klar, muss man halt ersetzen.

Wie bitte? Was spricht gegen &gt; für >, &lt; für < und &quot für "? Damit kann man diese Zeichen doch ganz normal verwenden. Wo ist das Problem?

Ein SEHR großes Problem dass mir die Tage aufgefallen ist, ist die Firebug-Extension des Firefox, mit dem man lustig die ganze Seite umbauen kann. D.h. der User kann hidden-Fields löschen die man eigentlich für die Steuerung der Seite bräuchte, den Namen/Value des Submit-Buttons ändern, letzendlich das ganze Ding kaputt machen, und mein PHP/DB-Backend mit Schrott zu müllen.

Wenn jemand anfängt an deinem Formular rumzubasteln, dann muss derjenige eben damit rechnen, dass die Seite nicht mehr die gewünschte Funktion erfüllt.

Nun frage ich mich, wie kann ich mich gegen sowas schützen. Ich könnte die POST/GET Rückgaben validieren, ob das Formular so angekommen ist, wie es sein soll ... ooops, aber was ist wenn der Firebug-User nun auch noch das target und die method des forms geändert hat ... naja ... ihr seht, so unbedenklich ist das nicht.

Die Rückgabedaten musst du sowieso validieren. Wenn du das nicht bereits tust, dann solltest du das schleunigst ändern. Informiere dich mal über XSS. Sobald irgendwas an den GET/POST-Daten falsch ist, bekommt der Benutzer eine Fehlerseite vorgesetzt. Damit wäre das Problem mit den Firebug-Usern bereits gelöst. Und sowieso ist Firebug ja nicht die einzige Möglichkeit deiner Seite vollzumüllen. Man kann sich problemlos Programme schreiben die sinnlose POST-Requests an deine Seite schicken. Schon rein wegen denen musst du alle einkommenden Daten validieren.

Die Lösung?

Ein Standard-HTML-Formular und ein PHP-Backend, das sämtliche vom Benutzer manipulierbare Daten erstmal gründlich validiert.

Gruss,
OhneName

[dr.colossos]

Danke für die Antworten.

@Klawischnigg:
Die PHP-Scripte können zumindest nicht "einfach" aufgerufen werden, es ist immerhin ein Login und eine gültige Session nötig.

@OhneName:
Ja, ich weis schon das ich die Sonderzeichen (<>") ersetzen muss, aber evtl. ist das in anderen Techniken nicht nötig ... Denn bei Formularen mit bis zu 1000 Eingabefeldern ist das auch ein Zeitfaktor.

Naja, mal abgesehen davon, was gäbe es an Alternativen für HTML-<form>s.

Danke nochmal

[Johannes Zeller]

Hallo,

Die PHP-Scripte können zumindest nicht "einfach" aufgerufen werden, es ist immerhin ein Login und eine gültige Session nötig.

Sobald sich aber jemand eingeloggt hat, kann er das PHP-Formular aufrufen und diesem _beliebige_ Werte übergeben. Du musst also _immer_ überprüfen, ob die Werte, die das PHP-Script erhält in dem Kontext, in dem sie später verwendet werden keine Schäden bewirken können. Wenn du bestimmte Voraussetzunge, z.B. dass bestimmte Felder ausgefüllt sein müssen, erfüllt haben willst, musst du auch das überprüfen.

Ja, ich weis schon das ich die Sonderzeichen (<>") ersetzen muss, aber evtl. ist das in anderen Techniken nicht nötig ... Denn bei Formularen mit bis zu 1000 Eingabefeldern ist das auch ein Zeitfaktor.

Für die Ersetzung gibt es doch so praktische Funktionen wie htmlspecialchars(). Aber 1000 Eingabefelder hört sich für mich nach einem etwas verqueren Konzept an, wer soll denn diese Monsterfomulare ausfüllen?

Naja, mal abgesehen davon, was gäbe es an Alternativen für HTML-<form>s.

XForms ;-)
Die praktische Einsetzbarkeit dieser Technologie im Web liegt aber im Moment noch nahezu bei null und es würde auch an dem Problem, vom dem du ausgehst, nichts ändern.

Schöne Grüße,

Johannes

[Der Martin]

Hallo,

ich möchte auf einer Web-Seite Formulare einsetzen.

na prima, nur zu!

HTML bringt ja schon so einige Nachteile mit, z.B. keine Sonderzeichen (<>") in Eingabefeldern oder in anderen HTML-Elementen - klar, muss man halt ersetzen.

Wie jetzt?
Beim Ausgeben des Formulars? Da hast du ja entweder nur statisches HTML, wo du _einmal_ die Sonderzeichen von Hand ersetzen musst; oder du hast eine serverseitige Scriptlogik, die auch noch schnell die Sonderzeichen umcodieren kann. Die paar Mikrosekunden reißen's ja nicht raus.
Oder beim Ausfüllen und Abschicken? Da spielt das keine Rolle, weil beim Versenden kein HTML mehr im Spiel ist. Stattdessen müssen bestimmte Zeichen URL-codiert werden, aber das macht der Browser beim Absenden des Formulars schon von sich aus.

Es gibt noch andere Probleme, wie z.B. das Browser-Problem ... egal.

Hmm? Was für ein Browser-Problem?

Ein SEHR großes Problem dass mir die Tage aufgefallen ist, ist die Firebug-Extension des Firefox, mit dem man lustig die ganze Seite umbauen kann. D.h. der User kann hidden-Fields löschen die man eigentlich für die Steuerung der Seite bräuchte, den Namen/Value des Submit-Buttons ändern, letzendlich das ganze Ding kaputt machen, und mein PHP/DB-Backend mit Schrott zu müllen.

Moment. Dass man deinem Script irgendeinen Schrott zuschicken kann, ist klar. Dazu braucht man kein Firebug, da reicht es, einfach ein eigenes Formular zu schreiben und dessen Ergebnis an dein Script zu schicken. Eine gründliche Prüfung der empfangenen Daten auf Korrektheit und Plausibilität ist sowieso zwingend nötig. Wo liegt also das Problem (außer in einer Portion Fleißarbeit)?

Nun frage ich mich, wie kann ich mich gegen sowas schützen. Ich könnte die POST/GET Rückgaben validieren, ob das Formular so angekommen ist, wie es sein soll

Genau, und wenn etwas nicht passt, eine Fehlerseite zurückgehen lassen.

Die Lösung?

Validierung der Empfangsdaten. Nicht mehr und vor allem nicht weniger.

So long,
 Martin