SQL Injection: Wie es funktioniert und wie man es verhindern kann

SQL-Injection (oder kurz SQLi) ist einer der ältesten Tricks im Hackerhandbuch, aber er ist immer noch unglaublich häufig und unglaublich gefährlich. Kurz gesagt, es geht darum, eine Datenbank auszutricksen, damit sie Dinge preisgibt, die sie nicht preisgeben sollte.

In diesem Artikel erkläre ich dir, was SQL-Injection eigentlich ist, wie Angreifer sie einsetzen, welche Beispiele aus der Praxis schwerwiegende Schäden verursacht haben und - vielleicht am wichtigsten - wie du sie verhindern kannst. Egal, ob du ein Entwickler bist oder einfach nur neugierig darauf, wie Dinge im Internet kaputt gehen, du wirst mit einem soliden Verständnis von SQLi nach Hause gehen (ohne auf halbem Weg einzuschlafen, das verspreche ich).

Was ist SQL Injection? 

SQL-Injection ist eine Art von Angriff, bei dem jemand einen Weg findet, die SQL-Abfragen, die deine App an die Datenbank sendet, zu manipulieren. Normalerweise sollen diese Abfragen Dinge wie das Profil eines Nutzers abrufen oder eine Produktliste aktualisieren. Aber mit SQLi kann ein Angreifer bösartigen SQL-Code in deine Eingabefelder (z. B. Suchleisten oder Anmeldeformulare) einspeisen, und plötzlich macht die Datenbank genau das, was sie stattdessen wollen.

Warum funktioniert das? 

Denn irgendwann vertraut die Anwendung den Benutzereingaben ein bisschen zu sehr und behandelt sie wie harmlosen Text und nicht wie potenziell ausführbaren Code. Das ist so, als würdest du jemanden ein Formular ausfüllen lassen und dann das Geschriebene direkt in eine Befehlskonsole einfügen.

Warum ist das schlecht?

SQL-Injection ist gefährlich, da sie dazu verwendet werden kann, private Daten (wie Benutzernamen, Passwörter oder Kreditkarteninformationen) einzusehen oder zu stehlen, Anmeldebildschirme zu umgehen, Daten zu löschen oder zu ändern und im schlimmsten Fall sogar die vollständige Kontrolle über den Datenbankserver zu übernehmen.

Ja, SQLi ist schlecht, und es ist nicht einmal ein neues Sicherheitsproblem, aber du wärst überrascht, wie viele Anwendungen nicht richtig dagegen geschützt sind.

Arten von SQL Injection

Je nachdem, wie der Angreifer mit deiner Anwendung interagiert und welche Art von Feedback er erhält, gibt es SQLi in verschiedenen Varianten. Es gibt 3 Haupttypen, denen du begegnen kannst:

In-Band SQLi

Dies ist der einfachste Typ. Der Angreifer sendet eine bösartige SQL-Abfrage und erhält die Ergebnisse direkt über die Anwendung zurück. Sie ist schnell und oft sehr effektiv.

• Fehlerbasiertes SQLi: Diese Technik beruht darauf, dass die Datenbank hilfreiche Fehlermeldungen zurückgibt. Diese Fehler können eine Menge nützlicher Informationen preisgeben, wie z.B. Tabellennamen oder die Struktur von Abfragen, was es dem Angreifer erleichtert, seinen nächsten Schritt zu planen.

• Union-based SQLi: Hier verwendet der Angreifer den Operator UNION, um seine eigene Abfrage mit der deiner App zu kombinieren. Das ist eine clevere Methode, um zusätzliche Daten aus der Datenbank zu ziehen und sie in die Antwort einzuschleusen.

Inferentielles SQLi (auch bekannt als Blind SQLi)

Dieser hier ist noch raffinierter. Anstatt die Ergebnisse seiner Abfrage direkt zu sehen, beobachtet der Angreifer, wie sich die Anwendung verhält, um herauszufinden, was unter der Haube passiert.

• Boolesches (inhaltsbasiertes) SQLi: Der Angreifer ändert die Abfrage mit Bedingungen, die entweder wahr oder falsch sind (wie 1=1 oder 1=2) und beobachtet, wie sich die Seite verändert. Lädt sie normal? Einen Fehler anzeigen? Seltsam handeln?
• Zeitbasierte SQLi: Diese Technik fügt Zeitverzögerungen in die Abfrage ein (z.B. WAITFOR DELAY '00:00:05' ) und nutzt die Antwortzeit, um daraus zu schließen, ob eine Bedingung erfüllt ist.

Out-of-band SQLi (auch bekannt als wenn die Dinge ausgefallen sind)

Das ist zwar weniger verbreitet, aber trotzdem wissenswert. Out-of-band SQLi verlässt sich nicht auf sofortige Antworten der App. Stattdessen nutzt der Angreifer alternative Kanäle wie DNS- oder HTTP-Anfragen, um Daten zu extrahieren. Sie ist normalerweise für Situationen reserviert, in denen eine direkte Rückmeldung nicht möglich ist, der Datenbankserver aber über einen Internetzugang verfügt (und in 90% der Fälle sollte er das wahrscheinlich nicht).

Übliche SQL-Injection-Techniken

Okay, wir haben also 3 Arten von SQL-Injection kennengelernt. Aber wie machen die Angreifer das in der Praxis?

OR 1=1 Angriff

Das hier ist ein Klassiker. Stell dir ein Anmeldeformular vor, in das du deinen Benutzernamen und dein Passwort eingeben sollst. Ein Angreifer könnte etwas wie das Folgende eingeben:

' OR 1=1 --

Die SQL-Abfrage sieht dann so aus:

SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '';

Da 1=1 immer wahr ist, gibt die Datenbank alle Benutzer zurück , und die -- verwandelt den Rest der Abfrage in einen Kommentar. Wenn es keine Begrenzung gibt, kann sich der Angreifer anmelden, ohne einen gültigen Benutzernamen zu kennen.

Quelle: vmware

Kommentar Injektion

Wie gerade oben gesehen, werden die Zeichen-- oder /* */ verwendet, um Teile einer SQL-Anweisung auszukommentieren. Angreifer nutzen dies, um alle zusätzlichen Klauseln zu entfernen, die ihre eingeschleuste Nutzlast zerstören könnten. Wenn sie z.B. nicht die vollständige Struktur der ursprünglichen Abfrage kennen, können sie sie einfach abhacken und syntaktisch wieder gültig machen.

Batch SQL-Anweisungen

Einige Datenbanken erlauben die Ausführung mehrerer SQL-Anweisungen in einer einzigen Anfrage, die durch ein Semikolon getrennt werden. Diese Funktion kann von Hackern genutzt werden, um alle möglichen Schäden anzurichten, z. B. Daten zu verändern oder sogar Tabellen zu löschen, wenn die Anwendung dies nicht einschränkt.

'; DROP TABLE users; --

UNION-basierte Angriffe

Indem sie eine UNION SELECT Anweisung einfügen , können Angreifer ihre bösartige Abfrage mit der legitimen kombinieren und Ergebnisse aus anderen Tabellen abrufen, z. B. sensible Benutzerdaten, Passwörter oder Kreditkarteninformationen. Dabei wird eine bestehende Abfrage verwendet, um Bonusdaten zu erhalten.

Blinde SQL-Injektion

Wir haben das schon einmal erwähnt. Selbst wenn die App keine Fehler anzeigt oder Abfrageergebnisse zurückgibt, können Angreifer durch Beobachtung des Verhaltens Stück für Stück Daten extrahieren. Es ist langsamer und mühsamer, aber es funktioniert. Dies wird oft mit Tools automatisiert, die Hunderte von Abfragen und zeitabhängige Antworten ausprobieren können.

Stored SQL Injection

Das bösartige SQL wird in der Datenbank gespeichert, z. B. in einem Benutzerprofil oder einem Kommentar, und später ausgeführt, wenn jemand diese Daten ansieht.

SQL-Injection-Angriffe in der realen Welt

SQL-Injection mag wie eine Nischenlösung für Hacker klingen, aber sie hat im Laufe der Jahre sehr reale Schäden verursacht. Und mit Schaden meine ich Millionen aufgedeckter Nutzerdaten, hohe Geldstrafen und Schlagzeilen, die den Marketingabteilungen keinen Gefallen taten.

Guess.com (2002)

Dies ist ein frühes Beispiel, das die Menschen aufhorchen ließ. Ein Sicherheitsforscher nutzte einen SQL-Injection-Fehler aus und verschaffte sich Zugang zu über 200.000 Kundendatensätzen, darunter auch Kreditkartendaten. Die gute Nachricht ist, dass sie von einem ethischen Hacker gefunden und gemeldet wurde. 

Heartland Zahlungssysteme (2009)

Dabei handelte es sich um einen massiven Einbruch bei einem Zahlungsabwickler, bei dem über 130 Millionen Kreditkartennummern gestohlen wurden. Die Angreifer nutzten SQL-Injection, um Fuß zu fassen und eskalierten dann von dort aus. Diese wird oft als eine der größten Datenschutzverletzungen aller Zeiten bezeichnet.

Yahoo! Stimmen (2012)

Die Angreifer nutzten einen UNION-basierten SQL-Injection-Fehler aus und gaben 450.000 Benutzernamen und Passwörter im Klartext preis. Ja, du hast richtig gelesen, die Anmeldedaten liegen dort im Klartext. Dieser Verstoß war besonders peinlich, weil Yahoo! ein großes Technologieunternehmen war und die Speicherung von unverschlüsselten Passwörtern selbst nach den Standards von 2012 ein absolutes Tabu ist.

TalkTalk (2015)

TalkTalk ist ein bekannter britischer Telekommunikationsanbieter, der einem einfachen SQL-Injection-Angriff zum Opfer fiel. Rund 157.000 Kundendatensätze wurden kompromittiert, und das Unternehmen wurde zu einer Geldstrafe von 400.000 Pfund verurteilt. Einer der Angreifer war erst 17 Jahre alt.

Gab (2021)

Die Hacktivisten nutzten SQL-Injection, um 70 GB an Daten zu exfiltrieren, darunter private Posts und gehashte Passwörter. Der Einbruch war politisch brisant, und die Folgen führten dazu, dass die Sicherheitslage von Gab noch genauer unter die Lupe genommen wurde.

Wie man SQL Injection verhindert

Okay, nachdem wir uns jetzt ein bisschen mit all diesen realen Verstößen erschreckt haben, lass uns über Lösungen sprechen. Die gute Nachricht ist, dass das Verhindern von SQL-Injection keine Raketenwissenschaft ist. Meistens geht es darum, den Eingaben der Nutzer/innen nicht zu vertrauen und sich an bewährte Verfahren zu halten. Hier ist, was du tun kannst:

Parametrisierte Abfragen verwenden

Das ist die oberste Regel. Erstelle niemals SQL-Abfragen, indem du Zeichenketten aneinander klebst. Verwende stattdessen Platzhalter und übergebe Benutzereingaben als Parameter. Die meisten Frameworks und Bibliotheken machen das super einfach.

Zum Beispiel in Node.js mit pg (PostgreSQL):

client.query('SELECT * FROM users WHERE id = $1', [userId]);

Damit wird der Datenbank im Wesentlichen mitgeteilt, "Hier ist die Abfragestruktur und hier sind die Daten, bitte verwechsle sie nicht".

Stored Procedures intelligent nutzen

Stored Procedures können helfen, aber nur, wenn sie auch dynamisches SQL vermeiden. Die Idee ist, dass die SQL-Logik in der Datenbank gespeichert ist und deine Anwendung nur diese sicheren, vordefinierten Teile der Logik aufruft.

Wenn du lernen möchtest, Funktionen und Stored Procedures zu erstellen, zu aktualisieren und auszuführen, schau dir unseren Kurs Writing Functions and Stored Procedures in SQL Server an.

Eingaben validieren und bereinigen

Wenn deine App eine Zahl erwartet, stelle sicher, dass es eine Zahl ist. Akzeptiere nicht einfach blind alles, was dir ein Nutzer vorsetzt. Verwende Typenprüfungen, Längenbegrenzungen und Zulässigkeitslisten (z.B. nur bekannte gute Werte zulassen), wo es möglich ist.

Escape-Zeichen (wie Anführungszeichen) können auch helfen, aber sie sind kein Ersatz für parametrisierte Abfragen.

Verwende eine Web Application Firewall (WAF)

Eine WAF kann als erste Verteidigungslinie dienen, insbesondere gegen bekannte Angriffsmuster. Es kann helfen, bösartigen Datenverkehr zu blockieren, bevor er deine App erreicht. Nicht narrensicher, aber nützlich. Es ist ein bisschen wie ein Spamfilter für dein SQL.

Anwendung des Prinzips der geringsten Privilegien

Deine Webanwendung sollte sich nicht mit Administratorrechten mit der Datenbank verbinden. Schränke ein, was jeder Nutzer oder Dienst tun kann. Wenn deine App zum Beispiel nur Daten lesen muss, solltest du ihr nicht erlauben, Tabellen zu löschen. Je weniger Kraft sie hat, desto weniger Schaden kann eine Injektion anrichten.

SQL Injection Testing & Detection

Auch wenn du glaubst, dass dein Code sicher ist, lohnt es sich, ihn so zu testen, wie es ein Angreifer tun würde. SQL-Injektionen können leicht durch die Maschen schlüpfen, besonders in großen Codebasen oder Altsystemen. Es gibt Tools und Techniken, die das Aufspüren viel einfacher machen und mit denen es richtig Spaß macht zu spielen.

Manuelles Testen

Manchmal ist der schnellste Weg, ein Loch zu entdecken, es einfach anzustechen. Versuche, ' OR 1=1 -- or '; DROP TABLE users; -- in Formularfelder, URLs oder andere Eingabebereiche einzugeben und schau, wie die App reagiert. Wenn du merkwürdige Fehler, unerwartete Daten oder mysteriöse Erfolgsmeldungen erhältst, hast du vielleicht etwas Verdächtiges gefunden.

Profi-Tipp: Teste immer in einer Entwicklungs- oder Staging-Umgebung. 

Automatisierte Scanner

Es gibt viele Tools, die das Stochern für dich übernehmen. Einige gute:

• sqlmap: Eine Open-Source-Bestie, die die Erkennung und Ausnutzung (in ethischen Testkontexten) automatisiert.
• Burp Suite: Großartig für die Sicherheit von Webanwendungen im Allgemeinen, mit Erweiterungen für die SQLi-Erkennung.
• OWASP ZAP: Kostenlos und anfängerfreundlich, um alle Arten von Schwachstellen im Internet zu finden.

Diese Tools simulieren Angriffe, zeigen potenzielle Einschleusungspunkte auf und können manchmal Abhilfemaßnahmen vorschlagen.

Log-Analyse

Ein weiterer heimtückischer Trick: Überwache deine Datenbankprotokolle. Wiederholte fehlgeschlagene Abfragen, seltsame Syntaxmuster oder eine Flut von Anfragen mit ', --, oder UNION SELECT sind alles rote Fahnen.

Fazit

SQL-Injection wird in absehbarer Zeit nicht verschwinden und ist eine der Bedrohungen, die nie alt werden. Es ist einfach, es ist mächtig, und wenn du nicht aufpasst, kann es großen Schaden anrichten. Die Sache ist die: SQLi ist absolut vermeidbar. Indem du parametrisierte Abfragen verwendest, Eingaben validierst, das Prinzip der geringsten Berechtigung anwendest und regelmäßig testest, kannst du deine Anwendungen und deine Nutzer vor den verheerenden Auswirkungen eines SQL-Injection-Angriffs schützen. 

Denke daran, dass niemand Perfektion erwartet, aber mit ein wenig proaktivem Einsatz kannst du deine Datenbank sicher halten und dies von deiner Sicherheitscheckliste streichen. Und wenn du dich ernsthaft mit SQL beschäftigst und deine Fähigkeiten potenziellen Arbeitgebern präsentieren möchtest, dann wirf einen Blick auf unsere SQL Associate Zertifizierung! Damit zeigst du, dass du in der Lage bist, SQL zu verwenden, um geeignete Daten aus einer Datenbank zu extrahieren und allgemeine Datenfragen zu beantworten.