SQL-Injection verstehen – wie funktioniert der Angriff eigentlich genau?

Hi Anna, der Punkt mit "glaubt" trifft es ganz gut. Die Anwendung baut einfach einen String zusammen und weiß gar nicht, dass darin mal Daten und mal Befehl steckt. Die Datenbank bekommt am Ende nur noch einen fertigen SQL-Text und kann nicht mehr unterscheiden, was davon ursprünglich Nutzereingabe war und was fest im Code stand. Genau da liegt das Problem.

Klassisches Beispiel, Login per Konkatenation:

• SELECT * FROM users WHERE name = '" + eingabe + "'

Wenn jemand bei der Eingabe ' OR '1'='1 einträgt, steht am Ende da:

• SELECT * FROM users WHERE name = '' OR '1'='1'

Die DB sieht nur noch fertiges SQL und wertet die Bedingung aus – '1'='1' ist immer wahr, also kommen alle Datensätze zurück. Der Trick funktioniert, weil das schließende Hochkomma aus der Eingabe die ursprüngliche String-Grenze beendet und danach frei SQL weitergeschrieben werden kann.

Bei Prepared Statements läuft das anders: Erst wird die Struktur der Abfrage an die DB geschickt (mit Platzhaltern), die DB erstellt daraus quasi einen Ausführungsplan. Erst danach werden die eigentlichen Werte getrennt übergeben – rein als Daten, nicht als SQL-Text. Es gibt also keinen Zeitpunkt mehr, an dem Nutzereingabe und SQL-Code im selben String stehen. Deshalb kann da kein Hochkomma mehr "ausbrechen".

Tobis Erklärung trifft den Kern schon sehr gut, ich ergänze das nochmal aus einer etwas anderen Perspektive, weil mir das beim Verständnis geholfen hat: Man kann sich das als zwei komplett getrennte Kanäle vorstellen. Beim normalen String-Zusammenbau gibt es nur einen Kanal – Struktur und Daten reisen gemeinsam als ein einziger Text zur DB, und die DB muss anhand von Zeichen wie Hochkommas raten, wo die Struktur endet und die Daten anfangen. Genau diese Rateaufgabe kann man als Angreifer manipulieren.

Bei Prepared Statements gibt es diese Rateaufgabe gar nicht mehr, weil Struktur und Daten getrennt übertragen werden. Die DB kennt also schon vorher genau, an welcher Position im Befehl ein Wert eingesetzt wird, und behandelt diesen Platz immer nur als Wert – egal was drinsteht. Selbst ein Hochkomma in der Eingabe wird dann einfach als Zeichen innerhalb eines Strings interpretiert, nicht als SQL-Syntax. Deshalb spricht man von einer strukturellen Lösung: Das Problem wird nicht „abgefangen“, sondern kann an dieser Stelle technisch gar nicht mehr entstehen.

Für eine vollständige Absicherung würde ich in der Projektarbeit noch ergänzen:

• Eingabevalidierung (Whitelisting von erlaubten Zeichen/Formaten)
• Prinzip der minimalen Rechte für den DB-Benutzer
• Keine detaillierten Fehlermeldungen der DB nach außen geben
• ORM-Frameworks, die intern ebenfalls Prepared Statements nutzen