如何通过SonarQube静态扫描工具检测代码中的SQL注入隐患？

SonarQube通过追踪“用户输入→未过滤拼接→执行函数”完整数据流识别SQL注入，而非仅检测SQL字符串内容；硬编码不触发告警，MyBatis注解需专用插件支持，漏报多因污点传播中断或扫描配置缺失。

SonarQube 能发现 SQL 注入隐患，但不是靠“看到 SQL 字符串”就报警——它必须确认「用户输入 → 未过滤拼接 → 流向执行函数」这条链路完整存在。漏报或误报，几乎都卡在这三步的某一个环节没识别准。

为什么 String sql = "WHERE id = '" + req.getParameter("id") + "'" 会被标红，而 "WHERE id = '123'" 不会

SonarQube 不分析字符串内容是否危险，而是追踪变量来源和数据流向：

• req.getParameter("id") 被识别为典型污点源（taint source），属于 OWASP 定义的“不可信输入”
• 用 + 或 StringBuilder.append() 直接拼进 SQL 字符串，触发“字符串拼接污染传播”规则
• 如果该字符串后续传给 Statement.execute()、JdbcTemplate.query() 或 knex.raw() 等已知执行点，链路闭合，立即报 java:S2077 或 javascript:S2077
• 硬编码字符串没有变量参与，不构成数据流，自然不告警——哪怕内容是 ' OR 1=1--'

Spring Boot + MyBatis 场景下，@Select("SELECT * FROM user WHERE id = ${id}") 为何常被漏掉

默认扫描根本看不到注解里的 SQL，因为 SonarQube 的 Java 插件不解析 MyBatis 注解语法：

• 必须安装并启用 MyBatis Plugin for SonarQube（非官方插件，需手动下载部署）
• 插件启用后，${id} 才会被识别为危险拼接（对应 MyBatis 的非参数化写法），而 #{id} 不会触发告警
• XML 映射文件中的 同样依赖该插件；否则整段 SQL 对扫描器“不可见”
• 使用 Lombok @Data 或 @Builder 可能导致 AST 解析失败，使 req.getParameter() 参数无法被标记为污点源

为什么已知拼接代码没被扫出来？先查这四件事

不是规则失效，而是扫描环境没把上下文“喂”对：

• 项目未声明语言类型：Maven 子模块缺 <packaging>jar</packaging>，或 JS 项目无 package.json，Scanner 直接跳过目录
• SQL 执行逻辑藏在自研 ORM 或反射调用里（如 Method.invoke(..., "executeQuery")），默认规则不认识，需配置 sonar.java.libraries 或自定义规则
• 问题代码在 src/test/ 下，默认被排除；加 -Dsonar.exclusions= 反向取消排除才能扫测试代码
• 用了非标准入口，比如从 HttpServletRequest.getAttribute() 取参，而非 getParameter() —— 默认污点源列表不包含它，需扩展规则或改用标准方式

修复时别只改一行，要拆掉整条风险链

把 "WHERE name = '" + name + "'" 改成 "WHERE name = ?" 是治标；真正要动的是数据流动路径：

• Java：优先用 JdbcTemplate.query("...", new Object[]{name})，或迁移到 MyBatis 的 #{name} 占位符写法
• Node.js/Knex：禁用 knex.raw("WHERE id = " + req.query.id)，改用 knex.where("id", req.query.id)
• 若必须动态拼字段名（如排序字段），用白名单校验：if (!Arrays.asList("name", "created_at").contains(sortField)) throw ...
• 所有用户输入进入 SQL 前，必须经过参数化或白名单过滤——静态扫描不会替你做运行时防护，它只告诉你“这里可能出事”

最常被忽略的点：规则本身不保证 100% 覆盖，尤其当数据流跨多个方法、经由中间对象传递，或使用非常规框架时，AST 解析可能断裂。与其纠结某处为何没报，不如把参数化当成强制契约，让所有 SQL 构造路径都绕不开占位符机制。