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

SQL Injection wurde 2026 sage und schreibe 27 Jahre alt und steht weiterhin in den OWASP Top 3. Nicht weil Angreifer schlauer geworden waren, sondern weil falsch genutzte ORMs, dynamische Queries in internen Dashboards und GraphQL-Endpoints mit naiven Resolvern immer noch Strings konkatenieren. Das Lab das wir hier aufbauen startet mit einer DVWA-Instanz in Docker, MySQL 8.0 mit aktivem Binlog und einem Burp Suite 2025.6 Proxy, der jeden Request einfangt. Ziel ist nicht der angeberische Dump der users-Tabelle: Ziel ist es, das Auge fur die defensiven Instrumentierungssignale zu trainieren, die sqlmap vor dem zweiten Payload stoppen. Wenn du noch keine isolierte Umgebung hast, lohnt sich ein Blick in Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen vorab.

Das erste Experiment zielt auf den DVWA SQLi GET-Endpoint im Low-Level. Wir starten sqlmap -u 'http://lab.local/vulnerabilities/sqli/?id=1&Submit=Submit' --cookie='PHPSESSID=...; security=low' --batch --technique=BEUST --level=3 --risk=2. In 4 Sekunden identifiziert sqlmap eine boolean-based blind Injection im id-Parameter, in 11 Sekunden enumeriert es die dvwa-Datenbank und ihre 2 Tabellen. Schau dir die gesendeten Payloads an: 1 AND 4523=4523, 1 AND 1=2 UNION SELECT NULL,NULL. Diese sich wiederholenden numerischen Literale sind Gold fur Detection-Regeln in WAF und SIEM. Notiere den Default-User-Agent sqlmap/1.8.x und das fehlende Accept-Encoding-Header, denn das verwandeln wir gleich in Signal.

Bevor wir auf time-based Techniken hochschalten, offnen wir einen zweiten Tab und aktivieren MySQL Query Logging mit SET GLOBAL general_log = 'ON'. Jeder sqlmap-Payload landet in /var/log/mysql/general.log mit Mikrosekunden-Timestamp. Vergleicht man 30 Sekunden legitimen Verkehr (generiert von Locust mit 50 simulierten Usern) mit 30 Sekunden sqlmap, explodiert die Entropie der Queries: der Variationskoeffizient der Query-Lange springt von 0,12 auf 1,8. Allein dieses Delta speist schon eine brauchbare Sigma-Regel. Es passt gut zu dem, was wir in Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel behandeln, um daraus eine wiederverwendbare Detection in Elastic zu bauen.

Jetzt der Teil der den Script-Kiddie vom Pentester trennt: second-order SQLi ausnutzen. Wir legen uber das Registrierungsformular einen User mit dem Namen admin'-- an, dessen Quotes vom Prepared Statement der Registrierung sauber escaped werden. Das Problem lebt im internen Such-Endpoint, der diesen Wert in einer dynamischen Query weiterverwendet ohne neu zu parametrisieren. Ergebnis: Authentifizierungs-Bypass auf einer Route, die im initialen sqlmap-Scan nicht mal auftauchte, weil der Payload nur in einem anderen Kontext zundet. Dieses Muster ist dasselbe das gerne GraphQL-APIs mit gemeinsam genutzten Resolver-Buildern aufreisst, wie in Pentest von REST und GraphQL APIs: Technische Checkliste fur legales Bug Bounty beschrieben. sqlmap erwischt das nicht von allein, weshalb manuelles Code-Review in jedem Bug-Bounty-Programm weiter Geld bringt.

Echte Mitigation startet mit parametrisierten Prepared Statements, hort dort aber nicht auf. In unserem Java/Spring-Lab ersetzen wir den interpolierten String durch NamedParameterJdbcTemplate, validieren Input mit Bean Validation (jakarta.validation 3.1) und erganzen eine Allowlist erlaubter Spalten fur ORDER BY (weil PreparedStatement keine Identifier parametrisieren kann). In PHP ist PDO mit PDO::ATTR_EMULATE_PREPARES=false unter MySQL Pflicht, um den klassischen Multibyte-Quote-Bypass zu vermeiden. Weitere Schichten: Least Privilege fur den Anwendungsuser (nur GRANT SELECT, INSERT, UPDATE), plus eine WAF wie ModSecurity mit CRS 4.4 im Blocking-Modus fur numerische Parameter. Das Server-Hardening folgt demselben Prinzip wie in Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen: Angriffsflache reduzieren bevor man Detection vertraut.

Um den defensiven Kreis zu schliessen, hangen wir general_log an Filebeat, schieben das in ein Elastic 8.16 Cluster und bauen drei Detections: SQL-Syntaxfehler-Peaks uber 5 pro Minute pro IP, Queries die UNION SELECT NULL in Folge enthalten, und Query-Ausfuhrungszeit uber 3 Standardabweichungen vom stundlichen Baseline. In Tests gegen sqlmap mit --random-agent und --delay=2 feuerten alle drei Regeln in unter 90 Sekunden. Wir setzten zusatzlich Honeytokens: Fake-Spalten wie credit_card_test mit ruckverfolgbaren Strings. Sollte dieser Wert irgendwann auf einer Paste-Seite auftauchen, wissen wir genau welcher Endpoint geleakt hat. Diese Red-Blue-Feedbackschleife spiegelt das, wofur wir in Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus argumentieren.

Praktisches Takeaway: bau das Lab auf, fahr sqlmap einmal um den Payload-Rhythmus zu spuren, und investiere die restlichen 80 Prozent der Zeit in Detection und Fixes. SQLi ist kein Kreativitatsproblem des Angreifers, sondern eine dynamische Query die niemand reviewed hat. Trag dir einen quartalsweisen Review aller Queries die externen Input akzeptieren in den Kalender, parametrisiere alles was Wert ist und nutze Allowlists fur alles was Identifier ist. Der Tag an dem du nachweisen kannst, dass deine Anwendung sqlmap in unter 2 Minuten mit automatischem Blocken killt, hast du gewonnen.