De SQLmap-workflow die eindelijk betrouwbaar werkt (Full Mode → Lazy Mode uitgelegd)

SQLmap lijkt in het begin een simpel hulpmiddel: geef het een URL, wijs een parameter aan en de tool doet zijn ding. Maar zodra je een realistische webapplicatie, een PNPT-lab of een iets complexere POST-request test, merk je dat SQLmap vaak… koppig is. Geen resultaten. Geen tabellen. Niets.

Het duurde even voordat ik doorhad dat SQLmap niet draait om één commando, maar om de juiste volgorde. In deze blog leg ik de workflow uit die voor mij elke keer werkt en die ik nu standaard gebruik in mijn labs en PNPT-training.

Het fundament: de request uit Burp (Raw, nooit Pretty)

SQLmap is maar zo goed als de request die je erin stopt. Daarom begin ik altijd in Burp Suite. Niet in de terminal.

Ik doe mijn actie in de webapp (bijvoorbeeld een formulier versturen) en pak daarna de request uit:

Burp → Proxy → HTTP History → Request → Raw

Alleen het Raw-tabblad toont de request precies zoals de server hem ontvangt. Dat is belangrijk: SQLmap is extreem gevoelig voor formatting, lege regels en zelfs kleine wijzigingen in headers.

Ik kopieer de Raw-request en plak hem in een bestand:

req.txt

Dit bestand moet er ongeveer zo uitzien:

POST /labs/i0x03.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Cookie: ajs_anonymous_id=edb7dd...

product=test

Het belangrijkste detail:
er moet één lege regel zitten tussen de headers en de body.

Zonder dat werkt SQLmap gegarandeerd niet goed.

Full Mode: de fase die je nooit mag overslaan

Dit is de fase waarin SQLmap de applicatie leert kennen.
Full Mode geeft SQLmap de ruimte om:

  • de kwetsbare parameter te ontdekken
  • de database te identificeren
  • tabellen op te sporen
  • een sessie op te bouwen

Zonder Full Mode werkt Lazy Mode niet, en krijg je incomplete of lege resultaten.

Stap 1 — SQLi-detectie

Wanneer ik weet welke parameter mogelijk kwetsbaar is, geef ik die expliciet op:

sqlmap -r req.txt -p product --batch --level=5 --risk=3

Weet ik het niet zeker?
Dan laat ik SQLmap alle parameters testen:

sqlmap -r req.txt --batch --level=5 --risk=3

Hiermee ontdekt SQLmap de injectiepunten, het type kwetsbaarheid en het backend-databasesysteem.

Stap 2 — Databases laten ontdekken

Nu laat ik SQLmap zien welke databases achter de applicatie zitten:

sqlmap -r req.txt --dbs

Typisch zie je:

information_schema
performance_schema
peh-labs

De eerste twee negeer ik altijd: dat zijn MySQL-systeemdatabases.
De database die ik wil hebben is de applicatie-database, in dit geval:

peh-labs

Stap 3 — Tabellen bekijken

SQLmap kent nu de database. Tijd om te zien wat erin zit:

sqlmap -r req.txt -D peh-labs --tables

Stap 4 — Data die je écht nodig hebt dumpen

Nu ik weet welke tabel interessant is (bijvoorbeeld gebruikers), dump ik die:

sqlmap -r req.txt -D peh-labs -T injection0x03_users --dump

Aan het einde van Full Mode weet SQLmap alles wat nodig is om autonoom te werken.
Dit is het fundament van Lazy Mode.

Lazy Mode: wanneer SQLmap het begrijpt

Pas na een goede Full Mode-run begin ik met Lazy Mode. SQLmap weet nu:

  • welke parameter kwetsbaar is
  • welke database actief is
  • welke methodes werken
  • welke tabellen bestaan

Nu heb ik veel minder werk en kan SQLmap zelfstandig beslissingen nemen.

Bijvoorbeeld: de hele database dumpen zonder dat ik iets specificeer:

sqlmap -r req.txt --dump

SQLmap gebruikt simpelweg de kennis uit de sessie.

Wil ik een specifieke tabel dumpen maar geen database opgeven?

sqlmap -r req.txt -T injection0x03_users --dump

SQLmap vult dan zelf in:

  • de database
  • de kwetsbare parameter
  • de aanvalsmethode

Dat is Lazy Mode: efficiënt en snel, maar alleen betrouwbaar als Full Mode eerst is uitgevoerd.

Wanneer moet je terug naar Full Mode?

SQLmap gebruikt sessies.
Verandert de context? Dan moet SQLmap opnieuw leren.

Ik ga terug naar Full Mode wanneer:

  • de URL anders is
  • het formulier anders is
  • de cookie of authenticatie anders is
  • de POST-body is aangepast
  • SQLmap geen kwetsbaarheid meer ziet
  • de sessie-map gewist is

Elke wijziging betekent dat SQLmap opnieuw geïnformeerd moet worden via een nieuwe Full Mode-run.

De essentie van deze workflow

In de kern komt het neer op dit:

  1. Begin altijd met een perfecte Raw-request uit Burp.
  2. Gebruik Full Mode om SQLmap de applicatie te laten leren.
  3. Pas als dat klaar is, kun je Lazy Mode gebruiken.
  4. Verandert iets? Terug naar Full Mode.

Zodra ik deze volgorde begon te respecteren, werd SQLmap niet langer een gokspel maar een betrouwbare, voorspelbare tool die precies deed wat ik wilde.

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *