Was muss aus Benutzereingaben alles gefiltert werden,

htmlspecialchars oder htmlentities brauchst Du bei der Ausgabe (zB Browser).
Und wegen den Injections:
mysqli_real_escape_string() / mysql_real_escape_string()

Aber die escape-dinger brauchst Du nicht mehr, wenn Du die PDO (richtig) nutzt.

Für die db - ja.
Im anderen Thread hatte ich das mit den ->prepare und ->execure geposted.
Wenn Du die PDO nutzt, und immer Platzhalter verwendest, dann ist eine Sql-Injection nicht möglich.

http://de3.php.net/pdo.prepared-statements

Zitat

Wenn eine Anwendung ausschließlich Prepared Statements benutzt, kann sich der Entwickler sicher sein, dass keine SQL-Injection auftreten wird. (Wenn aber trotzdem andere Teile der Abfrage aus nicht zuverlässigen Eingaben generiert werden, ist dies immer noch möglich.)

Du musst allerdings (sowieso) aufpassen, was auf welchem Weg in die db kommt. Basiii hatte mir das mal gesagt: inverted(glaub ich) injections.
Aber das läuft so weit ich weiß nicht mit normalen Sql-Anweisungen. Da müsste schon was ausgefallenes her.

Ansonsten gäbe es noch die Klassiker RegEx (mit PHP5.3 deprecated) und Variablenfilter.
Oder eben, wie schon gesagt, PDO, da ist Wurst was in den Variablen ist, nur trimmen ist noch nötig
Außerdem jagst du zumindest das Passwort als vertrauenswürdiger Webmaster, dem die Sicherheit seiner Member am Herzen liegt, doch ohnehin erstmal durch password_hash(). Und dann ist sowieso da schonmal nix Schlimmes mehr drin
Du könntest natürlich auch auf den Paranoia-Modus schalten und sämtliche Eingaben erstmal Base64 enkodieren, bevor du Vergleiche in der Tabelle anstellst Aber ich glaube, das könnte evtl. auf die Performance und den Speicher schlagen

Und was bitte sollen Inverted Injections sein? Informationen für Angreifer aus Rückmeldungen von vorgenerierten SQL Statements? So, nach dem Motto "Aha, den Nutzer gibts noch nicht, das ist bestimmt ein toller Angriffspunkt!"

inverted injections sind injections hintenrum
Wollte das mal testen, dann aber vergessen.

Finde gerade nix im Netz, aber das Prinzip ist (nicht wie angenommen in meinem Post vorher),
dass (wie auch immer) ein String in die db komme wie zB:

Zitat

alert('hallo'); -- irgendwas ganz boeses

Wenn man mit den db-Daten jetzt eine vorgefertigte Form ausgibt, und die Daten nicht maskiert (htmlspecialchars zB),
dann wird das ausgeführt - hintenrum.

Das war allerdings keine SQL-Injection.
Bei der muesste man wissen, wie das Script arbeitet.
Man bekommt einen String like

Zitat

meinname', `admin` = 1; --
# halt irgend ne sql-injection

von der db in den Namen des Benutzers zurueck. Der String kam auf irgend einem ungefilterten Weg in die db.
Beim (ver-)arbeiten mit dem Datensatz will das Script nu irgendwas updaten
und der coder hat nur $_POST vars maskiert -- er geht also davon aus, dass hier nix passieren kann:

Zitat

"
UPDATE db.tbl
SET name = '".$dievar."'
WEHRE name = '".$dievar."'
"

Alles anzeigen

und dabei ensteht das hier:

Zitat

"
UPDATE db.tbl
SET name = 'meinname', `admin` = 1; -- '
WEHRE name = 'meinname', `admin` = 1; -- '
"

Alles anzeigen

Es gibt sicher bessere Bsp. Ist aber bissl Kopffasching ;D

Hmm, man sollte doch meinen, dass ein =, ein ; oder ein ` auch so gefiltert werden könnten. Macht das nicht PDO von selber? Schließlich sollte den Erstellern von PDO das System bekannt sein, wenn es sogar hier hin findet

Mit der PDO (richtig genutzt) kann da nix passieren. Dann landet der String nur wieder in der db.