Bei einer SQL-Injection schleust ein Angreifer über Eingabefelder eigene Datenbankbefehle ein, um Daten auszulesen, zu verändern oder die Anwendung ganz zu übernehmen.
SQL-Injection – kurz SQLi – ist eine der ältesten und zugleich folgenschwersten Schwachstellen in Webanwendungen. Sie entsteht, wenn eine Anwendung Benutzereingaben ungeprüft in Datenbankabfragen einbaut. Statt eines erwarteten Werts – etwa einer Kundennummer – übergibt der Angreifer eine Zeichenfolge, die die Datenbank als zusätzlichen Befehl interpretiert. Die Grenze zwischen Daten und Befehl verschwimmt, und der Angreifer bringt die Datenbank dazu, Dinge zu tun, die der Entwickler nie vorgesehen hat: Datensätze ausgeben, verändern, löschen oder sogar Betriebssystembefehle ausführen.
SQL-Injection gehört seit Jahren zu den OWASP Top 10 und ist dort in der Kategorie „Injection“ eingeordnet. In MITRE ATT&CK fällt das Ausnutzen über eine öffentlich erreichbare Anwendung unter „Exploit Public-Facing Application“ (T1190). Trotz ihres Alters bleibt die Schwachstelle verbreitet, weil sie überall dort entsteht, wo Eingaben und Abfragen vermischt werden – in Webanwendungen ebenso wie in APIs.
So funktioniert es
Man unterscheidet mehrere Ausprägungen, die sich im Informationsrückfluss unterscheiden:
- Klassische (in-band) SQLi: Das Ergebnis der eingeschleusten Abfrage erscheint direkt in der Antwort der Anwendung – etwa als zusätzliche Datensätze in einer Ergebnisliste.
- Blind SQLi: Die Anwendung zeigt keine Daten, verhält sich aber je nach Wahrheitswert der Abfrage unterschiedlich (andere Seite, andere Antwortzeit). Der Angreifer liest die Datenbank Bit für Bit aus.
- Out-of-band SQLi: Die Datenbank wird veranlasst, Daten über einen separaten Kanal – etwa eine DNS-Anfrage – an den Angreifer zu senden.
Ist die Schwachstelle gefunden, lässt sich der Angriff automatisieren. Je nach Rechten des Datenbankkontos reicht die Wirkung vom Auslesen einzelner Tabellen bis zur vollständigen Übernahme des Datenbankservers und von dort ins interne Netz.
Bedeutung für Unternehmen
Eine einzige SQL-Injection in einer kundenseitigen Anwendung kann die gesamte Kundendatenbank offenlegen – mit unmittelbaren Folgen nach DSGVO und, bei betroffenen Einrichtungen, nach NIS2. Der häufigste Grund für solche Schwachstellen ist nicht Unkenntnis, sondern uneinheitliche Umsetzung: An den meisten Stellen werden Eingaben korrekt behandelt, an einer übersehenen Stelle jedoch nicht – und genau die findet der Angreifer.
In unseren Penetrationstests von Webanwendungen und APIs gehört die systematische Suche nach Injection-Schwachstellen zum Kern. Anders als ein reiner Schwachstellenscan prüfen wir dabei auch Logik und Kontext, in denen automatische Werkzeuge regelmäßig scheitern.
Schutz und Prüfung
- Parametrisierte Abfragen: Prepared Statements und ORM-Bindungen trennen Daten strikt von Befehlen – die wirksamste und grundlegendste Gegenmaßnahme.
- Eingaben validieren: Erwartete Formate und Wertebereiche serverseitig prüfen; nie auf Prüfungen im Browser allein vertrauen.
- Least Privilege für Datenbankkonten: Anwendungskonten erhalten nur die nötigen Rechte, damit eine Injection nicht gleich den ganzen Server öffnet.
- Web Application Firewall als zusätzliche Schicht: Sie fängt bekannte Muster ab, ersetzt aber keine saubere Programmierung.
- Regelmäßig testen: Injection-Schwachstellen entstehen mit jeder neuen Funktion neu; wiederkehrende Penetrationstests und ein Retest nach Behebung halten das Risiko klein.