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

去哪儿网

去哪儿是全球最大的中文在线旅行网站,创立于2005年。去哪儿网为消费者提供国内外特价机票、酒店、旅游度假、景点门票产品一站式预订服务,为旅游行业合作伙伴提供在线技术、移动技术解决方案。去哪儿近年来,接连发力大数据与人工智能,利用出游、住宿等领域的全量数据和人工智能,为用户打造智能化搜索、排序、推荐等服务。目前,去哪儿用户累计超6亿,平台年交易额超1600亿,且仍在快速发展中。

作为洞态 IAST 最早期版本的用户,去哪儿在 IAST 与其 Q-SDL 安全体系的融合适配上有着独到的见解,十分感谢去哪儿 Q-SDL 负责人耿师傅对本次 IAST 实践的分享。

一、安全背景

1. 新政策、新业务、新威胁

近年来,国家愈发重视信息安全,《网络安全法》、《数据安全法》、《个人信息保护法》相继出台并施行,对互联网企业提出了更严格的安全要求。在业务上,互联网企业的业务边界不断拓宽,用户和年交易额等均实现持续发展,业务保障需求更强。但技术研发成本不断攀升、盈利增速下降都促使着以业务为主的企业,更加注重在安全上的“高产出”。据可查数据,自疫情爆发以来,黑客针对国内互联网企业的攻击几乎呈现指数级增长,企业面临的安全威胁极大。

在这样的背景下,互联网企业的网络安全能力建设,尤其是应用开发期的安全能力建设显得格外重要。阿里、腾讯、字节、去哪儿、轻松筹等企业均在着力强化应用安全开发,试图在应用开发期便大幅降低安全风险。DevSecOps 流程、SDL 流程在各企业都已早早落地实践运行,并打造适配其业务场景的安全体系。

2. 安全需求

去哪儿结合自身实际,打造了Q-SDL体系。Q-SDL体系通过预防、检测和监控措施相结合的方式,减少设计、开发中的软件的漏洞数量和严重性问题,降低应用安全开发和维护的总成本,保证系统的安全性。

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

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

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

二、调研之路

考虑到开源产品具备高扩展性、低使用成本的特性,我们首先将选择定位在开源产品上。由于当时市面上只有开源的 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 网关、分布式、微服务等架构下的后端服务漏洞检测),还不会产生脏数据,干扰正常的开发测试流程。

对于检测发现的漏洞,洞态根据外部可控数据的传播过程,完整的还原漏洞触发流程,帮助 DevOps 团队快速理解漏洞、定位漏洞,更好的解决漏洞。通过赋能研发人员,提高漏洞修复的效率。

洞态IAST产品优势:

? 第三方开源组件漏洞分析

? 应用漏洞溯源、定位与分析

? 应用漏洞自动验证

? 全面的风险监测

? 开源带来低成本、高扩展、多策略和多场景

促使我们选择洞态IAST的原因,除以上产品优点外,还有洞态团队对IAST部署升级的全力支持。在服务上,如果我们选择其他厂商的RASP/IAST,不一定能得到全力支持。

三、IAST实践

去哪儿部署洞态IAST已经有一年多的时间,特分享一下IAST实践经验。

IAST应用于Q-SDL体系

在 Q-SDL 体系中,IAST 承担测试的角色,并且打造了 IAST 平台收集漏洞信息数据。

部署适配

在 Q-SDL 体系中部署 IAST,主要是从基础环境、应用环境、生命节点上进行适配,并在具体的点上进一步优化。

在去哪儿,IAST Agent 的部署环境包括容器与虚拟机二种。采用分布式部署的方式,提高系统的可靠性与可用性,并对二种不同环境开发一套标准流程,保证 Agent 在不同环境的标准化部署。部署完毕后,需要将安装 Agent 的机器所在的网络和 Agent 接收数据的 OpenAPI 之间的网络打通,使 OpenAPI 能接收数据。

在实际应用上,通过二次开发,扩展 IAST 的功能,并推动和去哪儿其他安全工具的融合。通过洞态 IAST Agent 收集识别企业资产,从而对整个资产进行漏洞检测。为应对 IAST 运行过程中可能出现影响业务等问题,我们提出了二套解决方案。一是“软着陆”,即通过洞态 IAST 自带的解决方案,直接删除核心模块;二是“硬着陆”,基于去哪儿强大的 API 直接将 IAST Agent 端去除。但我们使用这么长时间,还没出现过严重的问题。

在使用中,我们并不是将 IAST 孤立地用来检测。而是把威胁信息和项目信息,上传至去哪儿的威胁建模平台,然后将 IAST、DAST 和 SAST 做相应的配合,有针对性地检测某些漏洞,提高检测率。

私有云部署场景

对于私有云部署场景,我们主要做了二点变动:第一点是在 IAST Agent 部署时,把 Agent 包直接放入镜像指定目录,以应对庞大的测试流量。另一点是对 Agent 端启动命令进行植入,以适配标准化环境,从而有序地执行,不去抢占其他环境变量的资源,发生冲突。

整体部署方案

整体的部署方案是遵循洞态 IAST 的基础部署方案,我们只做了微调。业务端 Agent 没有做太大的改变,仅对 Java 包进行了二次开发。为防止应用高流量高并发导致 IAST 超载,针对性地开发了负载均衡功能。而在 IAST 分析模块上,我们将 Redis 独立出来,并做得更强大些以应对高流量高并发。

以下为我们去哪儿网络进出口的真实情况:

为控制突发性的高流量,我们采用了 “自适应流量采集+分布式架构” 的方案。自适应流量采集将无效的流量过滤,分布式架构则可灵活支撑高并发,减轻流量压力。

运行流程

实际使用感受:

1. 值得称赞的点

       ● 应用威胁识别广泛

我们在上线前利用靶场做过了大量测试,才放心将洞态IAST上线。IAST检测到的漏洞类型几乎覆盖所有的通用漏洞,包括(持续增加中):

       ● 组件威胁识别率高

IAST上线后发现了大量的组件威胁,具体数量等信息就不方便透露咯。

       ● 技术真材实料,服务尽心尽力

2. 吐槽

      ● 高危漏洞检出率较低

洞态说明:因为去哪儿部署的是最早一版的洞态,出于稳定性考虑,还未进行版本更新,因此在检测能力上相对新版本会差许多。但洞态会加强研发力度,持续扩大可检测漏洞类型以及高危漏洞的检出率。

洞态:去哪儿的 IAST 实践亮点在于擅长将 IAST 与自身 Q-SDL 体系的适配,也善于从自身所处互联网行业高流量高并发的特点出发,通过开发负载均衡功能、对 IAST 模块进行调整、扩展开发等手段,将 IAST 的作用发挥到 ,也希望大家都能从去哪儿的安全智慧中找到灵感。

关于洞态 IAST

洞态 IAST 是全球 开源 IAST ,于2021年9月1日正式开源发布。洞态 IAST 专注于 DevSecOps,具备高检出率、低误报率、无脏数据的特点,帮助企业在应用上线前发现并解决安全风险。自开源发布以来,洞态 IAST 备受开源社区人员和企业的关注,包括工商银行、去哪儿、知乎、同程旅行、轻松筹等在内的上百家企业都已成为洞态用户。