Wie verhindern Prepared Statements SQL-Injection?
Kurzantwort
Prepared Statements senden zuerst die Abfragevorlage mit Platzhaltern an die Datenbank, sodass die Struktur feststeht, bevor irgendwelche Nutzerdaten eintreffen. Parameter werden danach als reine Daten gebunden und können niemals als SQL geparst werden — eine Eingabe wie ' OR 1=1 wird also als Zeichenkettenliteral behandelt, nicht als Code. Diese Trennung ist die kanonische, zuverlässige Lösung gegen Injection.
Prepared Statements (parametrisierte Abfragen) sind die kanonische Verteidigung gegen SQL-Injection, weil sie die Ursache angehen: SQL-Injection existiert nur, weil Daten und Code zusammen in einer einzigen Zeichenkette reisen. Prepared Statements trennen sie.
Wie die Trennung funktioniert
Die Abfrage wird in zwei Phasen an die Datenbank gesendet:
- Vorbereiten. Die Anwendung sendet die Abfrage-Vorlage mit Platzhaltern, z. B.
SELECT * FROM users WHERE email = ?. Die Datenbank parst, kompiliert und plant diese Anweisung, bevor sie irgendeine Nutzereingabe sieht. Die Struktur ist nun fixiert. - Binden und Ausführen. Die vom Nutzer gelieferten Werte werden getrennt gesendet und als typisierte Daten an die Platzhalter gebunden. Sie werden nie erneut als SQL geparst.
Wenn ein Angreifer also ' OR 1=1 -- übermittelt, behandelt die Datenbank diese gesamte Zeichenkette als Literalwert, der mit der Spalte email verglichen wird. Sie sucht nach einem Nutzer, dessen E-Mail wörtlich ' OR 1=1 -- lautet, findet keinen und gibt nichts zurück. Die Payload wird nie Teil der Abfragelogik.
Warum Maskierung die schwächere Alternative ist
Manuelle Maskierung versucht, gefährliche Zeichen in einer zusammengesetzten Zeichenkette zu neutralisieren — aber das geht leicht schief (Zeichensatzprobleme, übersehene Kontexte, numerische Felder ohne Anführungszeichen). Prepared Statements beseitigen die gesamte Fehlerklasse.
Wo sie an Grenzen stoßen
Platzhalter funktionieren nur für Datenwerte, nicht für Bezeichner — du kannst keinen Tabellennamen, Spaltennamen oder eine ORDER BY-Richtung parametrisieren. Müssen diese dynamisch sein, musst du eine strenge Zulassungsliste verwenden, die die Nutzereingabe auf bekannte, gute Bezeichner abbildet. ORMs verwenden intern in der Regel Prepared Statements, aber Roh-SQL-Schlupflöcher können Injection wieder einführen.
Prüfer achten auf die Erklärung, dass die Struktur kompiliert wird, bevor die Daten eintreffen, auf das konkrete Beispiel, in dem ' OR 1=1 zu einem Literal wird, und auf das Bewusstsein für die Bezeichner-Einschränkung, die Zulassungslisten erfordert.
Wahrscheinliche Anschlussfragen
- Warum kann man keinen Platzhalter für einen Tabellen- oder Spaltennamen verwenden?
- Wie hängt ein ORM mit Prepared Statements zusammen?
- Wann ist Maskierung oder eine Zulassungsliste weiterhin nötig?