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

AnnaWInf

Ich sitze gerade an meiner Projektarbeit und soll relativ kompakt erklären, wie SQL-Injection technisch funktioniert und warum Prepared Statements das verhindern. Das Prinzip an sich habe ich schon verstanden: Nutzereingabe wird ungeprüft in eine Abfrage eingebaut und dadurch kann jemand zusätzliche SQL-Befehle einschleusen. Aber an einer Stelle hänge ich gedanklich fest.

Wenn ich mir sowas wie eine Login-Abfrage vorstelle, die per String-Konkatenation zusammengebaut wird, verstehe ich, dass am Ende ein veränderter String bei der Datenbank ankommt. Aber mir ist nicht ganz klar, an welcher Stelle im Ablauf genau der Übergang passiert – also ob die Anwendung quasi "glaubt", sie schickt nur Text, und die Datenbank diesen Text dann als Befehl interpretiert, oder ob das schon vorher irgendwie unterschieden wird.

Und bei Prepared Statements verstehe ich nicht ganz, warum die Eingabe dort nicht mehr als Code ausgeführt werden kann. Wird die Eingabe da anders übertragen oder einfach nur anders maskiert?

Hat jemand eine anschauliche Erklärung oder vielleicht ein einfaches Beispiel, an dem man das nachvollziehen kann?

Tobi89

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".

DanielIT

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

AnnaWInf

Danke euch beiden, das mit den zwei Kanälen hat bei mir echt den Groschen fallen lassen! Ich versuche mal, das für mich nochmal mit einem konkreten Beispiel durchzugehen, damit ich es in der Projektarbeit auch sauber erklären kann.

Beim Prepared Statement würde die Login-Abfrage aus meinem Beispiel so aussehen:

SELECT * FROM users WHERE name = ?

Dieser String wird zuerst allein an die Datenbank geschickt, also ohne jeden Nutzerwert. Die DB parst ihn, erkennt die Struktur und weiß: an dieser Stelle kommt gleich ein einzelner Wert vom Typ String hin, der mit dem Spaltenwert "name" verglichen wird. Dieser Ausführungsplan steht dann fest.

Erst im zweiten Schritt wird der eigentliche Eingabewert übergeben, bei meinem Beispiel also ' OR '1'='1 komplett als ein Datum. Die DB setzt diesen kompletten Text an die vorgesehene Stelle ein und sucht einfach nach einem Nutzer, dessen Name exakt diesem kuriosen String entspricht. Da es den vermutlich nicht gibt, kommt kein Ergebnis zurück, genau wie bei jedem anderen "falschen" Namen auch.

Der entscheidende Unterschied ist also: Das Hochkomma wird nie als SQL-Syntax gelesen, weil zum Zeitpunkt der Eingabe die Struktur schon fertig und "eingefroren" ist. Für meine Projektarbeit nehme ich mir vor, genau diesen zeitlichen Ablauf (erst Struktur, dann Daten) als Merksatz zu formulieren, das fand ich anschaulicher als nur "Eingabe wird maskiert".

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

Jetzt mitmachen!

Letzte Beiträge

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

NoSQL vs. relationale Datenbank – wann lohnt sich der Wechsel im Projekt? 6

API-Versionierung – wie gehe ich damit um, wenn sich Schnittstellen ändern? 3

Echte Kundendaten im Testsystem - geht das datenschutzrechtlich überhaupt? 3

Vendor Lock-in bei Cloud-Diensten – wie vermeide ich die Abhängigkeit? 3

Prozessmodellierung mit BPMN – wie unterscheide ich Gateway-Typen sauber? 2

Testdatenbank vs. Produktivsystem – wie trenne ich das sauber im Projekt? 2

Lastenheft und Pflichtenheft – wer schreibt eigentlich was? 2

Microservices oder Monolith – was eignet sich besser für mein Studienprojekt? 3

DSGVO im Studienprojekt – was muss ich bei selbst erhobenen Umfragedaten beachten? 2

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

NoSQL vs. relationale Datenbank – wann lohnt sich der Wechsel im Projekt?

API-Versionierung – wie gehe ich damit um, wenn sich Schnittstellen ändern?

Echte Kundendaten im Testsystem - geht das datenschutzrechtlich überhaupt?

Vendor Lock-in bei Cloud-Diensten – wie vermeide ich die Abhängigkeit?

Über Study-Board.de