2、实际落地场景层面的局限性

除了技术层面，数据安全、法律合规和成本等因素也使得 GPT 难以用于生产：

a)  企业内部数据安全问题

GPT 这类大型模型目前不支持私有化部署，只能通过 API 接口将代码发送到远程服务进行分析。由于代码是相对敏感的数据，一旦数据出了内网，就有可能造成不可控的数据泄露问题。这就意味着，对于很多行业客户来说，使用 GPT 进行代码安全检测是完全不合规的

b)  计算成本问题

GPT 的每个请求都需要一定的计算资源和时间来得出结果，使用 GPT 进行代码安全检测的成本可能会比现有的 SAST 工具更高。为了弥补这些成本，OpenAI 的 API 是需要付费使用的，收费模式如下表所示，一个大项目每次扫描可能就需要几美元。因此，使用 GPT 进行代码安全检测时，需要考虑高额的 API 成本问题。

虽然GPT技术不能直接替代SAST工具，但利用其能力可以很好的提高SAST产品的使用效果和体验。

基于我们的测试结果，我们认为GPT技术可以在以下场景有较为明确的落地机会，Xcheck产品在后续的迭代中也会新增相关的功能和能力，敬请期待。

1、面向SAST产品用户

a)  提供最佳修复建议

GPT 可以基于 SAST 工具发现的漏洞，分析实际漏洞，并根据代码结构、漏洞类型等因素，提供更贴合实际情况的修复代码和指引。相比固定的修复建议和样例代码，这种个性化的修复建议可以帮助研发人员更快地解决漏洞，提高工作效率。

b)  智能审计助理

在使用 SAST 工具缺陷审计时，可以嵌入 GPT 作为审计助理，通过内置的一系列提示词，既可以智能分析漏洞，提供详细的解释和分析，并确定漏洞是否真实有效，也可以让用户和 GPT 进行交互式对话，例如，开发人员可以询问有关漏洞的危害、常见的利用方式等问题，从而更好地理解漏洞，并快速解决问题。这种智能化的审计助理可以帮助用户更好地掌握漏洞信息，提高审计的准确性和效率，提升用户体验。

c)  辅助编写自定义规则

GPT 可以根据要求提取出代码中的关键信息，并按照指定格式生成 SAST 工具可用的规则。帮助用户更快地生成规则，提高规则的准确性和可用性，降低规则编写的工作量，从而更好地检测潜在的漏洞或者降低误报。

d)  辅助开发安全培训与教育

GPT 技术可以帮助开发安全团队建设企业内部的开发安全知识库及规范，用于为开发人员提供编码规范和安全编程的实践教程

2、面向 SAST 厂商

a)  提高检测能力

虽然在复杂的代码场景中  GPT 的能力不足，但是在简单的代码片段中，它可以准确地理解代码中的语义内容，包括变量类型、函数调用关系、变量值的含义等，相比根据专家经验来提取信息，GPT 给出的信息更为贴合实际情况。SAST 产品可以基于这些信息，在漏洞分析过程中更好地理解代码，从而减少漏报和误报。

b)  生成漏洞样本

GPT 可以根据代码的结构和特征，自动化地生成各种语言、框架和库的漏洞代码，并作为数据集用于 SAST 产品能力评测、算法优化或模型训练等方面。相比传统的数据集构造方式，GPT 生成的样本更贴近真实代码，并且成本更低。

0x00 Xcheck 能力再受认可

近日，由中国信息通信研究院主办的 2022 首届软件供应链安全论坛在北京召开，会上正式发布：腾讯代码安全检查工具 Xcheck 通过了《静态应用程序安全测试工具能力要求》评估。

为了从软件生命周期的源头保障软件供应链安全，自 2019 年以来，中国信通院联合腾讯在内的众多国内知名企业，共同编制了《软件供应链安全保障基本要求》、《可信研发运营安全能力成熟度》、《静态应用程序安全测试工具能力要求》、《交互式应用程序安全测试工具能力要求》等软件供应链安全相关标准。基于以上系列标准，中国信通院对国内多个企业开展了严格的测试与评估。凭借优异的性能和在代码安全实践中的表现，Xcheck 通过了此次静态应用程序安全测试工具的能力评估。

0x01 关于 Xcheck

Xcheck 是腾讯自研的新一代静态应用安全测试（SAST）工具，采用创新的技术路线，基于成熟的污点分析技术与对抽象语法树的精准剖解，实现了快速精准的识别代码风险。

作为新一代的 SAST 工具，Xcheck 解决了传统白盒扫描速度慢、误报高的通病，非常适合集成到 DevOps 的流水线当中使用。当前腾讯内部已全面使用 Xcheck 作为 DevOps 开发环节中的必备检测工具。

针对 Golang、Java、Nodejs、PHP、Python 等常用语言，Xcheck 引擎算法具有非常明显优势，能够实现每秒万行的扫描，速度是同类工具的几十倍。同时，Xcheck 产品经过每年数百万个真实项目统计，工具自身误报率可控制在 10%以下，远低于同类工具。

0x02 新控制台抢先看

Xcheck 一直在持续迭代，在不断提升核心引擎扫描分析能力的同时，控制台也经历了多次重构优化，针对灵活性、扩展性、兼容性、安全性、用户体验等方面进行充分的思考和设计，以满足用户在不同场景下的使用需求。

整体架构

如下图所示，Xcheck 整体采用客户端-服务端的架构，服务端的各个组件均支持水平伸缩，使得 Xcheck 可以支撑海量的分析任务。

使用场景

Xcheck 支持多种使用场景，可以帮助用户在研发的各个阶段发现代码中的安全风险

Web 图形页面

用户可以通过 Web 页面来使用 Xcheck

API 接口调用

Xcheck 提供丰富的 API 接口，供用户进行调用，用户可以基于 API 开发自己的插件

命令行调用

Xcheck 也提供命令行工具：xcheck-cli，只需要简单的命令就能对本地代码进行安全分析

CI/CD 插件

Xcheck 提供常见 CI/CD 平台的流水线插件，如腾讯 Coding、蓝鲸、Jenkins 等，凭借优异的分析速度，能够在制品构建环节发现安全风险，避免漏洞发布到生产环境

本地 IDE 插件

Xcheck 提供常见 IDE 的插件，让用户在开发阶段可以快速发现并修复安全风险

分析模式

Xcheck 支持多种分析模式，包括：

• 全量分析/增量分析
• 并发分析/定时分析

告警形式

Xcheck 支持多种告警通知形式，包括：邮件、短信、企业微信

报告格式

Xcheck 支持导出多种格式的报告，也可以自定义报告内容

辅助功能

Xcheck 希望用户在分析代码、定位缺陷、修复缺陷等操作中，能够获得良好的用户体验，为此，我们提供这些辅助能力

• 实时查看分析进度
• 手动启停分析任务

• 缺陷定位、溯源
• 缺陷介绍与修复指引

• 集中管理任务/项目

• 多维度数据统计与展示

集成扩展

扩展性是一款成熟商业产品的必备能力，Xcheck 支持集成其他工具或作为第三方工具被集成

集成其他工具

Xcheck 提供导入结果功能，可以导入其他工具的扫描结果，作为一次分析记录在 Xcheck 中展示

同时，Xcheck 底层也支持多引擎分析能力，只要实现相关接口，就能在分析时调用其他引擎来进行分析，结果会一并展示在页面中

被集成

Xcheck 提供了丰富的 API 接口，可以通过 API 来调用 Xcheck 来分析代码并获取结果，只要将结果转换为对应平台支持的结果格式并导入，即可在其他工具平台展示

0x03 体验环境正式开放!

即日起，Xcheck 在线体验环境正式开放，

访问体验地址或点击阅读原文即可体验！

https://xcheck.tencent.com/

每个用户默认可以创建 20 个分析任务，可分析代码行数 20w 行

欢迎反馈漏报/误报或提出产品使用上的建议。

0x00 背景

log4j2 和 spring cloud function 爆出严重的安全漏洞，作为静态代码扫描工具，Xcheck 经常会被问到——是否能够发现此类漏洞。

从设计初衷出发，Xcheck 不会对框架代码和工具类代码（第三方 Jar 包）进行有效扫描。

主要有以下原因：

1. 此类代码与上层应用代码相比，通常来说漏洞相对少，且使用到的 Java 语言特性比较复杂，Xcheck 使用的污点传播模型来进行分析，既不够高效，效果也不够理想
2. 工具类代码的入口缺乏统一的特征，如果要通过自定义规则来逐一标注，不利于实现自动化批量分析

尝试自己使用CodeQL，以及参考网上的文章，在不添加专用规则的前提下并没有实现精准的分析出 log4j2 的漏洞。

那么换一个思路，如果只需要得出近似的结果，Xcheck 是否可以做？

近期，基于 Java 引擎进行扩展，实现了对框架代码和工具类代码的分析，能够得出一些近似结果，可以辅助做安全研究的同学用于分析。

0x01 log4j2

分析后，根据lookup函数得出可能的入口函数有 426 个，其中虽然包含了所需要的函数，但是也存在不少干扰数据：

AbstractLogger.debug(Marker, String, Object, Object, Object, Object, Object, )
AbstractLogger.debug(Marker, String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.debug(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.debug(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.debug(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.debug(String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.debug(String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.debug(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.debug(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.enter(String, MessageSupplier, )
AbstractLogger.error(Marker, String, Object, Object, Object, Object, )
AbstractLogger.error(Marker, String, Object, Object, Object, Object, Object, )
AbstractLogger.error(Marker, String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(Marker, String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(String, Object, Object, Object, Object, Object, )
AbstractLogger.error(String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.error(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(Marker, String, Object, Object, Object, )
AbstractLogger.fatal(Marker, String, Object, Object, Object, Object, )
AbstractLogger.fatal(Marker, String, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(Marker, String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(Marker, String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(String, Object, Object, Object, Object, )
AbstractLogger.fatal(String, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.fatal(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, Marker, String, Object, Object, Object, )
AbstractLogger.log(Level, Marker, String, Object, Object, Object, Object, )
AbstractLogger.log(Level, Marker, String, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, Marker, String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, Marker, String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, String, Object, Object, Object, Object, )
AbstractLogger.log(Level, String, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Level, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.log(Message, )
AbstractLogger.readObject(ObjectInputStream, )
AbstractLogger.throwing(Level, T, )
AbstractLogger.trace(Marker, String, Object, Object, Object, Object, Object, )
AbstractLogger.trace(Marker, String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(Marker, String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.trace(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(Marker, String, Object, Object, Object, Object, Object, )
AbstractLogger.warn(Marker, String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(Marker, String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(Marker, String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(String, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(String, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(String, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
AbstractLogger.warn(String, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, )
...
...

Xcheck 能够找到从风险函数到入口函数的调用链路，但是，在不做专用规则的前提下，无法生成与真实路径一致的结果。

在此类较为复杂的场景下，Xckeck可以做的是，根据Debug过程中的实际数据，实时生成可能的调用链路，从而辅助漏洞挖掘：

0x02 Spring Cloud Function

分析后，根据parseExpression函数得出可能的入口函数有 4 个：

FunctionDeployerConfiguration.functionArchiveUnDeployer(FunctionDeployerProperties, FunctionRegistry, ApplicationArguments, MavenProperties, ApplicationContext, )
HeaderEnricher.apply(Object, )
RoutingFunction.apply(Object, )
SimpleFunctionRegistry.FunctionInvocationWrapper.accept(Object, )

其中调试确认 RoutingFunction.apply(Object)是真实触发路径上的函数：

Xcheck 分析出的调用路径与实际结果吻合：

RoutingFunction.apply(Object)
RoutingFunction.route(Object, String)
RoutingFunction.functionFromExpression(String, Object, String)
org.springframework.expression.spel.standard.SpelExpressionParser.parseExpression()

还缺少 doApply 到 post 的调用链条，是由于工具在处理上存在一点小的瑕疵，后续会补齐。

0x03 其它

尝试分析常见的 Java 框架和工具类代码，发现很多之前没有关注到的有意思代码，以下是一些归纳总结。

1. 很多软件都会对配置文件中的内容调用表达式语言进行解析，例如：

   Mybatis3 在处理某些标签时，会调用 OGNL 对标签属性进行解析

   spring-cloud-stream-binder-rabbit 的部分 bindings 配置信息会被 SPEL 解析

   如果你发现有写配置文件或者XML文件的漏洞，可以考虑上述特性的利用

2. 反序列化还是广泛存在于各种软件中，如果有新的反序列化链条被发现，会有很大影响，例如：

   spring-cloud-integration的session数据的持久化逻辑中

3. 代码中的各种注解，很多都用到表达式语言模块进行解析，例如：

   jeecg-boot、resilience4j、spring-batch

0x04 总结

1. 目前主流 SAST 工具对于框架类代码和工具类代码，在不做专用规则的前提下，只能输出近似调用链条的结果

2. 对于调用关系复杂场景（如 log4j2），输出的调用链条更多的意义在于辅助安全研究人员进行调试分析

3. 对于调用关系简单的场景（如 spring cloud function），输出的调用链条比较接近于准确结果

0x00 扩展规则

扩展规则是用来帮助Xcheck检查器去适配各种项目框架的一个解决方案。通过扩展规则模版，简单的填写项目框架中的一些必要信息（如类名，函数名等），即可让Xcheck检查器在扫描该项目的过程中，“认识”私有框架（或忽略某些片段），帮助用户挖掘代码中隐藏的安全风险。

0x01 安装 & 配置

首先，需要私有化部署Xcheck，并在部署的Xcheck网页上申请Token:

申请完成后，记录

• 后台地址URL

• Token

完成上述步骤后，安装私有化交付配套的Xcheck扩展规则客户端（win/mac）并打开：

软件打开后界面如图，共两个Tab：扩展规则/设置

首次打开Xcheck扩展规则客户端，需要完成以下几个步骤：

• 在本地磁盘新建一个目录例如C:/rule/rule，并在扩展规则客户端设置中填写。注：需要用户提前创建目录，并且至少为盘符下两级（包含两级），如不可为C:/rule，否则可能会有文件读写权限问题

• 在设置中填写规则测试服务器，如http://xcheck.com

• 在左侧设置中填写插件鉴权Token（在Xcheck后台页面创建）

完成以上三个步骤即为初始化完成，接下来就可以使用扩展规则客户端的核心功能：

• 添加规则并测试，若生效即可导出规则zip包，通过拖拽等方式上传至Xcheck网页

接下来重点介绍一下核心功能的使用方法。

0x02 添加规则

以一个Java私有项目为例，介绍如何添加规则，帮助检查器识别框架。

注：一些关键信息在代码注释中

package file_testcase;

import com.lib.FileUtils; // 需要适配的包名类名
import java.io.File;
public class FileTest {
    @RequestMapping("test0")
    public String test0(String name0) {
        File f = FileUtils.createFile(name0);
        // createFile是污点传播场景的方法名称
        // name0是污点，且下标是0（第一个参数）
        // 返回类型是java.io.File
        f.delete();
    }
    @RequestMapping("test1")
    public String test1(String name1) {
        FileUtils.deleteFile(name1);
        // deleteFile是危险函数场景的方法名称
        // name1是污点，且下标是0（第一个参数）
        // 此处存在任意文件删除漏洞
    }
}

首先切换到“扩展规则”Tab：

点击上方标题右侧添加规则按钮，然后分为4步：

Step1: 选择Java通用规则模版

Step2: 填写规则名称/规则描述/场景类型

此处为污点传播场景的扩展规则，因此场景类型选择污点传播 

Step3: （关键信息见上述黑框内的代码注释）

•需要适配的包名类名：com.lib.FileUtils•方法名字：createFile•污点参数：0，因为污点name0是createFile的第一个参数•返回类型：java.io.File，因为FileUtils.createFile返回的类型是File

Step4:

确认无误后点击确定按钮，提交即可 

0x03 测试规则

编写好规则之后，扩展规则客户端提供了低成本的规则测试方法：

找到刚才添加的扩展规则那一行，点击右侧测试按钮，自行选择测试样本根文件夹，等待测试结果。前后两次结果不同，表示扩展规则生效。 

0x04 名词解释

• 污点：英文名source，指系统中会使用到的用户可控/不受信任的数据

• 风险（危险）函数：英文名sink，指可能触发危险行为如文件操作、命令执行、数据库操作等行为的函数

0x05 常见问题

•Q: 点击测试之后，按钮一直转圈？•A: 可能扫描项目过大，请替换成较小项目，并重新打开客户端重试

0x06 总结

Xcheck的扩展规则还在持续迭代中，后续会逐步优化从而提高易用性，减轻用户的使用成本，敬请期待。

0x00 C/C++安全检查引擎

Xcheck的 C/C++ 安全检查引擎，能够在不编译源码的情况下对 C 和 C++ 源代码进行安全检查，检测SQL注入、命令注入、SSRF、路径穿越、缓冲区溢出、格式化字符串漏洞等漏洞。

作为最古老的“现代”编程语言，C/C++ 的框架和库极为丰富，当前 Xcheck 优先支持了业界和公司内部的主流开发框架，如 gRPC-C++ 、tRPC-C++、SPP、Svrkit、TARS 等，同时，用户也可以编写自定义规则，快速适配自己的框架。

0x01 不编译代码进行安全检查

随着多年的社区发展，C 和 C++ 的版本多、语法杂，各项目使用的编译器、编译参数、编译环境配置等均不统一，导致大部分 C/C++ 源代码不能拿到就直接编译。

传统 SAST 工具针对 C/C++ 代码的安全检查，强依赖于编译的中间产物进行扫描，编译失败就无法正常执行，用户在使用时，需要配置 SAST 工具可用的编译脚本，或者将源代码改造为 SAST 工具可以直接编译的代码，增加了使用成本。

Xcheck 的 C/C++ 安全检查引擎，采用了自研的 Xparser 语法解析器，可以在 不编译代码 的情况下模糊解析出代码的语法信息，再结合 Xcheck 的语义分析算法和污点传播算法，高效快速地发现代码中的安全风险。

Xparser 支持在各类无法编译的场景模糊解析语法，最大程度保留语法信息，如：缺少相关头文件/库、编译时替换字符、特殊编译器语法等。

场景1：缺少相关头文件/库

include 的库不在代码中，会导致代码中存在未知的宏定义

TEST(xxx, xxx){}     // 单测代码，像 function 声明
for_each(a, b, c){}  // 封装了一层的 for 循环
__END_DECLS          // 未知语句块

也可能存在未知的类型

XXClass * a          // 未知类型，造成歧义，声明或者相乘

场景2：编译时替换字符

某些项目的代码会在编译时，编译脚本替换源代码中的关键字

namespace ${APP} {   // 编译时替换 ${APP} -> xxx_project
...
} 

场景3：特殊编译器语法

一些编译器会有特殊的语法

int $a = 1;         // GNU C 支持标识符中包含 $

0x02 精准解析语法特性

和 Xcheck 的其他引擎一样，为了能够精准的发现安全漏洞，Xcheck 对 C/C++ 的各类语法特性都做了支持，包括：Template、流式操作、命名空间、指针等。

Template语法

Template（模板）是 C++ 中比较有代表性的语法之一，主要特点如下：

• 语法复杂：包括函数模板的声明和调用、类模板的声明和调用，类外声明模板函数、模板类外定义模板函数，模板特化等
• 编译器特殊处理：编译器在编译时，会根据传入参数的具体类型去实例化对应的函数/类

函数模板声明：

声明一个名为 Foo 的函数模板，函数中的 T 在这个时候是未知的

template <typename T>
T foo(T b){
 T a = b;
 return a;
}

函数模板调用：

调用 Foo，这里因为 Foo 是函数模板，会先用 a 的类型  int，去实例化一个真实的函数，然后调用

int a = 1;
Foo(a);         // 实例化出 int Foo(int a){}

double b = 1.1;
Foo(b);         // 实例化出 double Foo(double a){}

string c = “test”;
Foo(b);         // 实例化出 string Foo(string a){}

类模板声明：

声明一个名为 Pair 的类模板，类中的 T 同样是未知的，类中有一个 value 属性和构造函数

template <class T>
class Pair {
 public:
 T value;
 Pair(T v): value(v) {
 }
}

类模板调用：

显示传入模板中需要的类型，这里传入了一个 int 类型，这时候会实例出一个真实的类，类中的 value 是 int 类型的，接着用这个类实例化一个对象，执行 Pair 的构造函数

Pair<int> a (1);

0x03 漏洞案例

以真实业务代码为例（已脱敏）

1. 这是 SPP 框架的一个入口函数，其中 req 参数为外部传入的污点，经过参数提取和字符串拼接后，污点传递给 select_sql，然后作为参数传给 LogServicesInstance.exec_query

int GetXXMsg::execute(const DbProxy::CommonReq &req, DbProxy::CommonRsp &rsp)
{
    const DbProxy::GetXXReq &real_req = req.getservicelogtopic();
    std::string select_sql = "SELECT xx FROM xxxxx "
                             "WHERE uin=" + Util::toString((unsigned long)real_req.uin()) +
                             " AND name= '" + real_req.name() + "'" +
                             " AND tag = '" + SERVICE_LOG_TAG + "'";
    std::vector<struct XXX> topic_rows;
    int ret = LogServicesInstance.exec_query(select_sql, topic_rows,...);

2. LogServicesInstance 实际上是一个宏

class LogServicesDb : public MysqlClient
{};
#define LogServicesInstance   (CSingleton<LogServicesDb>::instance())

Xparser 在解析 C/C++ 源代码时会调用自研的预处理模块，将该代码宏展开为：

int ret = (CSingleton<LogServicesDb>::instance()).exec_query(select_sql, topic_rows,...)

3. CSingleton 是一个单例模式的模板类，传入 LogServicesDb，再调用 instance 方法，就会返回 LogServicesDb 的一个实例

template<class T>
class CSingleton {
   public:
      static T& instance();
};
template<class T>
T& CSingleton<T>::instance(){
   static T _instance;
   return _instance;  
}

4. 在 2 中可以知道 LogServicesDb 实际上继承了 MysqlClient

class MysqlClient
{
    public:
        ...
        int exec_query(std::string& sql, ...);
    private:
        ...
        xxxxx::MySQLPool _pool;
}

具体的方法实现是在类外定义的

int MysqlClient::exec_query(std::string& sql, ...)
{
    if (interface <= 0)
        return _pool.exec_query(sql, row_vec);
    else
    {
        ...
    }
}

5. 经过精准的语义分析和污点传播，Xcheck 检查到污点传入了 _pool.exec_query(sql, xx)，而 _pool 是 xxxxx::CSyncMySQLPool 的实例， Xcheck 已将该类的 exec_query 方法标记为漏洞函数，故此处触发 SQL 注入漏洞。

涉及到的语义：

• 类声明/继承/实例化
• 类模板声明/实例化
• 函数调用
• 赋值语句
• 字符串拼接
• ...

0x04 测试数据

Xcheck 在 8 月内部灰度上线了 C/C++ 检查引擎，同时也和多个安全团队联合进行了测试，相关数据如下：

0x05 总结

Xcheck 的 C/C++ 引擎还在持续迭代中，后续会逐步支持更多主流框架和漏洞，同时也会尝试对开源项目进行静态代码分析，敬请期待。

0x00 漏洞挖掘

新增两个CNVD

近期，使用了Xcheck Java引擎对一些开源网站系统进行检查，最终发现了若依管理系统和MCMS系统两个安全漏洞。

漏洞挖掘过程

Xcheck检查
使用Xcheck挖掘漏洞十分简单，下载项目源码之后，上传至Xcheck进行检查，喝口水的功夫，就出结果了。

结果分析
这里对若依管理系统发现的漏洞进行简单分析：从检查结果总览可以看出发现了两个高风险的SQL注入漏洞，其中一个漏洞污染链如下（没展示报告中代码细节），最终在mybatis SQL文件中触发SQL注入漏洞

漏洞验证
本地搭建测试环境，验证结果如下：

0x01防护识别

防护识别是指Xcheck能够识别出用户自定义的安全防护代码，检查时不会将做过防护的漏洞上报为风险。
如下图，在若依管理系统的检查结果中，发现了三个做了安全防护的漏洞（confidence为0）。防护信息中显示在CommonController.java中46行做了安全防护。

来验证下检查器识别到的防护是否正确,可以看到在CommonController.java46行出对文件名做了合法性判断。

通过判断文件名中是否包含..

工具类StringUtils继承自apache库的StringUtils类

所以，检查器识别出的安全防护是准确的。
可以看出，Xcheck能够在没有提前适配的情况下，主动去识别用户的安全自定义防护逻辑，从而降低误报！

SAST 简介

SAST 工具的优势

SAST 大规模应用的障碍

误报多

速度慢

速度慢的原因

Xcheck 的解决方案

降低误报

0x00 JumpServer与漏洞介绍

JumpServer是一个开源的堡垒机，server端使用python编写开发，开源地址在https://github.com/jumpserver/jumpserver。

在上周五被爆出一个远程命令执行漏洞，这个远程命令执行主要由一个log日志跨目录读取引发。

漏洞影响版本：

• < v2.6.2
• < v2.5.4
• < v2.4.5
• = v1.5.9
• >= v.15.3

0x01 漏洞详情

漏洞主要由两部分组成：

1. 跨目录读取log日志来获取token
2. 利用获取的token构造ws通信payload，在jumpserver所管理的服务器进行命令执行。

本文主要对1部分进行分析，也是漏洞利用的前提关键条件。

log日志读取漏洞触发主要在apps/ops/ws.py 文件，关键代码为task_log_f = open(log_path, 'rb') ，位于wait_util_log_path_exist函数。

  def wait_util_log_path_exist(self, task_id):
      log_path = get_celery_task_log_path(task_id)
      while not self.disconnected:
          if not os.path.exists(log_path):
              self.send_json({'message': '.', 'task': task_id})
              time.sleep(0.5)
              continue
          self.send_json({'message': '\r\n'})
          try:
              logger.debug('Task log path: {}'.format(log_path))
              task_log_f = open(log_path, 'rb')
              return task_log_f
          except OSError:
              return None

0x02 日志读取漏洞调用链分析

1. apps/ops/ws.py的receive函数引入污点

污点由websocket通信进来。查阅相关文档，函数receive中的text_data为用户可控的参数。

2. 污点传递到handle_task, 又将污点传递给read_log_file

3. read_log_file函数再传递到上文提及的wait_util_log_path_exist函数

日志读取返回也是在此处，循环读取4096btypes，然后sleep(0.2)。

4. wait_util_log_path_exist 中通过get_celery_task_log_path获取路径，get_celery_task_log_path方法直接将污点拼接到所要读取的日志路径当中，造成一个跨目录的问题

0x03 Xcheck自动化审计

xcheck检查结果如下，仅耗时2s:

这是我们适配channels.generic.websocket 之后的检查结果，这个适配添加过程仅仅是将receive 方法的参数设置成污点，剩下的这长长的调用链都可由xcheck自动化完成。

漏洞复现：

1. 本地搭建成功

2. 漏洞验证

实际利用可读取默认log目录/opt/jumpserver/core/logs下的日志文件获取token等敏感信息。

漏洞利用进行命令执行的部分本文不进行赘述，可参考《Jumpserver 任意命令执行漏洞分析报告》这篇文章。

0x04 参考

• 修复建议：《JumpServer 远程命令执行漏洞风险通告，腾讯安全全面检测》 https://mp.weixin.qq.com/s/yB7pSlG2ZFz65JDf5A-1Mg
• 《Jumpserver 任意命令执行漏洞分析报告》https://mp.weixin.qq.com/s/mJ7nY1r2QWeNzaRK6aZViA

想了解Xcheck更多信息或者代码安全审计相关技术欢迎关注xcheck公众号~

0x00 禅道简介

ZenTaoPMS（ZenTao Project Management System），中文名为禅道项目管理软件。

禅道项目管理软件基于自主研发的PHP开发框架——禅道PHP框架开发而成。

禅道有四个版本，分别是开源版，专业版，企业版和集团版。

本文审计对象为禅道开源版，版本为v12.4.3。

0x01 禅道目录结构与路由

项目根目录如下图：项目根目录

其中framework目录包括具体路由分发的实现，这里细节不再展开，可参考《禅道pms-路由及漏洞分析》这篇，链接在文后。

至于module目录，则是禅道应用程序具体功能的实现，包含60多个模块。

以其中一个模块为例，主要看control.php，model.php这两个文件。

control.php中的函数可被用户请求直接访问到，下图为admin/control.php中的register函数，则访问请求为index.php?m=admin&f=register&from=1，请求中的from的值赋值给$from。

即m为对应module，f为对应方法，方法的参数也与请求中的参数一一对应。

0x02 CNVD-2020-65242 后台任意文件下载

漏洞入口位于file模块control.php中的sendDownHeader函数，

public function sendDownHeader($fileName, $fileType, $content, $type = 'content')
  {
    $this->file->sendDownHeader($fileName, $fileType, $content, $type);
  }

其中，$this->file即当前模块目录中model.php中类对象的实例，这里为fileModel。

漏洞代码位于922行，文件读取$content并输出，进入这个逻辑需要$file变量为字符串值file.

所以漏洞触发为index.php?m=file&f=sendDownHeader&fileName=2&fileType=1&content=/etc/passwd&type=file

若存在open_basedir限制，可读取数据库配置文件：index.php?m=file&f=sendDownHeader&fileName=2&fileType=1&content=./../../config/my.php&type=file。

0x03 后台im模块downloadXxdPackage函数任意文件下载

触发链接：index.php?m=im&f=downloadXxdPackage&xxdFileName=../../../../../../../../../etc/passwd

0x04 Xcheck适配与分析检查

禅道使用的框架是自研的一套禅道PHP框架，具有一定的复杂性，不在xcheck默认支持框架范围内。

对于框架的适配，xcheck这边均采用人工经验赋能检查器的思路进行相关规则的添加。从人工审计出发，将污点分析理论的关键点传递给检查器，使检查器能够理解新框架中的代码。

以本文的禅道为例，经过前面对路由请求的分析，可得以下人工审计经验：

1. module目录下子模块中control.php函数可被用户直接访问，函数参数为用户请求参数，即污点
2. file模块中$this->file即同模块当中的model.php中的fileModel对象，client模块中$this->client为同模块中model.php 中的clientModel对象，其他模块也类似
3. 模块control.php中继承的父类control存在loadModel方法，loadModel方法为动态调用对象，如 $this->loadModel("file") 则调用的为file模块中model.php的fileModel对象

通过将以上经验赋能给检查器，做一个禅道框架的简单适配，就可轻松检查发现项目中的安全漏洞。若由人工审计来做，对60多个子模块逐个审计，工作量可想而知。

0x05 最后

对禅道的代码检查发现问题数较多，对于其中部分与业务密切相关导致利用失败的或者存在一定利用条件的，本文不再赘述。

由于是简单适配，相关分析和提及安全问题仅供参考，有兴趣的小伙伴可发送消息后台一起讨论交流。

0x06 参考

• 《禅道pms-路由及漏洞分析》https://www.anquanke.com/post/id/160473

• 《【组件攻击链】禅道项目管理系统(ZenTaoPMS)高危漏洞分析与利用》https://mp.weixin.qq.com/s/LIugWEiETPwYmmLwZLe7Ag

想了解Xcheck更多信息或者代码安全审计相关技术欢迎关注xcheck公众号~

OpenRASP介绍

OpenRASP即应用运行时自我保护，“可直接注入到被保护应用的服务中提供函数级别的实时防护，可以在不更新策略以及不升级被保护应用代码的情况下检测/防护未知漏洞”——https://rasp.baidu.com/  《OpenRASP 官方文档》

OpenRASP防护效果

1. 环境搭建
   本文以Tomcat服务器为例，参考官网 快速接入——Tomcat服务器文档（https://rasp.baidu.com/doc/install/manual/tomcat.html）

2. 防护示例
   对靶场项目进行SQL注入攻击，根据burp返回报文，显示已经被OpenRASP拦截。

绕过OpenRASP进行SQL注入

操作：新增一个参数（参数名为一个无意义的参数名即可），注意该参数需要在被注入参数的前面，以保证rasp先检测该参数。被注入参数中添加一段注释如下，新增参数值为注释的一部分（长度大于等于8即可）。

如下图，盲注成功：

对于请求content-type为multipart的，也是同理，新增额外参数来绕过。但是对于json格式的请求报文，除了上述的请求参数污染外，还可以通过添加或者修改header（User-Agent/X-Forwarded-For/Referer）内容，从而绕过open rasp检测。

绕过分析

调试分析源码plugins/official/plugin.js文件。在_run方法中，使用RASP.sql_tokenize方法会将执行的SQL语句解析成一个个token，解析的结果中不会包含注释部分。

  if (algorithmConfig.sql_userinput.pre_enable && ! sqliPrefilter1.test(value)) {
       return false
  }
  // 懒加载，需要的时候初始化 token
  if (raw_tokens.length == 0) {
      raw_tokens = RASP.sql_tokenize(params.query, params.server)
  }
  if (is_token_changed(raw_tokens, userinput_idx, value.length)) {
      reason = _("SQLi - SQL query structure altered by user input, request parameter name: %1%", [name])
      return true
  }

如下图，调试可观察到程序将SQL语句解析为12个token，语句中注释的部分被忽略。

然后进入is_token_changed方法中。该方法作用主要是：找到用户输入参数值在要被执行的SQL语句（已经解析成token，里面不包含注释内容）的位置，所以只要该参数属于SQL语句注释的内容，这里的start值就不会被后续赋值，始终为-1。在后面会产生数组越界，从而程序异常终止。从而绕过open rasp检测。

最后

使用OpenRASP并不能保证应用程序绝对的安全，代码安全才是治本之道。本文仅对绕过OpenRASP进行SQL注入进行研究，但是从绕过原理上看，其他漏洞防护也可用相似的方法绕过，暂未验证。抛砖引玉，有兴趣的小伙伴欢迎发送消息后台交流~

想了解Xcheck更多信息或者代码安全审计相关技术欢迎关注xcheck公众号~

0x00 漏洞概述

影响版本：ecshop4.1.0及以下
是否需要身份认证：否，前台漏洞
漏洞类型：SQL注入
CNVD编号：CNVD-2020-58823，https://www.cnvd.org.cn/flaw/show/2454613
漏洞来源：xcheck代码安全检查
源码获取：https://www.ecshop.com/，登录注册下载，最新版本为4.1.1(已修复)。

0x01 漏洞详情

漏洞代码：/source/ecshop/delete_cart_goods.php,16行

$_POST变量直接传入sql语句进行拼接，再进入数据库查询，触发漏洞。

如果有对ecshop进行过代码审计的话，应该会知道在includes/safety.php存在个waf，但是在这个版本并没有生效，这里漏洞触发可以不进入这里的过滤防护逻辑。

本地搭建验证如下，配置默认是开了报错，线上的测试环境也是，不存在报错的话可以通过盲注验证。报错注入的截图证明如下。

漏洞修复：对请求参数进行过滤。

0x02 注入漏洞利用分析

思路一：获取注入获取管理员密码md5

ecshop默认密码不加盐，所以可以直接注入找到ecs_admin_user表获取管理员密码的md5.

思路二：获取管理员session

如果管理员使用了较为复杂的密码，md5解不出来时，可以考虑获取session。即cookie中ECSCP_ID的值。
登录用户的session存在ecs_sessions表，但是只有sesskey。

代码中登录成功后cookie设置：setcookie($this->session_name, $this->session_id . $this->gen_session_key($this->session_id), 0, $this->session_cookie_path, $this->session_cookie_domain, $this->session_cookie_secure, TRUE);.

其中$this->session_name 就是ECSCP_ID， $this->session_id . $this->gen_session_key($this→session_id)就是最终cookie的值，数据库中sesskey对应的是$this->session_id，至于后半部分是通过gen_session_key这个函数生成。

function gen_session_key($session_id)
    {
        static $ip = '';
        if ($ip == '')
        {
            $ip = substr($this->_ip, 0, strrpos($this->_ip, '.'));
        } 
        return sprintf('%08x', crc32(ROOT_PATH . $ip . $session_id));
    }

后半部分gen_session_key通过ip和ROOT_PATH来确认，ip也在session表中可以找到，至于ROOT_PATH，可以通过猜测或者部分路径的报错拿到。最后拼凑到的，就是最终的cookie。

思路三: ecshop/api/client/includes/lib_api.php 写入shell

api/client 的访问需要登录，位于ecshop/api/client/includes/lib_api.php的API_UserLogin接口。这里登录是直接校验密码md5，也就是说当思路一解不出来时，这里也能用上密码的md5。

登录成功后访问api接口，可以利用一个任意写入漏洞。触发点为upload_image函数，在API_AddBrand函数中被调用。

最后登录成功后写入文件的payload为：

URL: http://localhost/ecshop/api/client/api.php
POST: Json= {"Action":"AddBrand","brand_name":"test","brand_logo":{"Data":"xx,"Type":"xx"}}

最后getshell

ecshop后台能读写文件的地方，大多做了限制。现在找到能shell的地方，就是在利用smarty模板渲染来执行代码，可参考ecshop原来爆过的一个任意代码执行漏洞，这里简要概述下。

1. 首先插入代码，在模板管理里找到邮件模板，修改为{str:{\$asd'];assert(base64_decode('ZmlsZV9wdXRfY29udGVudHMoJ3hjaGVjay5waHAnLCc8P3BocCBwaHBpbmZvKCk7Jyk7IA=='));//}x

2. 再回到管理密码找回页面，点击确定，即可触发。

分析如下：$template['template_content']为我们插入的数据。

跟进fetch函数，进入eval函数前还有个fetch_str函数，会对payload进行一些过滤，这里不展开细节。

_eval函数将过滤后的字符串拿过来进行执行。由于是无回显，所以payload采用的是写文件的方式。

0x03 结束语

这个前台SQL注入较为简单，但是危害较高，只通过一些简单字符匹配规则去找类似这种漏洞的话，整个项目大概有三百多个，其中前台的风险大多被单双引号包裹且开了GPC防护，对xcheck来说仅需要加一点字符串比对处理即可筛选找出。

这个漏洞由xcheck检出，已第一时间上报CNVD，现在官网版本已经修复。本文仅限技术研究与讨论，严禁用于非法用途。

0x04 参考

Ecshop 2.x/3.x SQL注入/任意代码执行漏洞分析：https://www.secrss.com/articles/4965

想了解Xcheck更多信息或者代码安全审计相关技术欢迎关注xcheck公众号~

Java安全检查引擎

Xcheck的java安全检查引擎支持Spring RequestMapping、JAX-RS、WebService和Java Servlet几种常用web接口的代码安全检查，目前内部误报率数据统计低于10%，扫描速度1w+行每秒。

覆盖漏洞类别包括但不限于以下：

• 系统命令注入
• 模板注入
• 反序列化
• 路径穿越漏洞
• SQL注入
• XML实体注入
• XPATH注入

OWASP Benchemark评测结果

OWASP benchmark是OWASP组织下的一个开源项目，又叫作OWASP基准测试项目，它是免费且开放的测试套件。可用来评估那些自动化安全扫描工具的速度、覆盖范围和准确性。

从上图结果可以看出，对注入类漏洞（LDAPI、PATH Traversal、SQLI、XPATHI、CMDI）Xcheck的召回率均达到了100%。

从上图可以看出，对于基于benchmark评测，Xcheck的测试结果是与现有的某些商业化的代码检查工具的测试结果是不相上下的。

Apache Ambari任意代码执行漏洞：CVE-2014-3582 检测

在对内部项目的代码检查中，发现一个项目存在命令注入漏洞，经过查找，确认是已经披露出来的Apache Ambari任意代码执行漏洞——CVE-2014-3582。

漏洞分析如下：

1. 污点引入，java/org/apache/ambari/server/security/unsecured/rest/CertificateSign.java，63行

2. 跟进signAgentCrt函数，java/org/apache/ambari/server/security/CertificateManager.java，187行。在192行将污点传递给agentHostname，在239行agentHostname传递给agentCrtName，然后又到scriptArgs当中。

3. java/org/apache/ambari/server/security/CertificateManager.java，271行。调用runCommand函数，然后触发漏洞。

整理数据流分析图如下：

最后

Xcheck的Java引擎还在不断优化提升过程中，期间也发现不少开源项目的0day漏洞，待修复之后会分享出来，敬请期待。

想了解Xcheck更多信息或者代码安全审计相关技术欢迎关注xcheck公众号~

Golang安全检查引擎

Go语言近几年开始越来越流行，凭借其强大的性能和跨平台的优势，对web和后台开发都是一个不错的选择。Xcheck支持Golang的代码安全检查，覆盖常用web框架，包括golang内建的net/http，以及一些流行的第三方web框架：gin，iris，mux，httprouter，fasthttp，fasthttprouter等。自然，也可以通过Xcheck的扩展能力，来适配其他框架。目前覆盖的Web漏洞类型包括但不限于以下：

• 命令注入
• SQL注入
• URL跳转
• 路径穿越
• SSRF
• ...

检测数据

我们在github上面选取了10000个golang项目进行安全检查，发现其中存在风险的项目182个，风险数317个，误报数19个，整体误报率6%左右。

使用Xcheck扫描内部golang项目19w次任务，其中耗时小于1分钟的项目占18万个，换句话说，90%以上的项目都在1分钟内扫描完毕。

检测案例

SQL注入漏洞

这是整理的部分golang进行sql查询时不正确地使用方式会引发风险的函数。

以国外安全团队NemoSecurity在github的一个golang靶场项目GoVWA(https://github.com/0c34/govwa.git)为例：

靶场中共存在两个sql注入漏洞，以其中一个为例，触发漏洞的所用的package为database/sql。数据流分析如下：

1. /vulnerability/sqli/sqli.go 72行 引入污点：uid := r.FormValue("uid")
2. /vulnerability/sqli/sqli.go 74行 获取一个profile的实例p：p := NewProfile()
3. /vulnerability/sqli/sqli.go 79行 调用p的方法UnsafeQueryGetData: err := p.UnsafeQueryGetData(uid)
4. /vulnerability/sqli/function.go 37行 拼接sql语句
5. /vulnerability/sqli/function.go 41行 将拼接的sql参数进行查询。

这里我们也使用了github开源高星项目的gosec代码扫描工具进行检测，很遗憾，工具报错了未能得到结果。

命令注入

对于命令注入，Golang引擎原生支持识别os/exec相关的函数和结构体，包括exec.Command，exec.CommandContext以及相关实际执行函数CombinedOutput/Output/Run/Start。

举一个实际项目的案例，图中317行是一个污点，318行是一个Cmd的实例，339行才是真实执行。值得注意的是，如果没有执行Start函数（319行），是不会报漏洞的。

URL跳转和SSRF

对于扫描引擎来说，这两类漏洞的检测除了支持一些相关触发函数的识别外，难点在于对url字符串的精确判断和分析，如果能做到这个效果，就能降低一些误报。

来看一个SSRF案例，Xcheck识别出这是一个SSRF问题，但是在最后的触发点，“过滤”字段提示这个url的host部分不可控制，其实无法造成危害，对于这种无法被利用的风险，Xcheck给出的漏洞级别是“提示（可忽略）”，这也是Xcheck精准识别的一个体现。

结束语

随着golang在web后台开发等领域越来越流行，goalng的安全是个不可忽视的关注点。网上关于golang的代码审计文章也较少，后续xcheck也会持续输出golang代码审计的一些文章，共同学习进步。

想了解Xcheck更多信息或者代码安全审计相关技术欢迎关注xcheck公众号~

1 Xcheck介绍

Xcheck是一个由腾讯公司CSIG质量部代码安全检查团队自研的静态应用安全测试(SAST，Static application security testing)工具，致力于挖掘代码中隐藏的安全风险，提升代码安全质量。

Xcheck现已支持Golang、Java、Nodejs、PHP、Python 五种语言的安全检查，其他语言支持还在开发中。覆盖漏洞包括SQL注入、代码注入、命令注入、跨站脚本、反序列化漏洞、路径穿越等多种漏洞。

在框架支持上，xcheck内置覆盖了常见的web框架，也可根据易编写易扩展的自定义规则模块自行编写规则对第三方框架进行覆盖支持。

2 Xcheck的优势

Xcheck在基于成熟的污点分析技术与对抽象语法树的精准剖解上，通过巧妙优雅的实现来达到对污点的传递和跟踪的目的，更精准地发现隐藏在代码中的安全风险。同时赋予了Xcheck两大优势：快！低误报！

在4核16g的linux云主机上，Xcheck对项目的检查速度在 1w+/s ，部分项目可以达到 2w+/s。以28w行的wordpress项目为例，xcheck检查时间为18s。

经过团队对xcheck投喂大量的项目进行误报优化，现xcheck各语言的误报率低于10%。

以python为例，xcheck对github部分python开源项目检测结果如下：

传统的 SAST 需要比较长的扫描分析时间， 实时性比较差 ，一个稍大的项目扫描好几个小时，在版本迭代快速的web应用开发中严重拖慢流水线，同时 误报率也比较高 ，同一个漏洞报n次的情况更是常有发生， 需要投入大量的安全团队的资源来去除这些误报，因此 无法敏捷地融入到 DevOps 中 。但Xcheck基于这两大优势，可完美融入DevSecOps，加速流水线又快又安全地建设。

3 部分检测案例

3.1 Apache Kylin 远程命令执行漏洞（CVE-2020-13925）

2020年7月份，京东安全团队发现了一个Apachec Kylin 远程命令执行漏洞，这里使用Xcheck对Kylin2.6.3的源码进行检查。耗时31s,检测出3个RCE漏洞，2.6.3版本不存在checkParameterWhiteList过滤函数，检测结果如下图。

漏洞触发点：

其中一条触发路由：

3.2 ThinkAdmin V4,v5,v6 反序列化漏洞（CNVD-2020-33163）

这是今年6月份Xcheck在对github部分开源项目检测中发现的0day漏洞，通过这个反序列化漏洞可实现任意代码执行的效果。漏洞代码位于app/admin/controller/api/Update.php和app/wechat/controller/api/Push.php，无需登录认证，此漏洞已第一时间告知开发者并申报CNVD,现已修复。

从git历史可以看到，程序对用户post进来的数据直接进行反序列化操作。

想了解Xcheck更多信息或者代码安全审计相关技术欢迎长按关注xcheck公众号~