IAST 在去哪儿 Q-SDL 体系中的应用

正文

请到「今天看啥」查看全文

从上图可知，用于安全漏洞检测的自动化工具仅包括 SAST 和 DAST，但 SAST 和 DAST 均具有不可避免的严重缺陷。

我们在实际运行中发现，白盒测试存在误报率高、审计时策略规则失效明显、扫描效率低下严重阻碍开发节奏等问题，尤其是无法获取漏洞数据对安全部门造成了很大困扰。 而黑盒覆盖范围有限，覆盖率依赖于 Explore 的结果，无法扫描 AJAX、CSRF Token、验证码等页面，无法测试 APP，无法定位漏洞的具体代码，需要花费较长时间与人力来进行漏洞定位与原因分析。

去哪儿急需一款能够弥补黑盒和白盒不足的产品来完善 Q-SDL 体系。

02 调研之路

考虑到开源产品具备高扩展性、低使用成本的特性，我们首先将选择定位在开源产品上。由于当时市面上只有开源的 RASP，而没有开源的 IAST，因此首先调研的是 RASP。但调研后发现 RASP 存在严重影响服务器性能的问题，恰巧在了解 RASP 的过程中，发现火线安全正在研发 IAST，并打算开源发布，于是便进行了接触。以下为洞态 IAST 调研结果：

IAST 全称交互式应用程序安全测试， 主要通过 Agent 来收集和监控应用程序运行时的函数执行及数据传输，并与服务端进行实时交互，进而更高效、更准确的识别应用软件的安全缺陷及漏洞。同时可准确定位漏洞所在的代码文件、行数、函数及参数，方便开发团队修复问题，还具备高低误报率、0脏数据的优势。 但 IAST 在不同语言开发的 WEB 应用中需要有不同类型的 Agent、研发的技术难度和投入都非常巨大。

洞态 IAST 产品架构

在调研中我们发现洞态 IAST 在架构上完全不同于其他 IAST，其他 IAST 往往 “重 Agent 端、轻服务端”，而洞态的 Agent 端仅用于实现数据监听，漏洞检测全部在服务端完成。这种方法的好处是 Agent 端代码和逻辑简单， 单点故障率更低也极少需要升级，降低了维护成本 ；另外，传统 IAST 产品对于当时未检测的漏洞都在 Agent 端直接丢弃，产品出现新的检测策略后，需要重新发起应用的测试，而洞态 IAST 将检测数据保存在服务端， 可轻松地在服务端进行回归测试 。

产品架构说明： 首先，在服务器上安装 IAST Agent。当 IAST 启动，用户访问 Agent 服务后，Agent 便开始采集数据，并与 OpenAPI 服务通信，进行上报数据和Hook规则的拉取。OpenAPI 将数据存储到数据库中，包括 MySQL 和 Redis。然后，Agent 对 Engine 发送通知，Engine 便会来消费数据库中的数据，并在分析完毕后将漏洞信息回写到数据库中。最后，用户通过 WebAPI 查看数据库中漏洞的数据信息。

洞态 IAST 检测原理

洞态基于“值匹配算法“和”污点跟踪算法”对漏洞进行检测。这种算法检测准确率高，还无需采集和重放流量，可以适配如今各种场景下的漏洞检测（如 API 网关、分布式、微服务等架构下的后端服务漏洞检测），还不会产生脏数据，干扰正常的开发测试流程。

请到「今天看啥」查看全文