怎样审计SQL注入风险

审计 SQL 注入风险，核心目标是发现代码中“用户输入未被安全处理就拼接到 SQL 语句”的地方。下面从方法论 → 具体做法 → 工具 → 报告四个层面说明。

一、审计总体思路

SQL 注入产生的必要条件：

1. 不可信输入（用户、接口、Cookie、Header、文件等）
2. 直接拼接 SQL（字符串拼接、动态 SQL）
3. 缺少参数化 / 过滤 / 白名单

审计重点就是找：

不可信数据 → SQL 语句 的传递路径

二、人工代码审计方法

1. 识别 SQL 执行点

先找所有“执行 SQL”的代码：

• Java：PreparedStatement、Statement、MyBatis、Hibernate
• PHP：mysqli_query、PDO、ORM
• Python：cursor.execute、SQLAlchemy
• Node：mysql.query、sequelize

关键词搜索示例：

SELECT, INSERT, UPDATE, DELETE
execute, query, raw, createSQL
+ 
concat, +, format, f-string, %

2. 检查是否参数化（最重要）

✅ 安全示例：

String sql = "SELECT * FROM user WHERE id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setInt(1, userId);

❌ 危险示例：

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

审计结论：

• 有 ? / 命名参数 → 基本安全
• 有字符串拼接 → 高风险

3. 追踪用户输入来源（污点分析）

关注输入入口：

• URL 参数
• 表单
• JSON 请求体
• Header（User-Agent、Referer）
• Cookie
• 文件上传内容

例如：

Controller.getParameter("id")
  → Service
    → DAO
      → SQL（拼接）

只要中间没有安全处理，就是注入点。

4. 特殊风险点（容易漏）

• ORDER BY / LIMIT

ORDER BY ${column}

参数化无法解决，必须用白名单

• LIKE / IN 需要特殊处理 % 和 _

• 存储过程 / 动态 SQL

EXEC('SELECT * FROM ' + @table)

• 多语句执行

stmt.execute("SELECT *; DROP TABLE user")

三、自动化审计工具

静态代码扫描（SAST）

• Java：FindSecBugs、SonarQube
• PHP：Progpilot、RIPS
• 通用：Semgrep、CodeQL

示例（Semgrep）：

- pattern: $DB.query("SELECT ... " + $INPUT)

动态测试（DAST）

• sqlmap

sqlmap -u "http://site.com?id=1" --risk=3 --level=5

• Burp Suite + Scanner

四、审计输出与修复建议

风险等级判定

修复建议

1. 参数化查询（首选）
2. 输入白名单（表名、字段名）
3. 最小权限数据库账号
4. 关闭多语句执行
5. WAF 仅作为补充

五、一句话总结

审计 SQL 注入 = 找“用户输入”如何进入“SQL 语句”，并确认是否参数化。

如果你愿意，可以：

• 发一段代码我帮你直接审计
• 或说明你用的是 什么语言 / 框架，我给你针对性检查清单