[php] Validierung von Eingabefeldern ...

[Lutz Zetzsche]

Guten Morgen, Stefan!

Am Mittwoch, 28. Juni 2006 23:06 schrieb Stefan Weber:
> >> Ein Hauptgrund, warum ich gerade die Validierung aus JavaScript
> >> raus haben
> >> will ist, dass der Code dem User zugänglich ist und ich nicht
> >> immer gerne offen legen möchte, was ich- wie validiere. Da käme
> >> mir SSI gerade recht, wenn ich sich denn für den User erträglich,
> >> realisieren läßt.
> >
> > Warum sollen die User nicht wissen, wie du validierst? Wenn die
> > Sicherheitssysteme darauf basieren, dass der User nicht weiß, was
> > sie tun sind sie eh sinnlos.
>
> Wenn ich nicht haben will, dass Poweruser die Prüfroutinen einsehen,
> dann aus Sicherheitsgründen. Sorgen machen gemeinhin nicht die
> normalen User sondern die scriptkiddies und der gleichen.
>
> Beim 'basteln' meiner Formulare halte ich mich nämlich durchaus für
> jemanden, der validiert, dabei auch schon mal was übersieht. Wer
> weiß, wie validiert wird, weiß auch, welche Fehler bei der Eingabe
> zulässig sind.

Bei formalen Prüfungen sehe ich den Sicherheitsvorteil bei der 
Verschleierung der Prüfroutinen nicht. Gerade diejenigen, die Dir 
Sorgen machen, wissen selbst, wie solche Prüfroutinen auszusehen haben. 
Also probieren sie einfach aus, ob alle erforderlichen Prüfungen 
korrekt durchgeführt werden. Das nennt man "Reverse Engineering".

Es gibt sogar Sicherheitsexperten, die der Auffassung sind, daß ein 
Übermaß an Sicherheit den gegenteiligen Effekt hat, weil es bestimmte 
Leute herausfordert... :-)

Auf jeden Fall ist es so, daß ich bisher jede noch so ausgeklügelte 
Prüfung der Syntax der anzugebenden Mailadresse durch eine syntaktisch 
korrekte, aber nicht existierende Mailadresse umgangen habe. Ein total 
simpler Ansatz, um eine u.U. komplexe Prüfung zu umgehen.

Will sagen: Bei all den Prüfungen kannst Du letztendlich nie wissen, ob 
die Angaben dann nicht inhaltlich falsch sind, wenn Du nicht zufällig 
auch noch eine Möglichkeit hast, sie inhaltlich vollständig zu prüfen.

Du kannst z.B. herausfinden, ob die angegebene Straße und Hausnummer 
unter der Postleitzahl und in dem Ort existiert, aber ob der Anwender 
da auch wirklich wohnt...? Dafür brauchst Du aber auch einen stets top 
aktuellen Datenbestand. Sonst kann das Ergebnis fehlerhaft sein und 
ehrliche Anwender unberechtigterweise ausschließen.

Alles hat also seine Grenzen. Ich bin mittlerweile der Auffassung, daß 
es letztendlich das Problem des Anwenders ist, wenn er aufgrund bewußt 
falscher Angaben oder aufgrund von Manipulationsversuchen ein falsches 
Ergebnis erhält. Ich trage nur Sorge dafür, daß sich die Anwendung 
korrekt verhält.

Wer z.B. bei Mailadresse oder postalischer Adresse auf eine 
Verifizierung angewiesen ist, kann das ja dadurch tun, daß er zum einen 
eine Mail verschickt, die bestätigt werden muß, und zum anderen eine 
Karte mit einem Freischaltcode an die postalische Adresse. web.de macht 
sowas z.B., wenn man eine Mailadresse bei denen haben will.

Für viel wichtiger als die Verschleierung der formalen Prüfroutinen 
halte ich, daß die Fehlermeldungen bei inhaltlichen Prüfungen nicht zu 
konkret sind, um einem potentiellen Angreifer nicht zu viele 
Informationen über das System zu geben. Klassisches Beispiel: Anmeldung 
fehlgeschlagen. Da sollte man nur dem Fehlermeldung ausgeben, daß 
Benutzername und/oder Passwort falsch waren. Sonst weiß ein Angreifer 
schon einmal, daß der Benutzername richtig war.

Generell würde ich sagen, daß die Art der Fehlermeldungen, die ein 
Angreifer bei seinen Angriffsversuchen zurückerhält, letztendlich für 
ihn am Aufschlußreichsten im Hinblick auf das darunterliegende System 
sind. In diesem Zusammenhang fällt mir wieder folgender Link ein:

http://www.unixwiz.net/techtips/sql-injection.html

> Darum hielte ich (derzeit) einen Mix, nämlich die 
> Validierung mit php auf dem Server zu vollziehen und einen Wert
> zurückzugeben, der von Javascript ausgewertet wird (habs noch nicht
> ausprobiert) für OK, jedenfalls solange, bis ich es geschafft habe,
> mich mit AJAX zu beschäftigen.

Der Kern der Geschichte ist eigentlich relativ einfach. Hier ein kurzes 
Tutorial mit Beispielen:

http://www.w3schools.com/ajax/default.asp

Die Beispiele sind aber nicht mit JSON realisiert, was Hannes zu 
verwenden vorgeschlagen hatte.


Viele Grüße
Lutz