Variablen absichern per mysqli_real_escape_string: Reicht das aus?

[Rolf B]

Hallo Christian_D,

wenn Du einen Wert, den Dir der Browser übergibt (sei es $_GET, $_POST, $_REQUEST oder $_COOKIE), in einen SQL String einsetzt, dann ist mysqli_real_escape_string Schritt 1 auf einem von drei Wegen.

Weg 1: Du erhältst eine Zeichenkette. Diese musst Du escapen (s.o.). Schritt 2 ist, dass sie im SQL in Anführungszeichen zu setzen sind.

Weg 2: Du erhältst eine ZAHL. Diese solltst Du nicht escapen, sondern in eine Zahl konvertieren (was bei einem Wert, der keine Zahl ist, als Fehler auffällt. Damit entfällt Escaping, denn rein numerische SQL-Injection Attacken gibt es meines Wissens nicht). Problem an der Konvertierung ist, dass PHP sich hier recht nutzlos anstellt. intval(" 047a") liefert fröhlich die 47 statt "Fehler" und eine 0 bei nicht-integer Werten, und filter_input erbricht sich über "047", weil es das für oktal hält und man ihm das nicht abgewöhnen kann^[1]. Also: natives Verhalten von atoi aus der Sprache C, ohne Rücksicht auf praktische Erwägungen der Anwendungsprogrammierung. Für Zahlen solltest Du zunächst mit einer Regex prüfen, ob die Eingabe eine valide Zahl ist, und sie dann mit intval konvertieren. Oder floatval, je nach Bedarf (floatval akzeptiert übrigens führende Nullen). Diese Zahl setzt Du dann ohne Anführungszeichen in dein SQL ein.

Weg 3: Verwende prepared Statements und ? Marker für deine Werte. Dann musst Du gar nichts escapen.

Rolf

---

1. Der entsprechende Bug wurde von Rasmus (Lerdorf, nehme ich an) zurückgewiesen. Dezimale Eingaben mit führenden Nullen existieren für ihn nicht. Eine der vielen Stellen in PHP, wo man diese Sprache und ihren Chefautor verfluchen kann. Führende Nullen wurden als "von PHP nicht behandelter Sonderfall" klassifiziert und zur Behandlung an den Anwendungsprogrammierer verwiesen. Oh boy... ↩︎