SQL Injection in der Praxis: Ausnutzen, Erkennen und Mitigieren im Kontrollierten Lab

SQL Injection wurde 2026 stolze 27 Jahre alt und steht weiterhin in den OWASP Top drei, nicht weil Angreifer schlauer geworden sind, sondern weil falsch genutzte ORMs, dynamische Queries in internen Dashboards und GraphQL-Resolver, die Strings konkatenieren, immer noch in Produktion landen. Diese Anleitung baut ein kontrolliertes Lab, in dem du die Schwachstelle von Anfang bis Ende ausnutzt, erkennst und mitigierst. Es geht nicht um den angeberischen Dump der users-Tabelle: Es geht um die vollstandige Schleife, vom ersten Probe-Request bis zur WAF-Regel, die sqlmap in unter zwei Minuten killt. Alles lauft auf eigener Hardware, gegen Ziele, die du angreifen darfst, in einem isolierten Netz ohne Route zu irgendetwas Echtem.

Was SQL Injection wirklich ist

SQL Injection passiert, wenn nicht vertrauenswurdiger Input den SQL-Interpreter als Code statt als Daten erreicht. Die Datenbank kann Absicht des Entwicklers und Payload des Angreifers nicht mehr unterscheiden, sobald beides im selben String klebt. Das kanonische Beispiel ist "SELECT * FROM users WHERE id = " + req.id, wo id=1 OR 1=1 aus einem Einzeltreffer einen vollstandigen Tabellenlese macht. Die Ursache ist nie die Datenbank-Engine, sondern die Konkatenation. Moderne Frameworks machen Parametrisierung zum Standard, doch rohes String-Bauen uberlebt in Reporting-Endpoints, dynamischen ORDER BY-Klauseln, Suchfiltern und selbstgebauten Query-Buildern.

Die Taxonomie der Injection-Klassen

Du kannst nicht testen, was du nicht benennen kannst. In-band UNION-based liefert Daten direkt in der HTTP-Antwort uber ein angehangtes UNION SELECT. Boolean-based blind leitet ein Bit nach dem anderen daraus ab, wie sich die Seite bei wahr oder falsch andert. Time-based blind nutzt SLEEP() oder pg_sleep(), um Daten uber Latenz zu leaken, wenn es gar keine sichtbare Ausgabe gibt. Error-based lockt die Datenbank dazu, Daten in einer Fehlermeldung zu echoen. Out-of-band exfiltriert uber DNS oder HTTP, wenn der Kanal vollstandig blind ist. Und second-order speichert eine Payload, die spater feuert, in einer anderen Query, auf einer anderen Route. Echte Anwendungen zeigen meist mehr als eine Klasse.

Das isolierte Lab bauen

Starte mit Docker in einem host-only Netz. Betreibe eine DVWA-Instanz, MySQL 8.0 mit aktivem Binlog und einen Burp-Suite-Proxy, der jeden Request einfangt. Ein minimales Compose-File liefert ein reproduzierbares Ziel: docker compose up -d dvwa mysql. Route den Browser uber Burp, setze die Sicherheitsstufe fur den ersten Durchgang auf low, dann hoch auf medium und high, um zu spuren, wie Input-Filterung das Spiel andert. Exponiere diesen Stack nie auf einem routbaren Interface; SQLi-Labs ziehen opportunistische Scanner an, und ein verwundbares MySQL im offentlichen Netz wird binnen Stunden zum Cryptominer eines Fremden.

Schritt fur Schritt ausnutzen mit sqlmap

Das erste Experiment zielt auf den DVWA GET-Endpoint. Fuhre sqlmap -u 'http://lab.local/vulnerabilities/sqli/?id=1&Submit=Submit' --cookie='PHPSESSID=...; security=low' --batch --technique=BEUST --level=3 --risk=2 aus. In etwa vier Sekunden bestatigt sqlmap boolean-based blind Injection im id-Parameter, in elf enumeriert es die dvwa-Datenbank und ihre Tabellen. Mit --dump -T users ziehst du Credentials, mit --os-shell schreibst du eine Web-Shell, wo FILE-Rechte und secure_file_priv es zulassen. Beobachte die Payloads auf der Leitung: 1 AND 4523=4523, 1 AND 1=2 UNION SELECT NULL,NULL. Diese wiederkehrenden numerischen Literale, der Default-User-Agent sqlmap/1.8.x und der fehlende Accept-Encoding-Header sind genau das Signal, das du spater fur Detection bewaffnest.

Manuell ausnutzen, weil Tools Kontext verpassen

Automatisiere die Entdeckung, aber nutze wichtige Dinge von Hand aus. Fur UNION-based Extraktion findest du erst die Spaltenzahl mit ORDER BY 5-- - bis die Query bricht, matchst dann Typen mit UNION SELECT 1,2,3,4,5-- - und platzierst @@version, database() und group_concat(table_name) uber information_schema.tables in sichtbare Spalten. Fur blind boolean bisektierst du jedes Zeichen mit AND ASCII(SUBSTRING((SELECT ...),1,1))>77. Fur time-based ersetzt du den Vergleich durch AND IF(condition, SLEEP(3), 0). Das einmal von Hand zu tun lehrt dich das mentale Modell, das kein Scanner liefert, und ist der einzige Weg fur WAF-verstummelte Kontexte, wo sqlmaps Tamper-Skripte scheitern.

Second-order Injection: der Bug, den Scanner uberspringen

Registriere uber ein Formular einen User namens admin'-- , dessen Quote das Prepared Statement beim Schreiben sauber escaped. Die Payload liegt inaktiv in der Datenbank. Das Problem lebt in einem internen Such- oder Profil-Endpoint, der diesen gespeicherten Wert in einer dynamischen Query weiterverwendet ohne neu zu parametrisieren. Ergebnis: Authentifizierungs-Bypass auf einer Route, die im initialen Scan nie auftauchte, weil die Payload nur in einem anderen Kontext zundet. Dasselbe Muster reisst GraphQL-APIs auf, deren Resolver einen Query-Builder teilen. Automatische Tools erwischen es selten, weshalb manuelles Code-Review in jedem ernsthaften Engagement weiter Miete zahlt.

Detection und Instrumentierung

Verwandle den Larm des Angreifers in ein Signal. Aktiviere SET GLOBAL general_log = 'ON', damit jedes Statement mit Mikrosekunden-Timestamp im Query-Log landet. Vergleiche dreissig Sekunden legitimen Verkehr mit dreissig Sekunden sqlmap: der Variationskoeffizient der Query-Lange springt von etwa 0,12 auf 1,8, und Syntaxfehler explodieren. Schiebe das Log via Filebeat nach Elastic und baue drei Detections: SQL-Syntaxfehler uber funf pro Minute pro Quell-IP, Folgen mit UNION SELECT NULL, und Query-Ausfuhrungszeit uber drei Standardabweichungen vom stundlichen Baseline. Gegen sqlmap mit --random-agent und --delay=2 feuerten alle drei in unter neunzig Sekunden. Setze auch Honeytokens: eine Fake-Spalte credit_card_test mit ruckverfolgbarem String verrat dir genau, welcher Endpoint geleakt hat, sobald der Wert auf einer Paste-Seite erscheint.

Mitigation und Hardening, das wirklich halt

Echte Mitigation startet mit parametrisierten Prepared Statements und hort dort nicht auf. Ersetze interpolierte Strings durch gebundene Parameter in jeder Sprache: NamedParameterJdbcTemplate in Java, $1-Platzhalter in Gos pgx, und PDO mit PDO::ATTR_EMULATE_PREPARES=false in PHP, um den klassischen Multibyte-Quote-Bypass zu vermeiden. Da Prepared Statements keine Identifier parametrisieren, sichere dynamisches ORDER BY und Spaltennamen mit strikter Allowlist. Erganze Least Privilege fur den Anwendungsuser (GRANT SELECT, INSERT, UPDATE, nie FILE oder SUPER), Input-Validierung an der Kante und eine WAF wie ModSecurity mit CRS 4.x im Blocking-Modus davor. Reduziere die Angriffsflache, bevor du Detection vertraust; Defense in Depth heisst, dass ein Angreifer jede Schicht schlagen muss, nicht nur eine.

Haufige Fallstricke

Teams brechen ihre eigenen Verteidigungen auf vorhersehbare Weise. Sie parametrisieren den Wert, interpolieren aber den Tabellennamen. Sie vertrauen einem ORM und droppen dann fur einen Report auf eine rohe Query. Sie escapen beim Output statt beim Input zu parametrisieren. Sie fahren den App-User als root auf der Datenbank, sodass eine kleine Injection zur vollen Server-Ubernahme wird. Sie testen nur das Login-Formular und ignorieren Suche, Export und Admin-Panels, wo das hassliche dynamische SQL steckt. Und sie halten einen grunen sqlmap-Scan fur Sicherheitsnachweis, obwohl sqlmap die second-order- und Business-Logic-Pfade per Design nie meldet, die ein menschlicher Reviewer findet.

Eine Feld-Checkliste

Vor dem Abzeichnen: jede Query mit externem Input ist parametrisiert; Identifier laufen durch eine Allowlist; der DB-User hat Least Privilege; Fehlermeldungen sind generisch und echoen nie SQL; eine WAF blockt in Produktion, statt nur zu loggen; das Query-Log speist ein SIEM mit den drei obigen Detections; Honeytokens stecken in wertvollen Tabellen; und ein quartalsweiser Review deckt jeden Endpoint ab, der Input akzeptiert, inklusive interner und Admin-Routen. Beweise, dass die Schleife funktioniert, indem du deinen eigenen Build angreifst und die Alerts feuern siehst.

Uber MySQL hinaus: andere Engines andern die Payloads

Die Klasse des Bugs ist portabel, die Syntax nicht, und ein Tester, der nur MySQL kennt, friert in dem Moment ein, in dem das Backend PostgreSQL oder SQL Server ist. Auf PostgreSQL konkateniert man mit ||, kommentiert mit --, verzogert mit pg_sleep(3), und gestapelte Queries sind oft uber den Treiber verfugbar, was die Tur zu COPY ... TO PROGRAM-Befehlsausfuhrung auf schlecht konfigurierten Instanzen offnet. Auf SQL Server treibt WAITFOR DELAY '0:0:3' die time-based Inferenz, xp_cmdshell ist die klassische Eskalation, wenn es aktiviert ist, und error-based Extraktion nutzt CONVERT()-Typkonflikte. Oracle zwingt jedes SELECT durch FROM dual und konkateniert ebenfalls mit ||. NoSQL-Stores sind auch nicht sicher: MongoDB akzeptiert Operator-Injection wie {"$gt": ""}, wenn ein JSON-Body unvalidiert in eine Query fliesst, und macht aus einem Login einen immer-wahren Treffer. Die defensive Lehre ist bei allen identisch, weshalb sie generalisiert: baue die Query nie aus dem Input, binde immer, und fahre den Datenbank-Account immer mit dem engstmoglichen Grant, damit selbst eine erfolgreiche Injection das Betriebssystem nicht erreicht.

FAQ

Macht mich ein ORM immun gegen SQL Injection? Nein. ORMs parametrisieren den gangigen Pfad, aber rohe Query-Escapes, native SQL-Fragmente und dynamisch gebaute WHERE- oder ORDER BY-Klauseln bringen die Schwachstelle zuruck. Auditiere jede Stelle, an der dein ORM auf rohes SQL fallen lasst.

Reicht eine WAF allein? Nein. Eine WAF kauft Zeit und blockt Standard-Tooling, aber Encoding-Tricks, Tamper-Skripte und second-order Payloads umgehen Signatur-Regeln. Behandle die WAF als eine Schicht uber parametrisierten Queries und Least Privilege, nie als Ersatz.

Wie teste ich sicher in Produktion, ohne Daten zu zerstoren? Gar nicht mit destruktiven Payloads. Nutze read-only Proben wie boolean- und time-based Vergleiche, die nichts schreiben, halte --risk niedrig, vermeide --os-shell, --dump gegen echte Nutzertabellen und stacked Queries, und hol dir vorher schriftliche Autorisierung mit klarem Scope und Zeitfenster. Ein Pentest, der Daten loscht oder den Dienst umwirft, ist kein Test, sondern ein Incident; reproduziere jeden gefahrlichen Schritt zuerst im isolierten Lab und fahre gegen Produktion nur die minimal-invasive Bestatigung.

Praktisches Takeaway: bau das Lab auf, fahr sqlmap einmal um den Payload-Rhythmus zu spuren, und investiere die restlichen achtzig Prozent in Detection und Fixes. SQL Injection ist kein Kreativitatsproblem des Angreifers, sondern eine dynamische Query, die niemand reviewt hat. Parametrisiere alles, was Wert ist, allowliste alles, was Identifier ist, und an dem Tag, an dem du nachweist, dass deine Anwendung sqlmap in unter zwei Minuten mit automatischem Blocken killt, hast du gewonnen.