如何审计SQL注入风险

审计 SQL 注入风险，通常分为代码审计、配置审计、运行态检测、流程与防护审计四个层面。下面给你一套可落地的审计方法。

一、代码层审计（最关键）

1. 查找危险拼接方式

重点检查是否存在字符串拼接 SQL：

• ❌ 高风险写法

String sql = "SELECT * FROM user WHERE name = '" + name + "'";

$sql = "SELECT * FROM user WHERE id = $id";

• ✅ 安全写法

PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM user WHERE name = ?");
ps.setString(1, name);

审计要点：

• 是否使用 参数化查询 / 预编译语句
• 是否使用 ORM（MyBatis / Hibernate）但仍在 XML 或注解中写 ${}
• 是否使用 statement.execute() 动态执行 SQL

2. 审计 MyBatis / ORM 配置

常见风险点：

<select id="getUser">
  SELECT * FROM user WHERE name = '${name}'
</select>

❌ ${} 是字符串替换，有注入风险
✅ #{} 才是参数绑定

3. 审计动态 SQL 拼接函数

重点检查：

• ORDER BY
• GROUP BY
• LIMIT
• 表名 / 字段名动态传入

这些无法使用参数化，必须：

• 白名单校验
• 枚举控制

4. 审计输入来源

检查是否对所有外部输入做处理：

• URL 参数
• Header
• Cookie
• JSON Body
• 文件内容
• 第三方回调

二、配置与架构审计

1. 数据库账号权限

• 是否使用 最小权限
• 是否禁止：
  • DROP
  • FILE
  • SUPER
  • EXECUTE

2. 是否开启安全特性

• MySQL：sql_mode=STRICT
• 是否禁用 multi-statements
• 是否限制远程执行

3. 是否使用 WAF / RASP

• WAF 规则是否覆盖常见 payload
• 是否有绕过风险（编码、注释）

三、运行态与黑盒审计

1. 手工测试

常用 payload：

' OR '1'='1
" OR 1=1 --
' UNION SELECT null,version() --

测试位置：

• 登录框
• 搜索框
• 排序参数
• ID 参数

2. 自动化工具

• SQLMap
• Burp Suite
• AWVS / Nessus
• 自研扫描脚本

四、流程与制度审计

• 是否有 代码评审（Code Review）
• 是否接入 SAST（静态代码扫描）
• 是否做 安全测试准入
• 是否有 紧急修复机制

五、审计输出示例

你可以形成类似报告：

风险等级：高
位置：UserDao.java:45
问题：使用字符串拼接 SQL
建议：改为 PreparedStatement 或 MyBatis #{}

如果你愿意，我可以：

• 按 Java / PHP / Python / Node 给你具体审计清单
• 帮你写 SQL 注入审计检查表（Checklist）
• 针对 MyBatis / JPA / Django 做专项审计

你现在是做代码审计、渗透测试，还是合规检查？