Ein Code-Review zeigt eine SQL-Abfrage, die durch Verkettung von Benutzereingaben gebaut wird. Was ist die korrekte Behebung?
Kurzantwort
Parametrisierte Abfragen sind die eigentliche Behebung: Sie trennen Code von Daten, sodass Benutzereingaben stets als Wert behandelt werden, niemals als SQL, das die Abfragestruktur ändern kann. Manuelles Escaping ist fehleranfällig und je nach Kodierung und Dialekt umgehbar. Ein WAF ist eine kompensierende Maßnahme, keine Behebung, und Kodierungstricks hebeln es aus. Eine Längenprüfung stoppt Injection überhaupt nicht. Behebe es auf der Abfrageebene.
Eine durch String-Verkettung zusammengesetzte Abfrage lässt vom Angreifer kontrollierten Text Teil des SQL werden, das die Datenbank parst. Die Grundursache ist, dass Code und Daten in derselben Zeichenkette vermischt sind. Jede Behebung, die sie nicht trennt, behandelt nur Symptome.
Warum parametrisierte Abfragen die Lösung sind
Bei einem Prepared Statement wird der SQL-Text mit Platzhaltern zuerst an die Datenbank gesendet und kompiliert; die Benutzerwerte werden getrennt übertragen und an diese Platzhalter gebunden. Der Parser hat die Abfragestruktur bereits festgelegt, bevor er die Eingabe sieht, sodass ein Wert wie ' OR 1=1-- nur ein String-Literal sein kann — niemals neue SQL-Syntax. Das ist strukturell und kein Filter, den man ständig nachjustieren muss, weshalb es die kanonische OWASP-Empfehlung ist.
Warum die anderen Optionen scheitern
- Anführungszeichen mit einem regulären Ausdruck escapen versucht, gefährliche Zeichen von Hand zu neutralisieren. Es bricht bei alternativen Kodierungen, Unicode, numerischen Kontexten ohne Anführungszeichen und den feinen Escaping-Unterschieden zwischen MySQL, PostgreSQL und anderen. Ein einziger übersehener Kontext reißt die Lücke wieder auf.
- Eine WAF-Regel hinzufügen und den Code unverändert lassen ist eine kompensierende Maßnahme, nützlich als Defense-in-Depth, aber sie gleicht Verkehrsmuster ab und wird routinemäßig mit Kommentaren, Groß-/Kleinschreibung und Kodierung umgangen. Der verwundbare Code geht trotzdem in Produktion.
- Ein Limit von 100 Zeichen bringt nichts:
' OR 1=1--und die meisten Exfiltrations-Payloads passen mühelos unter jedes vernünftige Limit.
Worauf der Interviewer achtet
Er will sehen, dass du die Fehlerklasse auf der richtigen Ebene behebst, statt zu einem Filter oder einer Appliance zu greifen. Eine starke Antwort nennt zuerst die Parametrisierung, behandelt Eingabevalidierung und WAF als zusätzliche Schichten (nie die Behebung) und kennt den Grenzfall: Bind-Variablen können Bezeichner wie Tabellen- oder Spaltennamen nicht parametrisieren, daher müssen dynamische Schema-Elemente stattdessen gegen eine strikte Allow-Liste validiert werden.
Wahrscheinliche Anschlussfragen
- Wie verhindern parametrisierte Abfragen konkret, dass der Parser die Eingabe als Code behandelt?
- Wo helfen Prepared Statements NICHT — etwa bei dynamischen Tabellen- oder Spaltennamen?
- Wie würdest du diese Behebung sicher über eine große Legacy-Codebasis ausrollen?