CodeQL对Java项目进行SQL注入审计总结

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

一、项目背景

今年参与了一个AI驱动的代码安全审计项目，发现代码库中绝大多数为Java项目，因此开始深入研究针对Java语言的自动化审计方法。传统的人工代码审查方式效率较低，且容易因视觉疲劳而遗漏关键问题。为此，引入了CodeQL这一强大的静态分析工具。

CodeQL的核心机制是将源代码转化为可查询的数据库结构，随后通过类SQL语法对潜在漏洞进行挖掘。整个流程主要分为两个阶段：

1. 执行CodeQL扫描：生成包含可疑漏洞信息的报告文件（通常为JSON或SARIF格式）。
2. 结果拆解与分析：对报告内容进行人工复核，判断每个告警是真实漏洞还是误报。

二、具体实施步骤

2.1 使用CodeQL进行代码扫描

该过程可分为三个关键环节：

1. 创建分析数据库

此步骤相当于将原始Java代码“加工”成CodeQL能够识别和处理的中间表示形式。例如，使用Maven构建项目时，可通过以下命令创建数据库：

codeql database create my-java-db --language=java --command="mvn compile"

• my-java-db

  ：指定数据库名称。

• --language=java

  ：明确目标语言为Java。

• --command

  ：定义项目的编译指令。

• mvn compile

  ：若使用Maven，则填写mvn compile作为编译命令。

• gradle build

  ：若项目基于Gradle，则替换为相应的Gradle构建命令。

这一步至关重要，因为CodeQL依赖编译过程来完整解析代码的语法树和控制流结构。

2. 执行安全查询脚本

利用预设的QL查询规则，在已构建的数据库中查找符合漏洞模式的代码路径：

codeql database analyze my-java-db codeql/java/ql/src/Security/ --format=sarif-latest --output=results.sarif

• codeql/java/ql/src/Security/

  ：采用CodeQL官方提供的安全规则库，覆盖如SQL注入、SSRF等多种常见漏洞类型。

• sarif

  ：输出格式选择SARIF最新标准，便于与其他CI/CD工具集成；也可导出为CSV或JSON格式以适应不同需求。

3. 查看扫描结果

最终生成的报告文件存储了所有被识别出的潜在风险点。

results.sarif

2.2 解析扫描输出结果

初学者面对SARIF或JSON格式的结果可能感到复杂难懂，但实际上只需关注以下几个核心字段即可：

• 漏洞位置：

  location

  提供精确到行、列的文件路径信息，定位问题代码所在。
• 漏洞类型：

  ruleId

  标识系统检测到的具体风险类别，例如

  java/sql-injection

  指示可能存在SQL注入。
• 数据流路径：这是最关键的分析依据。

  codeFlows

  展示了从“源头”（Source，如用户输入参数）到“汇点”（Sink，如数据库执行函数）之间的完整传播链路，是后续人工验证的重点。

三、漏洞真实性判定

需要注意的是，CodeQL的告警仅表示“高风险提示”，并非确认漏洞存在。必须结合上下文进行人工验证。核心验证原则可归纳为四个字：跟踪数据流。重点核查以下三个方面：

1. 注入源是否可信？ 数据是否真正来源于外部不可信输入（如HTTP请求参数）？
2. 执行点是否存在危害？ 目标函数是否会实际触发危险操作（如执行动态SQL）？
3. 传输过程中是否被净化？ 数据在传递路径中是否经过过滤、转义或编码处理，从而消除威胁？

3.1 SQL注入典型场景分析

假设CodeQL报告指出：

UserController.java

文件第35行可能存在SQL注入风险。

查看对应代码片段：

// UserController.java
public String getUserByName(@RequestParam String name) {
    String sql = "SELECT * FROM users WHERE name = '" + name + "'"; // Source: 用户控制的name参数
    return jdbcTemplate.queryForObject(sql, String.class); // Sink: 执行SQL查询
}

审计过程如下：

• 源头分析：

  name

  参数来自HTTP请求，完全由用户控制，属于有效污染源。
• 汇点分析：

  jdbcTemplate.queryForObject

  方法会直接执行拼接后的SQL语句，具备实际危害能力。
• 链路检查：数据从

  name

  直接拼接到SQL字符串中，并传入数据库执行函数，全程未经过任何安全处理，即

  sql

  处无过滤措施。

结论：确认为真实存在的SQL注入漏洞。修复建议：改用预编译语句（PreparedStatement）防止拼接攻击。

3.2 MyBatis框架下的特殊案例

MyBatis因其SQL常定义于XML文件中，具有一定的隐蔽性，但CodeQL仍能有效识别其风险模式。

关键区分点在于占位符使用方式：

• #{}

  ：使用#{} 表示参数化查询，支持预编译，安全性高。

• ${}

  ：使用${} 表示字符串替换，存在拼接风险，易导致注入漏洞。

CodeQL告警示例：

在

UserMapper.xml

的Mapper XML中检测到使用了不安全的 ${} 占位符。

<!-- UserMapper.xml -->
<select id="getUser" parameterType="String" resultType="User">
    SELECT * FROM users WHERE name = '${name}'
</select>

审计流程：

• 源头追溯：

  name

  参数由Java层调用传入，初始值可控。
• 汇点行为：MyBatis在解析

  ${name}

  时，会对${name}进行直接文本替换，等同于字符串拼接。
• 链路完整性：数据未经任何清洗或编码，直接进入SQL模板并被执行。

综上所述，只要满足上述条件，即可判定该处存在可利用的SQL注入风险。

用户可控，即为真漏洞。CodeQL具备识别此类模式的能力，并会触发告警。

四、常见误报案例

CodeQL并非完美无缺，在多种场景下会出现“过度敏感”的情况。以下是三个典型的误报警例，我们将逐一深入剖析其成因。

4.1 参数类型限制有效防御注入

CodeQL报告：在

AdminController.java

第42行，检测到潜在SQL注入风险，数据流显示用户输入被直接拼接至SQL语句中。

查看相关代码：

public String resetPassword(@RequestParam int userId) {
    // userId虽来自用户输入，但其类型为int
    String sql = "UPDATE users SET password='default' WHERE id = " + userId;
    jdbcTemplate.update(sql);
    return "密码已重置";
}

源头分析：

userId

确实来源于HTTP请求参数，属于外部不可信输入，此部分判断准确。

汇点分析：

jdbcTemplate.update(sql)

执行了动态SQL语句，符合SQL注入的危险操作特征，该判定正确。

关键链路分析：
问题核心在于

userId

的数据类型定义——它被声明为

int

基本类型。这意味着Spring MVC框架在接收参数时会强制进行类型转换。若攻击者尝试传入如

1; DROP TABLE users;--

这类恶意字符串，系统将因类型不匹配而抛出异常，无法进入业务逻辑。最终参与SQL拼接的仅可能是合法整数，从根本上杜绝了注入可能。

因此，尽管数据流路径看似危险，但由于强类型机制的存在，实际并不存在可利用的漏洞。

结论：此为假漏洞。CodeQL在追踪数据流时未能充分考虑Java语言的类型安全特性，忽略了基础类型本身所具备的输入过滤能力。

4.2 中间环节已完成输入净化

CodeQL报告：在

UserService.java

第78行，提示用户输入未经过滤即拼接进SQL语句，存在注入风险。

代码示例如下：

// UserService.java
public User findUser(String inputName) {
    // 调用全局安全工具类进行过滤
    String filteredName = SecurityUtils.sanitizeSQL(inputName);
    String sql = "SELECT * FROM users WHERE username = '" + filteredName + "'";
    return jdbcTemplate.queryForObject(sql, User.class);
}

源头分析：

inputName

为前端传入的原始用户输入，确属不可信源，CodeQL识别无误。

汇点分析：

jdbcTemplate.queryForObject

处执行了构造的SQL语句，构成潜在危险汇点，判断成立。

关键链路分析：
CodeQL未识别中间调用的

SecurityUtils.sanitizeSQL

方法。该方法来自公司自研的安全工具类SecurityUtils，其内部的

sanitizeSQL

函数会对输入进行全面处理：包括对单引号

'

转义为

\'

，同时移除或编码双引号、分号、注释符号等；并对

UNION

、

DROP

、

EXEC

等高危关键字进行过滤。经此处理后，变量

filteredName

已不具备触发SQL注入的条件。

然而，CodeQL默认规则库仅能识别标准库中的安全函数（如Apache Commons Lang的

StringEscapeUtils.escapeSql

），对自定义清洗逻辑缺乏语义理解能力，因而仍发出警告。

结论：此为假漏洞。需人工验证中间净化函数的有效性。若确认其具备足够防护能力，则该警报应标记为误报。

4.3 汇点不具备实际危害能力

CodeQL报告：在

FileProcessor.java

第112行，指出用户控制的URL参数可能导致SSRF（服务器端请求伪造）漏洞。

具体代码如下：

public void logFileUrl(@RequestParam String fileUrl) {
    // 仅将URL记录到日志，未发起任何网络请求
    logger.info("用户请求处理的文件URL：" + fileUrl);
    // 其他业务逻辑...
}

源头分析：

fileUrl

为用户传入的参数，完全可控，符合SSRF漏洞的输入特征，判断正确。

汇点分析：

name

问题核心分析

在CodeQL的SSRF检测规则中，可能存在一种情况：所有“接收字符串并进行输出”的函数都被视为潜在的危险汇点。然而，实际上SSRF（服务器端请求伪造）的关键危害在于服务器是否会基于该输入的URL发起网络请求——例如访问内部系统或敏感端口。

以当前场景为例，所涉及的方法仅仅是将字符串写入日志文件，并不具备任何解析URL的能力，也不会触发HTTP或HTTPS请求，更无法连接内部服务。因此，尽管数据流看似到达了一个“汇点”，但该节点并无执行实际危险操作的可能性，属于典型的“伪Sink”。

logger.info

链路追踪与风险评估

从数据源头来看，数据由

fileUrl

直接拼接进日志内容，在整个传递过程中未经过其他处理逻辑。但由于最终的落点仅为日志写入操作，不涉及任何网络请求行为，因此即便存在完整的数据流动路径，也无法构成真正的安全威胁。

结论：识别误报

此案例应判定为假漏洞。根本原因在于CodeQL对“危险汇点”的定义可能过于宽泛，将一些形式上相似但实际无害的操作也纳入了检测范围。在人工审计过程中，必须重点验证数据最终流向的函数是否具备执行特定危险动作的能力。

例如，在SSRF检测中应关注是否调用了如

URL.openConnection

、

HttpClient.execute

等可发起请求的函数；而在XSS检测中，则需确认是否输出到了类似

response.getWriter().write

这样的可执行上下文环境。

五、总结：CodeQL审计实践要点

通过对Java代码中SQL注入及其他类型漏洞的分析（方法论通用），我们可以提炼出以下关键审计心法：

• 工具仅为辅助：CodeQL的作用是发现疑似漏洞线索，最终判断仍需依赖人工分析与上下文理解。
• 聚焦数据流动路径：必须手动追踪

  Source -> ... -> Sink

  这一完整链条。不仅要看起点和终点，中间是否存在过滤、编码或参数化处理等“净化”环节尤为关键。
• 掌握框架机制：熟悉MyBatis中的

  #

  和

  $

  ， Spring的自动参数绑定等特性，有助于快速甄别某些看似危险实则安全的代码模式。
• 警惕三大类误报：
  • 类型安全限制：如输入被限定为整型参数，天然阻断注入可能；
  • 自定义防护逻辑：CodeQL无法识别项目私有安全函数，易导致误判；
  • Sink点误识别：数据虽流转至某函数，但该函数并无执行危险操作的能力。

采用“自动化扫描 + 人工深度研判”的协同模式，能够在大型复杂的Java项目中，高效且准确地定位真实存在的安全缺陷，避免被大量误报干扰判断。

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：java项目 code Java ODE jav