Sql Injection: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

SQL Injection ist keine einzelne Technik, sondern eine Klasse von Eingabeproblemen, bei denen ungeprüfte oder falsch verarbeitete Daten in Datenbankabfragen gelangen. In der Praxis zeigt sich das nicht nur in klassischen Login-Formularen, sondern in Suchfeldern, Filterparametern, Sortieroptionen, API-Requests, JSON-Bodies, Cookie-Werten, Headern und sogar in sekundären Verarbeitungswegen, bei denen ein zunächst gespeicherter Wert später in einer Query landet. Genau deshalb ist Burp Suite für diesen Bereich so nützlich: Requests lassen sich präzise abfangen, verändern, wiederholen und systematisch vergleichen.

Ein häufiger Anfängerfehler besteht darin, SQL Injection nur mit einem einzelnen Apostroph zu testen und bei ausbleibender Fehlermeldung sofort weiterzugehen. Moderne Anwendungen unterdrücken Datenbankfehler, normalisieren Eingaben oder verarbeiten Parameter serverseitig in mehreren Schritten. Ein fehlender SQL-Fehler bedeutet daher nicht, dass keine Schwachstelle existiert. Entscheidend ist die Beobachtung von Verhaltensänderungen: Statuscodes, Redirects, Antwortlängen, Timing, Seitentitel, Fehltexte, leere Ergebnislisten, Unterschiede in JSON-Strukturen oder Änderungen an Session-States.

Burp Suite wird in diesem Kontext typischerweise in einem Workflow aus Proxy, Repeater, Intruder und optional Comparer eingesetzt. Der Proxy dient zum Erfassen realer Requests. Repeater ist das Kernwerkzeug für manuelle Verifikation. Intruder hilft bei systematischen Variationen, wenn mehrere Payloads oder Parameter gegeneinander geprüft werden sollen. Comparer wird dann wertvoll, wenn Unterschiede klein sind und sauber isoliert werden müssen.

SQL Injection muss immer im Kontext der Anwendung betrachtet werden. Ein numerischer Parameter in einer GET-Anfrage verhält sich anders als ein JSON-String in einer REST-API. Ein Suchparameter, der mit LIKE arbeitet, erzeugt andere Reaktionsmuster als ein Login, das intern mit vorbereiteten Statements arbeitet, aber an anderer Stelle unsichere dynamische ORDER-BY-Konstruktionen verwendet. Wer nur Payloads kopiert, übersieht diese Unterschiede. Wer dagegen den Datenfluss versteht, erkennt schneller, wo Eingaben in Query-Strukturen landen könnten.

Vor jedem Test sollte klar sein, welche Bereiche erlaubt sind und wie der Scope definiert wurde. Gerade bei produktionsnahen Umgebungen ist sauberes Arbeiten Pflicht. Für die organisatorische und technische Vorbereitung sind Scope, Workflow und Legal keine Nebenthemen, sondern Grundlage eines belastbaren Vorgehens.

Die meisten übersehen SQL Injection dort, wo der Parametername harmlos wirkt. id und search sind offensichtlich. Interessanter sind sort, direction, filter, lang, category, page, from, to, profile oder verschachtelte JSON-Felder. Besonders kritisch sind Funktionen, die dynamische Abfragen erzeugen: freie Suche, facettierte Filter, Exportfunktionen, Reporting, Admin-Listen, Bulk-Aktionen und API-Endpunkte mit komplexen Query-Parametern.

Ein typisches Beispiel ist eine Produktliste mit Sortierung. Entwickler schützen vielleicht den Suchbegriff per Prepared Statement, bauen aber die Sortierspalte direkt in die Query ein. Dann ist nicht der Wert des Suchfelds interessant, sondern der Parameter sort=name. Gleiches gilt für numerische IDs, die serverseitig nicht als Integer gecastet werden, oder für JSON-Filter, die intern in SQL-Fragmente übersetzt werden. In APIs ist das besonders häufig, weil dort viele Entwickler davon ausgehen, dass strukturierte Daten automatisch sicher seien.

Auch Cookies und Header dürfen nicht ignoriert werden. Anwendungen speichern Mandantenkontext, Rollen, Sprachcodes oder Feature-Flags gelegentlich clientseitig und lesen diese Werte später in Datenbankabfragen ein. Ein manipulierbarer Cookie kann dann dieselbe Wirkung haben wie ein Formularfeld. In Burp Suite lässt sich das sauber über Proxy History nachvollziehen: Welche Requests werden gesendet, welche Parameter ändern sich, welche Header sind dynamisch, welche Cookies beeinflussen das Verhalten?

• GET-Parameter in Listen, Suchfunktionen, Detailansichten und Exporten
• POST-Parameter in Formularen, Login-Prozessen und Filterdialogen
• JSON- und XML-Bodies in APIs, mobilen Backends und Single-Page-Anwendungen
• Cookies, Header und versteckte Felder mit Kontext- oder Rolleninformationen
• Mehrstufige Workflows, bei denen Eingaben gespeichert und später erneut verarbeitet werden

Ein weiterer Punkt ist Second-Order SQL Injection. Dabei wird ein Wert zunächst nur gespeichert und erst später in einer unsicheren Query verwendet. Das klassische Beispiel ist ein Profilfeld wie Anzeigename oder Firmenname. Die erste Anfrage zeigt keine Auffälligkeit. Erst wenn ein Admin-Report, eine Suchfunktion oder ein Export diesen gespeicherten Wert verarbeitet, tritt die Schwachstelle zutage. Solche Fälle lassen sich nur erkennen, wenn Requests und Folgeaktionen als zusammenhängender Prozess betrachtet werden.

Gerade in modernen Anwendungen mit vielen asynchronen Requests lohnt sich ein strukturierter Blick auf das Zielsystem. Wer Burp bereits sauber eingerichtet hat, profitiert von einer klaren Navigation durch Target Tab, Proxy Intercept und API Testing. SQL Injection ist selten ein isolierter Einzeltest; sie ist meist Teil einer breiteren Analyse des Datenflusses.

Der Repeater ist das wichtigste Werkzeug für belastbare SQLi-Tests. Automatisierte Scanner liefern Hinweise, aber die eigentliche Verifikation erfolgt manuell. Ziel ist nicht, möglichst viele Payloads abzuschießen, sondern das Verhalten eines Parameters kontrolliert zu verändern und die Reaktion der Anwendung präzise zu beobachten. Dazu wird zunächst ein stabiler Basis-Request benötigt. Dieser sollte reproduzierbar sein, keine ablaufenden Tokens enthalten oder vor jedem Test aktualisiert werden und möglichst wenig Nebeneffekte erzeugen.

Ein sinnvoller Start ist die Prüfung, ob ein Parameter überhaupt Einfluss auf die Antwort hat. Wenn eine Produkt-ID verändert wird und sich Inhalt, Titel oder Datensatz ändern, ist der Parameter funktional relevant. Danach folgt die Frage, wie der Server den Wert interpretiert: numerisch, als String, als Teil einer Liste, als Sortierkriterium oder als eingebettetes Fragment. Erst dann werden gezielte Testeingaben gesetzt.

Ein einfacher Ablauf im Repeater Anleitung-Stil sieht so aus: Basis-Request senden, Antwort notieren, einen einzelnen Parameter minimal verändern, erneut senden, Unterschiede dokumentieren. Danach werden kontrollierte Syntaxbrüche getestet, etwa ein einzelnes Apostroph, eine schließende Klammer oder ein Kommentarzeichen. Wenn die Anwendung Fehler unterdrückt, sind Boolesche Varianten oft aussagekräftiger als rohe Syntaxfehler.

GET /products?id=10 HTTP/1.1
Host: target.local

GET /products?id=10' HTTP/1.1
Host: target.local

GET /products?id=10 AND 1=1 HTTP/1.1
Host: target.local

GET /products?id=10 AND 1=2 HTTP/1.1
Host: target.local

Wichtig ist die Interpretation. Wenn AND 1=1 dieselbe Antwort wie der Basis-Request liefert, AND 1=2 aber eine leere Seite, einen anderen Redirect oder eine andere Trefferzahl erzeugt, liegt ein starkes Indiz für eine Boolesche SQL Injection vor. Wenn dagegen beide Varianten identisch sind, kann das mehrere Gründe haben: Parameter wird ignoriert, serverseitig normalisiert, in einen anderen Kontext eingebettet oder die Anwendung cached Antworten. Ohne Kontextanalyse ist das Ergebnis wertlos.

Bei POST-Requests mit JSON muss die Syntax des Formats erhalten bleiben. Ein häufiger Fehler ist, SQL-Payloads einzufügen und dabei das JSON zu zerstören. Dann testet der Request nur die JSON-Validierung, nicht die Datenbanklogik. Dasselbe gilt für URL-Encoding. Manche Eingaben müssen kodiert werden, andere gerade nicht. Wer unsicher ist, nutzt Decoder oder Repeater Parameter Testen, um exakt zu sehen, was tatsächlich übertragen wird.

Die drei wichtigsten praktischen Erscheinungsformen sind error-based, boolean-based und time-based SQL Injection. Error-based ist am einfachsten zu erkennen, weil die Anwendung Datenbankfehler direkt oder indirekt offenlegt. Das kann ein expliziter SQL-Fehler sein, aber auch ein Framework-Trace, ein 500-Status, ein Template-Fehler oder eine ungewöhnliche Fehlermeldung im JSON. Solche Fälle sind selten die schwierigsten, aber sie liefern oft wertvolle Hinweise auf Datenbanktyp, Query-Struktur oder verwendete Funktionen.

Boolean-based SQL Injection ist in realen Tests deutlich häufiger. Hier wird keine Fehlermeldung benötigt. Stattdessen werden zwei logisch gegensätzliche Bedingungen erzeugt, deren Antworten sich unterscheiden müssen. Das kann die Anzahl der Suchtreffer, die Sichtbarkeit eines Elements, die Länge der Antwort oder ein Redirect-Verhalten sein. Entscheidend ist, dass die Unterschiede stabil und reproduzierbar sind. Ein einzelner abweichender Response reicht nicht; es muss ein Muster erkennbar sein.

Time-based SQL Injection wird relevant, wenn weder Fehler noch sichtbare Inhaltsunterschiede zuverlässig auftreten. Dann wird versucht, über eine bedingte Verzögerung Rückschlüsse zu ziehen. Das ist technisch anspruchsvoller, weil Netzwerklatenz, Serverlast, Rate Limits und asynchrone Verarbeitung das Ergebnis verfälschen können. Ein sauberer Test benötigt mehrere Wiederholungen, eine bekannte Baseline und möglichst geringe Störfaktoren.

Beispiele für typische Testmuster:

id=10 AND 1=1
id=10 AND 1=2

id=10' AND '1'='1
id=10' AND '1'='2

id=10 AND IF(1=1,SLEEP(5),0)
id=10 AND IF(1=2,SLEEP(5),0)

Die konkrete Syntax hängt stark vom Datenbanksystem ab. MySQL, PostgreSQL, MSSQL und Oracle unterscheiden sich bei Funktionen, Kommentaren, String-Konkatenation und Sleep-Mechanismen. Wer Payloads ohne Anpassung übernimmt, produziert oft nur Syntaxfehler oder falsch negative Ergebnisse. Deshalb sollte zuerst versucht werden, den Datenbanktyp indirekt zu erkennen: Fehlermeldungen, Header, Framework-Hinweise, SQL-Dialekt in Responses, bekannte Konventionen der Anwendung oder Unterschiede im Verhalten bestimmter Operatoren.

Ein häufiger Praxisfehler bei time-based Tests ist die Verwendung zu kurzer Delays. Eine Verzögerung von einer Sekunde ist in vielen Umgebungen unbrauchbar. Besser sind klar erkennbare Werte mit Wiederholungen und Gegenproben. Ebenso wichtig: keine parallelen Requests, keine laufenden Hintergrundaktionen im Browser und keine unnötigen Burp-Features, die zusätzliche Last erzeugen. Wenn Timing das einzige Signal ist, muss die Messung sauber sein.

Falsch negative Ergebnisse entstehen meist nicht, weil keine Schwachstelle vorhanden ist, sondern weil der Test technisch unsauber war. Ein klassischer Fall ist ein Request mit CSRF-Token oder Nonce, der nach dem ersten Senden ungültig wird. Danach werden alle weiteren Antworten von der Anwendung abgelehnt, und die Unterschiede haben nichts mit SQL zu tun. Ähnlich problematisch sind Session-Wechsel, Redirect-Ketten, Captchas, WAF-Eingriffe, Caching und serverseitige Normalisierung.

Ein weiterer häufiger Fehler ist das Testen des falschen Parameters. In komplexen Requests gibt es oft sichtbare und unsichtbare Steuerwerte. Der sichtbare Suchbegriff wird sicher verarbeitet, aber ein versteckter Filterparameter oder ein Cookie beeinflusst die eigentliche Query. Wer nur offensichtliche Felder testet, verpasst die relevanten Stellen. Deshalb sollte jeder Request zuerst funktional zerlegt werden: Welche Werte ändern das Ergebnis, welche sind nur dekorativ, welche steuern Sortierung, Paging oder Berechtigungen?

Auch Encoding-Probleme führen regelmäßig zu Fehlinterpretationen. Ein Apostroph im Burp-Fenster ist nicht automatisch dasselbe Apostroph, das serverseitig ankommt. URL-Encoding, doppelte Kodierung, Unicode-Normalisierung oder serverseitige Sanitizer können den Payload verändern. In solchen Fällen hilft ein Blick auf die rohe Anfrage, auf serverseitige Fehlermuster und auf alternative Darstellungen. Bei Bedarf lässt sich mit Encode Decode oder Proxy Modify Request präziser arbeiten.

• Abgelaufene Tokens oder Sessions verfälschen die Antwort stärker als der eigentliche Payload
• WAFs blockieren bestimmte Zeichenfolgen und erzeugen generische Fehlerseiten
• Caching liefert identische Antworten, obwohl der Backend-Pfad unterschiedlich wäre
• Asynchrone Frontends zeigen nur Teilinformationen und verdecken Response-Unterschiede
• Payloads passen nicht zum Datentyp oder zum SQL-Kontext des Parameters

Ein besonders tückischer Fehler ist die Verwechslung von Validierungsfehlern mit Datenbankreaktionen. Wenn eine Anwendung clientseitig oder serverseitig nur numerische Werte akzeptiert, führt ein String-Payload möglicherweise nur zu einer Eingabeablehnung. Das sagt nichts über die Sicherheit der späteren Query aus. In solchen Fällen müssen Payloads an den erwarteten Typ angepasst werden, etwa mit numerischen Booleschen Ausdrücken statt String-Manipulationen.

Wer wiederholt auf unklare Ergebnisse stößt, sollte den Testpfad vereinfachen. Einen minimalen Request isolieren, unnötige Header entfernen, stabile Sessions verwenden, Parameter einzeln testen und Antworten mit Comparer Anwendung vergleichen. Viele vermeintlich schwierige SQLi-Fälle werden erst dann sichtbar, wenn Störfaktoren konsequent eliminiert wurden.

Intruder ist bei SQL Injection dann sinnvoll, wenn ein manuell bestätigter Verdacht systematisch vertieft werden soll oder wenn mehrere Parameter, Wertebereiche oder Payload-Varianten effizient gegeneinander geprüft werden müssen. Intruder ersetzt jedoch nicht die manuelle Analyse. Ohne Verständnis des Kontexts produziert er nur große Mengen an Responses, die schwer auszuwerten sind und unnötige Last verursachen.

Für viele SQLi-Szenarien reicht ein einfacher Sniper-Ansatz: ein Parameter, viele gezielte Payloads. Wenn zwei Parameter gemeinsam relevant sind, etwa ein Filterwert und eine Sortierrichtung, kann ein koordinierter Angriffstyp sinnvoll sein. Entscheidend ist, dass die Payload-Liste klein, präzise und hypothesengetrieben bleibt. Eine riesige Wordlist mit generischen SQLi-Strings ist selten effizient.

Ein guter Intruder-Lauf misst nicht nur Statuscodes. Wichtiger sind Länge, Wortanzahl, Redirect-Verhalten, Antwortzeit und markante Textfragmente. Bei Blind-SQLi kann die Kombination aus Antwortzeit und Response-Länge besonders aussagekräftig sein. In manchen Fällen lohnt es sich, vorab im Repeater zwei bis drei bekannte True/False-Payloads zu validieren und erst danach diese Muster im Intruder zu skalieren.

Payload 1: 10 AND 1=1
Payload 2: 10 AND 1=2
Payload 3: 10 AND IF(1=1,SLEEP(5),0)
Payload 4: 10 AND IF(1=2,SLEEP(5),0)
Payload 5: 10 ORDER BY 1
Payload 6: 10 ORDER BY 999

Bei der Auswertung sollte nicht nur nach dem größten Ausreißer gesucht werden. Oft sind es kleine, aber konsistente Gruppenunterschiede, die den Hinweis liefern. Wenn beispielsweise alle ORDER BY-Varianten bis 6 identisch sind, ab 7 aber ein anderer Statuscode oder eine andere Fehlerseite erscheint, kann das auf die Anzahl selektierter Spalten hindeuten. Solche Informationen sind nicht automatisch ausnutzbar, aber sie zeigen, dass der Parameter in SQL-Strukturen eingebettet ist.

Für die praktische Bedienung sind Intruder Anleitung, Intruder Payloads und Intruder Beispiele nützlich, wenn es um die saubere Konfiguration geht. Fachlich entscheidend bleibt jedoch: erst Hypothese, dann Payload, dann Vergleich. Nicht umgekehrt.

Die Qualität eines SQLi-Tests steht und fällt mit der Fähigkeit, Responses richtig zu lesen. Viele Anwendungen liefern keine offensichtlichen SQL-Fehler, aber sie verraten ihr Verhalten über subtile Unterschiede. Dazu gehören veränderte Content-Length-Werte, zusätzliche Leerbereiche, andere JSON-Felder, fehlende Elemente in Arrays, geänderte Paginierung, andere Template-Blöcke oder leicht abweichende Redirect-Ziele.

Ein Beispiel aus der Praxis: Ein Such-Endpoint liefert bei normalen Treffern ein JSON mit "count":12 und einer Ergebnisliste. Bei einer False-Bedingung bleibt der HTTP-Status 200, aber "count":0 und das Array ist leer. Bei einem Syntaxfehler liefert derselbe Endpoint ebenfalls 200, jedoch mit einem generischen Fehlerobjekt. Wer nur auf Statuscodes schaut, erkennt keinen Unterschied. Wer die Struktur vergleicht, sieht sofort drei verschiedene Zustände.

Auch HTML-Anwendungen verhalten sich oft subtil. Eine boolesche Bedingung kann dazu führen, dass nur ein Tabellenkörper leer bleibt, während Header, Navigation und Footer identisch sind. In solchen Fällen ist ein visueller Eindruck unzuverlässig. Besser ist der Vergleich der Rohantworten oder die Suche nach stabilen Markern. Der Comparer ist dafür hilfreich, vor allem wenn Responses lang sind und Unterschiede nicht sofort ins Auge fallen.

Bei Time-Based-SQLi muss die Response-Analyse zusätzlich die Messmethodik berücksichtigen. Einzelne langsame Antworten sind wertlos, wenn die Anwendung generell schwankt. Aussagekräftig wird es erst, wenn True- und False-Bedingungen mehrfach in wechselnder Reihenfolge gesendet werden und sich ein klares Muster ergibt. Ein robustes Vorgehen ist etwa: Baseline messen, True senden, False senden, True wiederholen, Baseline erneut prüfen. So lassen sich Lastspitzen und Zufallseffekte besser erkennen.

Ein weiterer Aspekt ist die Trennung von Frontend- und Backend-Effekten. Single-Page-Anwendungen rendern Antworten oft clientseitig. Im Browser wirkt die Seite unverändert, obwohl der API-Response im Hintergrund klare Unterschiede zeigt. Deshalb sollte nicht nur die sichtbare Oberfläche betrachtet werden, sondern immer auch der tatsächliche Request- und Response-Inhalt in Burp. Gerade bei modernen Frontends ist das Pflicht.

Ein belastbarer SQLi-Workflow beginnt nicht mit Payloads, sondern mit Aufklärung. Zuerst wird die Anwendung normal benutzt, um Datenflüsse, Zustandswechsel und relevante Endpunkte zu verstehen. Danach werden Requests gesammelt, gruppiert und priorisiert. Besonders interessant sind Endpunkte mit Datenbanknähe: Suche, Filter, Listen, Detailansichten, Login, Passwort-Reset, Reporting, Admin-Funktionen und APIs mit Query- oder Filterlogik.

Im nächsten Schritt werden Kandidaten nach Kontext sortiert: numerische Parameter, String-Parameter, strukturierte Daten, Header, Cookies und gespeicherte Eingaben. Für jeden Kandidaten wird ein Basis-Request festgelegt. Dann folgt die manuelle Prüfung im Repeater mit minimalen Änderungen. Erst wenn ein Parameter auffällig reagiert, lohnt sich eine systematische Vertiefung mit Intruder oder ergänzenden Werkzeugen.

In APIs ist zusätzlich wichtig, ob die Anwendung serverseitig GraphQL, ORM-Filter, Such-DSLs oder proprietäre Query-Formate verwendet. Nicht jede Injection in einem API-Kontext ist klassische SQL Injection. Manche Auffälligkeiten gehören eher in die Bereiche NoSQL, Command Injection oder unsichere Query-Parser. Die Abgrenzung ist wichtig, weil sonst falsche Payloads verwendet werden. Wer angrenzende Themen sauber trennen will, findet bei Command Injection und Web Pentest passende technische Einordnung.

• Normale Nutzung der Anwendung zur Erfassung realistischer Requests
• Priorisierung datenbanknaher Funktionen und dynamischer Filtermechanismen
• Manuelle Verifikation einzelner Parameter mit stabilen Basis-Requests
• Systematische Vertiefung nur bei belastbaren Indikatoren
• Dokumentation von Payload, Kontext, Response-Muster und Reproduzierbarkeit

Ein sauberer Workflow berücksichtigt auch Betriebsrealität. Rate Limits, Session-Timeouts, Mandantenkontexte, Rollenmodelle und Testdaten beeinflussen das Ergebnis massiv. Ein Parameter kann für normale Benutzer sicher wirken, aber im Admin-Kontext in eine andere Query laufen. Ebenso kann ein Endpoint in einer leeren Testdatenbank keine sichtbaren Unterschiede zeigen, obwohl die Schwachstelle vorhanden ist. Deshalb müssen Testbedingungen dokumentiert und bei Bedarf variiert werden.

Wer Burp als tägliches Arbeitswerkzeug nutzt, profitiert von einer konsistenten Umgebung. Dazu gehören stabile Proxy-Einstellungen, saubere Projektoptionen und reproduzierbare Testabläufe. Technische Grundlagen dazu finden sich in Projekt Optionen, Einstellungen und Debugging. In der Praxis spart das Zeit und reduziert Fehlinterpretationen.

Eine SQL Injection ist erst dann belastbar bestätigt, wenn das beobachtete Verhalten reproduzierbar ist und alternative Erklärungen ausgeschlossen wurden. Dazu gehört die Gegenprobe mit True/False-Bedingungen, die Wiederholung unter denselben Rahmenbedingungen und die Prüfung, ob WAF, Caching, Session-Wechsel oder Validierungslogik das Ergebnis verfälschen. Besonders bei Blind- und Time-Based-Szenarien ist diese Disziplin entscheidend.

Die Dokumentation sollte nicht nur Payloads enthalten, sondern den gesamten Kontext: betroffener Endpoint, HTTP-Methode, Parametername, Datentyp, Authentifizierungsstatus, notwendige Vorbedingungen, Basis-Response, beobachtete Unterschiede und Wiederholbarkeit. Ein guter Befund beschreibt außerdem, welche Art von SQLi vorliegt und wie sicher die Aussage ist. Ein vager Hinweis wie „möglicherweise SQL Injection“ ist nur dann vertretbar, wenn die Evidenz tatsächlich unvollständig ist und klar benannt wird.

Ebenso wichtig ist die Abgrenzung zu verwandten Problemen. Nicht jede ungewöhnliche Datenbankreaktion ist SQL Injection. Ein unsicherer Suchparser, ein ORM-Fehler, ein Business-Logic-Problem oder eine unzureichende Zugriffskontrolle können ähnliche Symptome erzeugen. Wenn etwa ein Parameter fremde Datensätze sichtbar macht, liegt möglicherweise eher Idor oder Authentication Bypass vor als eine Injection. Wenn ein Filterwert Shell-Kommandos beeinflusst, gehört der Befund in eine andere Kategorie.

Auch die Frage nach dem Ausmaß muss sauber beantwortet werden. Eine bestätigte Boolesche SQL Injection ist nicht automatisch gleichbedeutend mit vollständigem Datenbankzugriff. Die tatsächliche Ausnutzbarkeit hängt von Rechten, Query-Kontext, Datenbanktyp, Fehlerverhalten und Schutzmechanismen ab. In vielen professionellen Berichten ist es sinnvoll, zwischen bestätigter Injektion, wahrscheinlicher Datenextraktion und nicht verifizierter Eskalation zu unterscheiden.

Wer zusätzlich mit automatisierten Werkzeugen arbeitet, sollte Ergebnisse immer gegen manuelle Beobachtungen spiegeln. Ein Vergleich mit Vs Sqlmap ist in der Praxis interessant, weil Burp und spezialisierte Tools unterschiedliche Stärken haben. Burp ist stark in Kontextanalyse, Request-Manipulation und manueller Verifikation. Automatisierte Extraktionstools sind stark in Tiefe und Geschwindigkeit, sobald eine Schwachstelle belastbar bestätigt wurde. Beides zu vermischen, ohne den Kontext zu verstehen, führt oft zu schlechten Befunden.

Beispiel eins: Ein numerischer GET-Parameter id in einer Detailansicht. Der Basis-Request liefert Produkt 10. id=10 AND 1=1 zeigt weiterhin Produkt 10, id=10 AND 1=2 führt zu „Produkt nicht gefunden“. Das ist ein starkes Boolesches Muster. Nächster Schritt: Wiederholung, Prüfung auf Caching, Variation mit Klammern und numerischen Alternativen. Wenn das Verhalten stabil bleibt, ist die Verifikation belastbar.

Beispiel zwei: Ein Suchfeld in einer POST-Anfrage. Ein einzelnes Apostroph erzeugt keinen Fehler. q=test und q=test' OR '1'='1 liefern identische HTML-Seiten. Erst im JSON-Response eines Hintergrund-Endpoints zeigt sich, dass die Trefferzahl stark ansteigt. Das Frontend blendet nur die ersten zehn Ergebnisse ein, daher war der Unterschied visuell kaum erkennbar. Hier zeigt sich, warum die Analyse des tatsächlichen API-Traffics wichtiger ist als die Browseroberfläche.

Beispiel drei: Ein Sortierparameter sort akzeptiert Werte wie name oder price. Normale String-Payloads werden serverseitig abgelehnt. Ein Test mit ORDER BY-bezogenen Variationen zeigt jedoch, dass bestimmte ungültige Werte zu einem anderen Fehlerbild führen. Das deutet darauf hin, dass der Parameter direkt in eine ORDER-BY-Klausel gelangt. In solchen Fällen ist nicht jede klassische SQLi-Payload sinnvoll; der Kontext ist strukturell eingeschränkt, aber trotzdem potenziell angreifbar.

Beispiel vier: Ein Cookie tenant bestimmt den Mandantenkontext. Änderungen an sichtbaren Parametern zeigen keine Auffälligkeiten. Erst als der Cookie im Repeater manipuliert wird, ändern sich Datenmengen und Antwortzeiten. Eine boolesche Bedingung im Cookie-Wert erzeugt reproduzierbare Unterschiede. Solche Fälle werden leicht übersehen, wenn nur Formulare getestet werden.

Beispiel fünf: Eine API mit JSON-Body und serverseitiger Validierung. Der Wert {"userId":15} funktioniert, {"userId":"15 AND 1=1"} wird als Typfehler abgelehnt. Ein numerischer Ausdruck wie {"userId":15-0} oder eine andere kontextgerechte Variation kann dagegen zeigen, ob der Wert intern als Ausdruck oder strikt als Zahl behandelt wird. Nicht jede API erlaubt solche Tests, aber das Beispiel zeigt den Grundsatz: Payloads müssen zum erwarteten Datentyp passen.

Diese Beispiele verdeutlichen, dass SQL Injection kein starres Rezept ist. Erfolgreiche Tests basieren auf Beobachtung, Kontextverständnis und sauberer Verifikation. Wer Burp Suite nur als Klickwerkzeug nutzt, übersieht die Hälfte. Wer Requests, Zustände und Response-Muster präzise liest, erkennt auch unauffällige Schwachstellen zuverlässig.