CodeQL 1.25 Java 分析增强指南：安全查询变化、数据流库改进与源码佐证

静态分析SAST应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载本文基于 CodeQL 仓库中 1.25 版本的 Java 分析变更说明change-notes/1.25/analysis-java.md完整梳理该版本对 Java 分析的所有改动Java autobuilder 的 Gradle 版本检测增强、5 项既有安全查询的行为变化含 1 项减少误报、4 项增加检出以及数据流库data-flow library在嵌套字段读写、JDK Collections 框架和 Spring 框架污点追踪方面的能力扩展并逐一给出当前仓库中对应的查询源码、模型文件与测试用例帮助读者理解每一项变更的落地实现。1.25 版本 Java 分析变更总览该变更说明明确指出version 1.25 的以下改动影响所有应用中的 Java 分析。变更分为三类类别变更概要通用改进Java autobuilder 增强了对更多 Gradle Java 版本的检测能力既有查询变化5 个安全查询调整了识别范围详见下文逐项分析库变化数据流库新增 JDK/Spring 污点建模、支持方法间嵌套字段读写传播、扩展 Java 14 特性支持作为背景1.25 这一系列变更说明还涵盖了 C 分析、C# 分析、JavaScript 分析 和 Python 分析本指南聚焦其中的 Java 部分。通用改进Java autobuilder 增强 Gradle 版本检测变更说明的第一项是The Java autobuilder has been improved to detect more Gradle Java versions.CodeQL 对 Java 项目的分析依赖 autobuilder 自动推断编译参数与 JDK 版本。对于使用 Gradle 构建的项目autobuilder 过去可能无法识别部分非标准的 Gradle Java 版本声明导致提取extraction失败或降级。1.25 版本扩展了可识别的 Gradle Java 版本范围意味着更多使用非主流 Gradle 配置构建的 Java 项目能够直接建立数据库无需手动配置提取器。这是一项面向“开箱即用”体验的改进对所有 Java 项目分析生效。既有安全查询的 5 项变化变更说明以表格形式给出了 5 个既有查询的行为变化其中 4 项增加检出结果More results1 项减少误报Fewer false positive results。下面逐项说明并结合仓库中的实际实现佐证。1. 硬编码凭据查询新增识别 AWSBasicAWSCredentials更多结果查询 Hard-coded credential in API calljava/hardcoded-credential-api-call 现在能够识别 Amazon 客户端 SDK 中BasicAWSCredentials类被硬编码 access key / secret key 使用的情况。查询元数据显示这是 CWE-798 对应的 path-problem 查询security-severity 9.8基于HardcodedCredentialsApiCallFlow污点流做路径报告/** * name Hard-coded credential in API call * security-severity 9.8 * id java/hardcoded-credential-api-call * tags security external/cwe/cwe-798 */ from HardcodedCredentialApiCallFlow::PathNode source, HardcodedCredentialApiCallFlow::PathNode sink where HardcodedCredentialApiCallFlow::flowPath(source, sink) select source.getNode(), source, sink, Hard-coded value flows to $., sink.getNode(), sensitive API call见 HardcodedCredentialsApiCall.ql这个新识别能力是通过sink 模型文件实现的。在 com.amazonaws.auth.model.yml 中两条模型数据将BasicAWSCredentials双参构造函数的两个字符串参数都标记为credentials-key敏感参数extensions: - addsTo: pack: codeql/java-all extensible: sinkModel data: - [com.amazonaws.auth, BasicAWSCredentials, False, BasicAWSCredentials, (String,String), , Argument[0], credentials-key, manual] - [com.amazonaws.auth, BasicAWSCredentials, False, BasicAWSCredentials, (String,String), , Argument[1], credentials-key, manual]配套的测试用例 HardcodedAWSCredentials.java 演示了被命中的典型写法AWSCredentials creds new BasicAWSCredentials(ACCESS_KEY, SECRET_KEY); //sensitive call注释中同时给出修复方向改用 AWS credentials 文件、环境变量或实例/容器凭据。仓库还为测试提供了该类的桩stub定义见 BasicAWSCredentials.java期望输出标记在 HardcodedAWSCredentials.java 测试文件 中// $ HardcodedCredentialsApiCall行标记。对使用者的影响如果代码中存在形如new BasicAWSCredentials(AKID..., wJalr...)的调用升级查询包后将会新增告警。2. 不安全反序列化查询不再报告ValidatingObjectInputStream减少误报查询 Deserialization of user-controlled datajava/unsafe-deserialization 不再把基于org.apache.commons.io.serialization.ValidatingObjectInputStream的反序列化结果报告为漏洞因为 commons-io 提供的这一验证型输入流通过类名白名单/黑名单机制限制了可实例化的类型。这一排除逻辑在查询底层库 UnsafeDeserializationQuery.qll 中可以直接看到定义了SafeObjectInputStreamType类凡是源码超类型链上出现ValidatingObjectInputStream或org.nibblesec.tools.SerialKiller的类型都视为安全private class SafeObjectInputStreamType extends RefType { SafeObjectInputStreamType() { this.getASourceSupertype*() .hasQualifiedName(org.apache.commons.io.serialization, ValidatingObjectInputStream) or this.getASourceSupertype*().hasQualifiedName(org.nibblesec.tools, SerialKiller) } }随后在核心的unsafeDeserialization(MethodCall ma, Expr sink)谓词中ObjectInputReadObjectMethod即readObject与ObjectInputStreamReadUnsharedMethod即readUnshared两类 sink 都附带了同样的安全类型排除条件m instanceof ObjectInputReadObjectMethod and sink ma.getQualifier() and not DataFlow::exprNode(sink).getTypeBound() instanceof SafeObjectInputStreamType对使用者的影响如果你在用 commons-io 2.5 的ValidatingObjectInputStream做受控反序列化升级后相关告警会消失。测试文件 Test.java 中包含了对应的验证代码。3. 弱加密算法查询识别MessageDigest.getInstance更多结果查询 Use of a broken or risky cryptographic algorithmjava/weak-cryptographic-algorithm 及其“潜在弱”版本 java/potentially-weak-cryptographic-algorithm 现在都新增了MessageDigest.getInstance方法的识别。从源码结构看MessageDigest.getInstance属于 JDK 的 JCAJava Cryptography Architecture入口它按算法名字符串动态创建摘要实例。此前查询主要围绕静态可确定的算法常量做判断而通过getInstance传入如MD5、SHA-1等算法名时1.25 之后的库能够对这类字符串参数路径进行分析。仓库中 JCA.qll 对 JCA API 族做了类型化建模可作为理解该能力扩展的基础。对使用者的影响MessageDigest.getInstance(MD5)这类过去可能被漏报的弱摘要用法现在会分别落入weak-cryptographic-algorithm已确认破损或potentially-weak-cryptographic-algorithm疑似破损/有风险两个查询的结果中。4. 世界可写文件读取查询覆盖更多 JDK 文件操作更多结果查询 Reading from a world writable filejava/world-writable-file-read 现在识别更多 JDK 文件操作对应 CWE-732。扩展覆盖意味着通过更多 JDK I/O API如不同入口的File/Files/InputStream构造方式读取权限为world-writable的文件时都能被检出。对使用者的影响使用 JDK 文件 API 读取权限宽松文件的代码路径升级后可能新增告警修复方式通常是收紧文件权限或避免依赖共享可写路径。数据流库变化三类底层能力增强变更说明中“Changes to libraries”一节包含 4 条库级改进它们影响所有使用数据流的安全查询是 1.25 版本中影响面最广的部分。1. JDK Collections 框架及其他 JDK 类的污点建模增强数据流库为 Collections 框架List、Map、Set等和其他 JDK 类补充了更多污点流建模。由于 Java 安全查询普遍以TaintTracking::Global配置驱动底层流的增强会直接转化为更多结果——例如污点字符串存入ArrayList再取出传入 sink 的场景过去可能因缺少容器传播步骤而断链现在可以被跟踪。相关基础库位于 java/ql/lib/semmle/code/java/dataflow/ 目录DataFlow.qll、FlowSteps.qll、FlowSummary.qll等。2. Spring 框架污点流建模增强同样地数据流库为 Spring 框架补充了污点流建模。对依赖 Spring 的项目所有使用数据流的安全查询都可能产生额外结果——典型场景是污点数据经 Spring 的 bean 属性、请求参数绑定器或容器组件传播到 sink。3. 方法间流传播支持嵌套字段读写附示例代码这是变更说明中给出了完整代码示例的一项增强流经方法的污点现在会把嵌套字段读写nested field reads/writes纳入考虑。变更说明中的示例如下class C1 { String f1; C1(String f1) { this.f1 f1; } } class C2 { C1 f2; String getF2F1() { return this.f2.f1; // Nested field read } void m() { this.f2 new C1(taint); sink(this.getF2F1()); // NEW: taint reaches here } }解读这段示例taint字面量先经构造器写入C1的字段f1随后C2通过getF2F1()方法读取另一个对象字段f2的字段f1即嵌套字段读this.f2.f1并把值传出。旧版数据流库在这一跨方法、跨两层对象的链路上会断流导致sink无法被标记1.25 版本起该链路可被跟踪污点成功到达sink(this.getF2F1())。这类增强对“字段搬运器”风格代码getter/setter、DTO 转换尤其重要。4. Java 14 语言特性支持扩展Java 库扩展了对Java 14特性的支持具体包括switch表达式switch expressionsinstanceof模式匹配pattern-matching forinstanceof如if (obj instanceof String s)。这意味着使用 Java 14 语法的项目在被提取和分析时这些结构中的表达式能被正确纳入 AST 与数据流分析避免因为特性不支持导致的漏报或提取异常。变更影响汇总与使用建议查询/库变化方向需要关注的动作java/hardcoded-credential-api-call更多结果排查代码中BasicAWSCredentials的硬编码密钥java/unsafe-deserialization更少误报使用ValidatingObjectInputStream的告警将消失java/weak-cryptographic-algorithm更多结果检查MessageDigest.getInstance传入的弱算法名java/potentially-weak-cryptographic-algorithm更多结果同上疑似弱算法会被单独分级报告java/world-writable-file-read更多结果收紧可读文件的权限与路径选择数据流库JDK/Spring/嵌套字段更多结果安全查询整体结果可能增加需重新评审新增告警Java 14 特性支持覆盖增强Java 14 项目的提取与分析更完整实际使用时的建议升级后全量重跑由于数据流库是横切所有安全查询的库级增强会放大到每一个依赖数据流的安全查询。升级查询包版本后应对项目重新构建数据库并跑完整套件而非只跑上述 5 个查询。区分“新增真阳”与“既有漏报补齐”嵌套字段读写、Collections/Spring 传播这类增强补的是过去断流的真实链路新增结果往往更接近真实漏洞应优先评审。验证查询包版本可通过查询包自身的 changelog如 java/ql/src/CHANGELOG.md 与 java/ql/lib/CHANGELOG.md确认所依赖的查询与库版本再对照本指南判断具体行为差异。总结1.25 版本的 Java 分析变更呈现“查询级微调 库级增强”的双层结构查询层面精准修复了一处误报ValidatingObjectInputStream并补齐了一处 SDK 凭据识别BasicAWSCredentials库层面则通过 JDK/Spring 污点建模、嵌套字段读写传播和 Java 14 语法支持系统性地提升了污点追踪的完整性。对安全工程师而言理解这些变化有助于在升级查询包后正确解读新增与消失的告警对开发者而言文中每个查询变化都指向了仓库中可查证的具体源码、模型与测试文件可作为进一步深入 CodeQL Java 分析实现的入口。赞分享静态分析SAST应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载相关推荐Structured3D完整指南如何用3D结构化数据轻松构建智能室内场景Structured3D完整指南如何用3D结构化数据轻松构建智能室内场景 如果你正在寻找一个能够将室内设计从平面图转化为智能3D模型的强大工具那么Struc静态分析SAST应用安全漏洞扫描代码质量CodeQL 1.24 JavaScript 分析改进全解析查询、库与框架支持深度指南CodeQL 1.24 JavaScript 分析改进全解析查询、库与框架支持深度指南 导读 本文围绕 CodeQL 1.24 版本对 JavaScript/静态分析SAST应用安全漏洞扫描代码质量CodeQL C 分析 1.25 版变更深度解析UnboundGeneric 类型模型精化与集合精确数据流CodeQL C 分析 1.25 版变更深度解析UnboundGeneric 类型模型精化与集合精确数据流 本篇基于 CodeQL 仓库中 1.25 版 C静态分析SAST应用安全漏洞扫描代码质量上一篇Roaring Bitmaps高级用法并行计算、BSI索引和复杂查询优化终极指南下一篇GitHub Stars Manager核心功能详解从自动分析到多维度过滤全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考