SQL-Injektion Schutz auch bei Prepared Statements?

[dedlfix]

Hi!

Wenn ich _nicht_ mit Prepared Statements arbeite, dann muß ich Sonderzeichen escapen, weil es sonst zu erfolgreichen SQL Injections kommen kann.

Ja.

Dann würde ich also die Funktion mysqli.real-escape-string verwenden.

Ja.

Somit würde zB. der aus einem Formular kommende Name O'Rien als O'Rien in der Datenbank landen.

Nein. Es geht beim Maskieren einzig und allein darum, einen String zu erzeugen, bei dem eindeutig Zeichen mit Sonderbedeutung von denen ohne Sonderbedeutung unterschieden werden können. Der Empfänger liest den Zeichenstrom und filtert die Maskierungen wieder raus, so dass er mit Rohdaten arbeiten kann. Das muss er auch, denn sonst könnte man ihn nie nach der korrekten Länge eines Strings fragen oder richtig vergleichen und sortieren.

Dann müßte ich allerdings vor der Ausgabe mit der Funktion stripslashes die \ entfernen. Und diese Hin- und Her- Prozedur spare ich mir bei der Verwendung von Prepared Statements. Stimmt das soweit?

Nein. Probier es bitte aus. Intern werden die entmaskierte Rohdaten gespeichert und in der Form bekommst du sie auch wieder zurück. Das was intern gespeichert wird, kannst du nicht sehen. Aber mit der Funktion CHARACTER_LENGTH() kannst du die Länge ermitteln und das was bei einer Abfrage zurückkommt, kannst du dir anzeigen lassen. (Auch das was die Funktion mysql(i)_real_escape_string() aus den Daten macht, kannst du mit einer Kontrollausgabe anzeigen lassen. Erzeuge dazu das SQL-Statement in einer Variable.)

Es ist genau das gleiche, wie wenn du in PHP

echo 'O'Brian';

schriebest. Was wird angezeigt? O'Brian ohne . Der \ dient nur dazu, PHP zu sagen, das nächste ' ist kein Stringabschluss. Beim Parsen schon erkennt PHP dies und legt sich intern O'Brian in den Speicher. Ein

echo strlen('O'Brian');

zeigt auch richtig 7 an, der \ ist beim Weiterarbeiten nicht mehr vorhanden.

Lo!