从Java反序列化漏洞题看CodeQL数据流
内容提要
本文介绍使用CodeQL数据流分析挖掘Java反序列化漏洞。作者以Shiro-CTF项目为例，通过查找实现Serializable接口的类定位入口，分析User类实例化及Tools类反序列化方法，确定source（用户可控的request参数）和sink（deserialize的bytes参数），并尝试全局污点分析。最终使用RemoteFlowSource成功追踪数据流，发现LogHandler调用exeCmd可被利用，完成漏洞挖掘。
延伸解读
CodeQL数据流分析的关键：Source与Sink的定位
本文通过一个具体的Shiro-CTF项目，展示了如何利用CodeQL进行Java反序列化漏洞挖掘。核心在于准确识别Source（用户可控输入）和Sink（危险操作点）。作者最初尝试将request参数作为Source，但未成功，最终借助RemoteFlowSource类解决了问题。这提示我们，在CodeQL分析中，Source的定义需考虑多种用户输入形式，而RemoteFlowSource封装了常见输入场景，能有效提升分析覆盖率。
全局污点分析的实践与挑战
文章记录了作者三次尝试全局污点分析的过程，从配置错误到无结果，再到最终成功。其中，导入DataFlow::PathGraph而非TaintTracking是解决路径查询报错的关键。此外，作者指出，即使成功追踪到数据流，也可能无法覆盖完整路径（如request到bytes），需要额外定义isAdditionalTaintStep。这反映了CodeQL污点分析在实际应用中的复杂性，需要不断调试和优化。
从数据流到漏洞利用的衔接
文章不仅关注数据流分析，还强调了如何将分析结果转化为实际利用。作者发现LogHandler类调用了Tools#exeCmd方法，而该方法可执行任意命令，从而构成漏洞利用链。这提醒我们，在漏洞挖掘中，数据流分析只是第一步，还需结合业务逻辑，找到可利用的触发点，才能完整评估漏洞风险。
Q&A
如何使用CodeQL查找实现了Serializable接口的类？
可以使用CodeQL查询：`from Class cl where cl.getASupertype() instanceof TypeSerializable and cl.fromSource() select cl`，该查询会找出项目中所有直接或间接实现Serializable接口的类。
在Shiro-CTF项目中，反序列化漏洞的source和sink分别是什么？
source是IndexController类中index方法的参数request（用户可控），sink是Tools类中deserialize方法的bytes参数（即反序列化函数的输入）。
CodeQL数据流分析中，isSource和isSink谓词的作用是什么？
isSource定义了污点数据可能从哪里流出（即source），isSink定义了污点数据可能流向哪里（即sink）。在自定义Configuration类中重写这两个谓词，CodeQL会分析从source到sink的数据流路径。
在CodeQL中，使用path-problem查询时为什么需要导入DataFlow::PathGraph？
因为path-problem查询需要路径图来展示数据流路径，导入DataFlow::PathGraph可以提供路径图支持，否则会报错“Expected result pattern(s) are not present for query kind 'path-problem'”。
为什么在CodeQL污点分析中使用RemoteFlowSource作为source？
RemoteFlowSource是CodeQL内置的类，涵盖了多种用户输入数据的情况，如HTTP请求参数、Cookie等。使用它可以更全面地识别用户可控的输入源，避免手动定义source时遗漏某些情况。
在Shiro-CTF项目中，如何利用LogHandler类完成漏洞利用？
LogHandler类调用了Tools.exeCmd方法，可以执行系统命令。通过构造恶意序列化数据，在反序列化时触发LogHandler的invoke或toString方法，从而执行任意命令。具体利用方式参考文章提到的《一道shiro反序列化题目引发的思考》。
CodeQL污点分析中，additionalTaintStep的作用是什么？
additionalTaintStep用于定义额外的污点传播步骤，即除了默认的数据流传播外，还可以指定某些操作（如方法调用）也会传播污点。在本文中，作者提到没有涉及additionalTaintStep，但它是完善规则的重要部分。
