nicht angemeldet
Hello Alexander,
Wenn wir schon über alte APIs reden: PHP hat DB-Interfaces, die mit Prepared Statements umgehen können. Damit ist SQL Injection UNMÖGLICH.
Prepared Statements sind ungefähr das, was ich 1989 schon mit Pascal und bTrieve gebaut habe, also back to the roots. Arbeiten mit Blockbuffer. Es ist eben nicht alles schlecht gewesen. Und (Turbo-)Pascal war mit seiner rigiden Typenprüfung sowieso am besten ;-D
intval() ist nicht der sauberste Ansatz, das hast Du selbst schon teilweise erklärt: intval() liefert keinen brauchbaren Fehlerstatus, deswegen mußt Du in der DB ausbaden, was Du in PHP verbockt hast.
PHP hat auch noch die Filterfunktionen:
http://de2.php.net/manual/en/book.filter.php
zur Überprüfung und Einhaltung der Formatforschriften und zweitens sollte eine gewisse Logik durchgängig sein. Der Fehler steckt ja in HTTP, und nicht in PHP, denn HTTP überträgt nur Strings.
Allerdings macht PHP daraus ggf. auch wieder ein Array...
Erschwerend kommt hinzu, dass intval() gelegentlich auch 1 als FEHLERSTATUS liefert. (Ich will gar nicht wissen, welche Drogen man sich einwerfen muß, um auf eine derart abgedrehte API zu kommen.)
Das ist tatsächlich verwerflich. Man muss also erst noch auf den Typ prüfen und sicherstellen, dass man einen String erhalten hat, also doch besser gleich die Filterfunktionen benutzten. Das will ich dann doch lieber sofort nochmal ausprobieren, ob man das Problem damit lösen kann.
Da PHP reguläre Ausdrücke beherrscht, sollte vor der Übergabe des Parameters an die DB-Schnittstelle überprüft werden, ob der Parameter dem erwarteten Muster entspricht.
Das ist zu spät. Das sollte man schon tun, wenn man die Werte im Script "übernimmt", also z.B. das $_POST-Array mit dem Array mit den Vorgaben vergleicht.
Das sollten wir auf jeden Fall nebst negativen Beispielen in den Artikel "Umgang mit Formulardaten" aufnehmen, der Bestandteil des Mail-Artikels von Martin werden könnte...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
