Validierung von Formulatfeldern

[iuppitter]

Um zu verhindern, dass z.B. Skripte eingegeben werden, wird ein Feld über HTML5 validiert: input type="text" name="suche" required pattern="[A-z0-9]{1,15}" Eingaben mit im Pattern nicht enthaltenen Zeichen werden dann abgewiesen. Allerdings nur einmal! Wenn man die Eingabe löscht und die eigentlich unzulässige Eingabe noch einmal wiederholt, wird sie akzeptiert! Lädt man die Seite neu, wird sie wieder abgewiesen. Browser: Firefox 79.0 Was ist da falsch?

[Matthias Apsel]

Hallo iuppitter,

definiere „akzeptieren“.

Bis demnächst
Matthias

[iuppitter]

"Akzeptiert" heißt hier, dass keine Fehlermeldung des Browsers erfolgte und das zur Prüfung eingegebene Skript ausgeführt wurde.

[Rolf B]

Hallo iuppitter,

kann ich mit FF79 (Windows) in jsFiddle nicht nachvollziehen.

Dein Pattern ist aber ggf. nicht das, was Du willst. Hast Du beim zweiten Versuch exakt das gleiche wie beim ersten eingegeben? Oder hast Du da eins der Zeichen []^_` eingetippt - das sind die Zeichen zwischen Z und a, die durch das Patterm [A-z] erlaubt werden.

Vermutlich möchtest Du [A-Za-z0-9] haben. WENN Du denn tatsächlich die Eingabe auf Ascii-Buchstaben und arabische Ziffern beschränken willst. Wenn Du deutsche Wörter erlauben willst, oder Wörter von Nutzern außerhalb Deutschlands, dann ist dieses Pattern sehr unzureichend.

Rolf

[iuppitter]

Das pattern ist nur vorläufig. Trotzdem fällt auf, dass nur beim ersten Versuch eine Fehlermeldung erfolgt. Vor dem zweiten Versuch wurde eine zulässige Eingabe verschickt.

[Gunnar Bittersmann]

@@iuppitter

Um zu verhindern, dass z.B. Skripte eingegeben werden, wird ein Feld über HTML5 validiert: input type="text" name="suche" required pattern="[A-z0-9]{1,15}"

Auf die Art kannst du gar nichts verhindern. Findige „Nutzer“ (für dich eher Schädlinge) finden andere Möglichkeiten, ihre Eingabe zum Server zu senden.^[1]

Dort musst du die Eingaben abfangen und schädliche unschädlich machen.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

---

1. BTW, gegenwärtig basieren meine persönlichen Rekorde bei 8 der 60 Targets der CSSBattle darauf, die Eingaben nicht über das Frontend abzuschicken. ↩︎

[iuppitter]

Auf dem Server werden die Eingaben noch einmal überprüft. Aber ist das nicht zu spät für Cross-Site Scripting mit JavaScript? Das verwendete Pattern ist auch nur vorläufig. Verbesserungsvorschläge werden gerne genommen! Oder reicht auch [^script] oder Ähnliches?

[Der Martin]

Hallo,

Auf dem Server werden die Eingaben noch einmal überprüft.

na dann is' ja gut.

Aber ist das nicht zu spät für Cross-Site Scripting mit JavaScript?

Nö. Eher zu früh. An der Stelle, wo du jetzt gerade operierst, musst du die Eingabe nur soweit einschränken oder maskieren, dass sie bei der serverseitigen Verarbeitung (PHP?) keinen Schaden anrichtet. Da sehe ich aber im Moment kein Problem.

Das Problem entsteht eigentlich erst dann, wenn du diese Eingaben wieder in den HTML-Kontext ausgeben willst - also bei der Ausgabe an den Client durch das PHP-Script. Dort solltest du dann z.B. htmlspecialchars() verwenden, um Zeichen zu maskieren, die vom Browser sonst ungewollt als HTML verarbeitet würden.

Das verwendete Pattern ist auch nur vorläufig. Verbesserungsvorschläge werden gerne genommen! Oder reicht auch [^script] oder Ähnliches?

Wie gesagt: Nach dem, was ich bis jetzt verstanden habe, bastelst du gerade an der völlig falschen Stelle.

Live long and pros healthy,
 Martin

[localhorst]

Hallo/schädliche_Umleitung?daten,

Auf dem Server werden die Eingaben noch einmal überprüft. Aber ist das nicht zu spät für Cross-Site Scripting mit JavaScript?

Cross-Site-Scripting edfolgt mittels eines Roundturns zwischen Client und Server. Dazu ist kein JavaScript erforderlich. Durch fehlendes Escaping beim Kontextwechsel auf dem Server (aus Formulardaten wird ungeprüft eine Response erzeugt) entsteht ein schädlicher Link. Wird dieser dann aktiviert ("angeklickt") landen die Daten bei einem gefälschten Ziel.

Das verwendete Pattern ist auch nur vorläufig. Verbesserungsvorschläge werden gerne genommen! Oder reicht auch [^script] oder Ähnliches?

Es reicht im ersten Schritt zu verarbeitende oder zu respondierende Formulardaten mit der passenden Escapefunktion zu behandeln, also den vorgesehenen Kontextwechsel zu beachten.

Sollen aus Formulardaten Skriptteile gemacht werden, hilft ein passender Parser, der nur erlaubte Elemente zulässt. Mit RegEx würde das schnell unübersichtlich.

LG
localhorst

[localhorst]

Hi,

Um zu verhindern, dass z.B. Skripte eingegeben werden, wird ein Feld über HTML5 validiert: input type="text" name="suche" required pattern="[A-z0-9]{1,15}" Eingaben mit im Pattern nicht enthaltenen Zeichen werden dann abgewiesen. Allerdings nur einmal! Wenn man die Eingabe löscht und die eigentlich unzulässige Eingabe noch einmal wiederholt, wird sie akzeptiert! Lädt man die Seite neu, wird sie wieder abgewiesen. Browser: Firefox 79.0 Was ist da falsch?

Wo der Fehler in deinem Programmkonstrukt steckt, kann man ohne nähere Kenntnis dessen nicht beantworten.

Wo aber der Fehler in der Planung steckt, kann man ahnen. Die Kontrolle muss unbedingt beim DMS (Data modification System) stattfinden, also üblicherweise nicht durch den Client, sondern durch den Server.

Wird dort z.B. PHP eingesetzt, bietet sich für derartige Überwachungen der DOM-Parser an. Mit dessen Hilfe kann man übermittelte Text-/Fileuploads sehr fein gestaffelt auf erlaubte/verbotene Skriptanteile untersuchen.

Sind überhaupt keine HTML-/Skriptanteile erlaubt, hilft oft auch schon ein strip_tags().

LG
localhorst