如何审计SQL注入风险点

审计 SQL 注入风险点，核心目标是发现“用户输入未经过滤/参数化就拼接到 SQL 语句中”的地方。下面从方法论、常见风险点、审计步骤、工具与示例几个层面说明。

一、SQL 注入风险本质

风险 = 不可信输入 + SQL 拼接 + 缺少安全处理

安全处理包括：

• 预编译（PreparedStatement / 参数化查询）
• 严格白名单（表名、字段名、排序方向）
• 输入校验（类型、长度、格式）

二、审计范围（从哪里看）

1. 代码层

• DAO / Mapper / Repository
• SQL 拼接字符串（+、format、StringBuilder）
• XML（MyBatis / Hibernate HQL）
• 存储过程调用

2. 接口层

• HTTP 参数（GET/POST/Header）
• JSON / XML 请求体
• 文件路径、文件名

3. 配置与框架

• MyBatis ${} 用法
• 动态表名 / 排序字段
• 是否关闭了框架的安全特性

三、常见 SQL 注入风险点（重点审计清单）

✅ 高风险点

1. 字符串拼接 SQL

String sql = "select * from user where name = '" + name + "'";

2. MyBatis ${}

order by ${column}
where name like '%${name}%'

3. 动态表名 / 字段名

String sql = "select * from " + tableName;

4. IN 语句拼字符串

"id in (" + ids + ")"

5. HQL / JPQL 拼接

"from User where name = '" + name + "'"

6. 存储过程传参拼接

四、SQL 注入审计步骤

Step 1：定位所有 SQL 执行点

• 搜索关键字：
  • Statement
  • createQuery
  • execute(
  • select / update / delete / insert
• MyBatis：Mapper.xml、@Select

Step 2：判断输入来源

• 是否来自：
  • Request
  • Header
  • 配置文件
  • 第三方数据

Step 3：判断是否参数化

✅ 安全示例：

PreparedStatement ps = conn.prepareStatement(
  "select * from user where id = ?");
ps.setInt(1, id);

❌ 不安全示例：

"select * from user where id = " + id

Step 4：检查特殊情况

• ${} 是否用于非白名单字段
• order by / group by 是否可控
• like 是否直接拼接

五、白名单与例外处理（安全写法）

排序字段白名单

if (!allowedColumns.contains(column)) {
    column = "id";
}

IN 参数化

String placeholders = ids.stream()
    .map(i -> "?")
    .collect(joining(","));

六、辅助审计工具

静态代码扫描

• SonarQube（规则：SQL Injection）
• FindSecBugs
• CodeQL

动态测试

• sqlmap
• Burp Suite
• 手工 payload 测试

七、审计输出示例

风险描述
用户登录接口中使用字符串拼接 SQL，参数 username 未过滤。

位置
UserDao.java:45

修复建议
使用 PreparedStatement 或 MyBatis #{}

如果你愿意，可以：

• 发一段 代码 / MyBatis XML 我帮你直接审计
• 指定 语言（Java / PHP / Node）
• 针对 等保 / 行业合规 做专项检查清单