SQL注入审计应优先全局搜索SELECT/INSERT/UPDATE/DELETE等关键字并结合正则过滤干扰项，重点排查字符串拼接、${}占位符、隐蔽污染源及预编译绕过场景。
直接搜 SELECT、INSERT、UPDATE、DELETE 这类 SQL 关键字，比搜 executeQuery 或 query 有效得多——绝大多数注入点藏在拼接逻辑里，而不是执行函数调用处。
全局搜索 SQL 动词 + 正则过滤干扰项
IDE 或命令行里直接搜大小写不敏感的SELECT、INSERT、UPDATE、DELETE，能快速定位所有硬编码 SQL 字符串。但别只靠关键词匹配，容易被注释、变量名（如 String selectSql）或日志语句带偏。
- 加正则提高精度：(select|insert|update|delete|union)\s+from（注意空格和 from 的组合），可大幅减少误报
- 排除明显非 SQL 的场景：比如文件路径里的 select、类名中的 UpdateHandler、注释行（以 // 或 /* 开头的行）
- Java 项目额外搜 <script> 标签和 ${} 占位符——MyBatis 的 ${} 不走预编译，等同于字符串拼接
盯紧拼接操作符和模板字符串
SQL 注入真正危险的地方不是“用了什么框架”，而是“怎么拼的”。只要用户输入进了 SQL 字符串，就可能出事。 - PHP 中：. 拼接、sprintf、str_replace 后再拼接都算高危
- Java 中：+ 连接字符串、String.format("%s", input)、MessageFormat.format() 看似安全，实则仍是运行时拼接
- Python 中：f"WHERE id = {user_id}"、"%s" % user_id、.format() 全部绕过参数化保护
- Node.js 中：query(`SELECT * FROM x WHERE y = ${input}`) 模板字符串 ≠ 安全，照样执行拼接
别只看 $_GET 和 $_POST，污染源远不止表单
很多审计者卡在“没找到入口”，其实是漏掉了更隐蔽的数据来源。
- PHP：$_COOKIE、$_SERVER['HTTP_REFERER']、$_SERVER['HTTP_USER_AGENT']、file_get_contents 读取的文件内容、甚至数据库查出来再拼进新 SQL 的字段（二次注入）
- Java：request.getHeader("X-Forwarded-For")、request.getRemoteAddr()、Cookie.getValue()、MultipartFile.getOriginalFilename()
- 所有这些变量一旦出现在 SQL 拼接附近，就得顺藤摸瓜：是否做过类型转换？是否经过预编译？有没有中间层封装把拼接藏得更深？
警惕“看似安全”的预编译绕过点
用了PreparedStatement 或 #{} 就万事大吉？不一定。真正的风险常藏在边界上。
- Java 中：String sql = "SELECT * FROM user WHERE status = ? AND type IN (" + typeList + ")"; —— 前半段参数化，后半段 IN 子句仍拼接，照样可注入
- MyBatis：WHERE name LIKE '%${name}%'，哪怕前面是 #{} ，一个 ${} 就让整条语句失效
- 动态表名/字段名：预编译无法绑定表名，SELECT * FROM ${tableName} 是常见高危写法，必须白名单校验
- 宽字节注入：addslashes 在 GBK 环境下可能被绕过，别只看有没有过滤，要看字符集和连接方式是否匹配
真正难发现的不是明摆着的 "SELECT * FROM user WHERE id = " + id，而是跨方法、跨层、被封装了三次之后还带着用户输入进 SQL 的那条链路。审计时得像调试一样逆向追踪变量，而不是只盯着单个函数。
