去哪儿网
去哪儿是全球最大的中文在线旅行网站，创立于2005年。去哪儿网为消费者提供国内外特价机票、酒店、旅游度假、景点门票产品一站式预订服务，为旅游行业合作伙伴提供在线技术、移动技术解决方案。去哪儿近年来，接连发力大数据与人工智能，利用出游、住宿等领域的全量数据和人工智能，为用户打造智能化搜索、排序、推荐等服务。目前，去哪儿用户累计超6亿，平台年交易额超1600亿，且仍在快速发展中。作为洞态 IAST 最早期版本的用户，去哪儿在 IAST 与其 Q-SDL 安全体系的融合适配上有着独到的见解，十分感谢去哪儿 Q-SDL 负责人耿朋敲对本次 IAST 实践的分享。
01 安全背景
新政策、新业务、新威胁近年来，国家愈发重视信息安全，《网络安全法》、《数据安全法》、《个人信息保护法》相继出台并施行，对互联网企业提出了更严格的安全要求。在业务上，互联网企业的业务边界不断拓宽，用户和年交易额等均实现持续发展，业务保障需求更强。但技术研发成本不断攀升、盈利增速下降都促使着以业务为主的企业，更加注重在安全上的“高产出”。据可查数据，自疫情爆发以来，黑客针对国内互联网企业的攻击几乎呈现指数级增长，企业面临的安全威胁极大。在这样的背景下，互联网企业的网络安全能力建设，尤其是应用开发期的安全能力建设显得格外重要。阿里、腾讯、字节、去哪儿、轻松筹等企业均在着力强化应用安全开发，试图在应用开发期便大幅降低安全风险。DevSecOps 流程、SDL 流程在各企业都已早早落地实践运行，并打造适配其业务场景的安全体系。
安全需求
去哪儿结合自身实际，打造了 Q-SDL 体系。Q-SDL 体系通过预防、检测和监控措施相结合的方式，减少设计、开发中的软件的漏洞数量和严重性问题，降低应用安全开发和维护的总成本，保证系统的安全性。
未上线 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 网关、分布式、微服务等架构下的后端服务漏洞检测），还不会产生脏数据，干扰正常的开发测试流程。
对于检测发现的漏洞，洞态根据外部可控数据的传播过程，完整的还原漏洞触发流程，帮助 DevOps 团队快速理解漏洞、定位漏洞，更好的解决漏洞。通过赋能研发人员，提高漏洞修复的效率。
洞态 IAST 产品优势
- 第三方开源组件漏洞分析
- 应用漏洞溯源、定位与分析
- 应用漏洞自动验证
- 全面的风险监测
- 开源带来低成本、高扩展、多策略和多场景
促使我们选择洞态 IAST 的原因，除以上产品优点外，还有洞态团队对 IAST 部署升级的全力支持。如果我们选择其他厂商的 RASP/IAST，不一定能得到全力支持。
03 IAST 实践
去哪儿部署洞态 IAST 已经有半年多的时间，特分享一下 IAST 实践经验。
IAST 应用于Q-SDL体系在 Q-SDL 体系中，IAST 承担测试的角色，并且打造了 IAST 平台收集漏洞信息数据。
上线 IAST 后的 Q-SDL 体系架构
部署适配
在 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 的作用发挥到极致，也希望大家都能从去哪儿的安全智慧中找到灵感。
近期评论