Sqlmap on broken apps and WAFs
Tamper scripts, blind injection patience, and when automation stops being the right tool on web tests.
The parameter returned 500 on a single quote. Sqlmap ran for twenty minutes, got blocked by ModSecurity, and the junior tester declared "no SQLi."
Meanwhile the stacked query in the admin export function was waiting in a POST body nobody fuzzed because the WAF only watched GET.
The sqlmap cheat sheet covers the flags. WAF behavior and application weirdness decide if those flags help or get you rate-limited.
Confirm manually before you automate
One quote. One boolean pair. One timing sleep if you suspect blind:
' OR '1'='1
' AND '1'='2
'; SELECT SLEEP(5)--
If the app reflects errors with full stack traces, sqlmap will move fast. If everything is blind boolean with a 200 wrapper, expect hours and a good notebook.
Point sqlmap at a specific request, not the whole site:
sqlmap -r request.txt -p id --batch --level 3 --risk 2
Capture request.txt from Burp with cookies and headers intact. Missing session state is the most common false negative.
Tamper is a loop, not a setting
Behind WAFs I iterate tamper scripts and watch error text:
sqlmap -r request.txt --tamper=space2comment,between --random-agent --delay=1
--delay and --timeout keep you on the network longer but reduce lockouts. Some teams prefer --threads=1 on fragile apps.
When the WAF returns the same block page for every payload, stop sqlmap and switch to manual encoding tests or a different injection point. Automation persistence without new data is noise for the SOC.
Second-order injection
Stored payloads show up in reports, emails, or admin dashboards later. Sqlmap does not discover that arc by default.
Map the flow: where does input land, where does it execute, what request triggers the sink? Sometimes you craft a second request file that references the stored row ID.
This is tedious. That is why it gets missed.
When to stop using sqlmap
- Parameter is clearly parameterized with bound types and no odd casting
- WAF block rate is 100% with no variation after tamper passes
- You already have OS shell via file upload or desync and SQLi is a detour
Sqlmap is a amplifier. If the underlying bug is logic or IDOR, move on.
Document what you tried: tamper list, level/risk, time spent. Clients ask.
FAQ
Should sqlmap be my first step on every parameter?
Usually no. Manual confirmation with a single quote or timing test tells you if SQL injection is plausible before you spray traffic. Sqlmap is loud and easy to log.
What tamper script should I try first behind a WAF?
There is no universal winner. space2comment and between are common starting points. Watch responses and switch when error shapes change. WAF evasion is iterative, not a checkbox.
When is second-order SQL injection worth chasing?
When input is stored and executed later: registration fields, profile updates, log tables. Sqlmap will not guess the delay unless you map the flow manually and point it at the right secondary request.
FAQ
- Should sqlmap be my first step on every parameter?
- Usually no. Manual confirmation with a single quote or timing test tells you if SQL injection is plausible before you spray traffic. Sqlmap is loud and easy to log.
- What tamper script should I try first behind a WAF?
- There is no universal winner. space2comment and between are common starting points. Watch responses and switch when error shapes change. WAF evasion is iterative, not a checkbox.
- When is second-order SQL injection worth chasing?
- When input is stored and executed later: registration fields, profile updates, log tables. Sqlmap will not guess the delay unless you map the flow manually and point it at the right secondary request.