nicht angemeldet
Tach!
wenn du als "wert=" z.b. Zahlen erwartest, dann prüfe ob der übergebene Wert eine Zahl ist mit den vorhandenen Funktionen (is_numeric, is_int bei natürlichen Zahlen usw.)
wenn du als "wert=" nur Buchstaben erwartest und/oder wenige andere Zeichen, kannst du einen regulären Ausdruck benutzen.
wenn du als "wert=" eine bestimmte Länge des Strings erwartest, dann kannst du schauen ob er die Anzahl an Zeichen enthält, die du erwartest (z.B. strlen)
Das sind Prüfungen, die man vor allem aus fachlichen Gesichtspunkten durchführen sollte. Um Sicherheit zu gewährleisten sind sie nur bedingt tauglich. Besser als ein "alles weg, was nicht darf" ist ein "alles so notieren, dass es wie gewünscht interpretiert wird". Beim Alles-weg-Ansatz übersieht man gern die eine oder andere Situation. Hingegen ist die Liste der zu berücksichtigenden Zeichen für einen bestimmten Kontext üblicherweise recht klein und eindeutig bekannt.
PDO. PDO ist der neue Standard...
Naja, PDO ist nicht als Ablösung für native Treiber gedacht. Für einige Situationen (abseits der 08/15-Anwendungsfälle) ist es sogar nicht verwendbar. Dein Artikel ist nicht schlecht, aber mir ist er zu wertend. Ob zum Beispiel PDO nicht alle DBMSe unterstützt, kann mir egal sein, wenn ich nur MySQL und vielleicht noch PostgreSQL und noch SQLite benötige. Das wäre also keine "schlechte Meldung". OOP und prozedurale Funktionen in der mysqli-Erweiterung sind auch kein fauler Kompromiss, was das Datenbankhandling angeht, sondern sind der PHP-Philosophie geschuldet. Man mag es vielleicht sogar als Nachteil ansehen, dass PDO keine prozedurale Vorgehensweise erlaubt. Unstrittig ist, dass das Prepared-Statement-Handling um eine ganze Ecke anwenderfreundlicher ist als bei mysqli. Wie du am Ende selbst festellst, ist PDO noch lange kein Allheilmittel, weil es die Unterschiede der SQL-Dialekte nicht auszugleichen vermag. Dafür ist es auch nicht ausgelegt. Es ist lediglich eine Datenbankzugriffs-Abstraktion und keine Datenbank-Abstraktion. Und es ist auch nicht angetreten, alle Funktionen mysql(i)s zu verbessern, das kann es gar nicht vollumfänglich.
Erwarte einfach etwas und schaue was nicht zutreffen darf.
Das ist nicht nur aus sicherheitstechnischen Aspekten bedenklich, weil dabei zu viel übersehen werden kann.
Wenn es doch zutrifft, dann wurden falsche Daten übermittelt. In dem Fall brichst du jede weitere Bearbeitung der Daten ab
Das ist eine Vorgehensweise, um bestimmte Missbrauchsmuster zu erkennen. Das (sprich: Spam verhindern) will man aber eher aus inhaltlichen Gründen.
oder du machst sie mit z.b. htmlspecialchars oder mysql_real_escape_string + weitere unschädlich.
Das ist keine Oder-Angelegenheit. Kontextgerechtes Escaping benötigt man immer, sowohl für die "guten Daten", als auch um Injection-Angriffe zu verhindern. Die fachliche Inhaltsprüfung ist davon komplett unabhängig.
Der SQL-Injection-Abschnitt ist veraltet. Das Feature Magic Quotes gibt es nur in alten PHP-Versionen. Es hat nämlich nur bedingt geholfen und das Problem nicht generell beseitigen können (nur Nutzereingaben behandelt, andere Datenquellen nicht berücksichtigt), sowie einige unangenehme Nebenwirkungen gehabt (wirkt am Script-Anfang und stört, wenn mit den Daten kein DBMS-Zugriff erfolgen soll). Deswegen ist es auch schon seit längerer Zeit nicht mehr per Default eingeschaltet und mittlerweile entfernt worden. Die richtige Vorgehensweise wäre kontextgerechtes Behandeln, situationsabhängig und am Ziel, nicht am Start.
dedlfix.