介绍

IAST（Interactive Application Security Testing）是一种应用程序安全测试方法，它旨在帮助组织识别和修复应用程序中的安全漏洞和缺陷。与传统的静态应用程序安全测试（SAST）和动态应用程序安全测试（DAST）不同，IAST结合了这两种方法的优点，通过实时监视和分析应用程序的运行时行为来发现和评估安全风险。

下面是关于IAST的详细介绍：

1. 工作原理：

   • IAST在应用程序运行时与应用程序交互，通常以代理或插桩的形式集成到应用程序中。

   • 它监视应用程序的实际执行，并记录与安全相关的信息，例如输入验证、访问控制、会话管理等。

   • IAST还分析应用程序的数据流和控制流，以便更准确地识别潜在的安全问题。

   • 当发现问题时，IAST可以提供详细的信息，包括漏洞的位置、漏洞类型和可能的攻击场景。

2. 优点：

   • 实时检测：IAST能够在应用程序运行时立即检测到安全漏洞，而不是在静态分析或DAST之后。

   • 低误报率：由于IAST了解应用程序的实际上下文，因此通常产生较少的误报，提供更准确的结果。

   • 高效：与手动安全审计相比，IAST可以更快地发现问题，减少了漏洞修复的时间和成本。

3. 缺点：

   • 集成复杂性：将IAST集成到应用程序中可能需要一些工作，特别是对于大型和复杂的应用程序。

   • 不适用于所有应用程序：某些应用程序类型（如硬件控制器或没有运行时环境的应用程序）可能不适合IAST。

   • 有限的覆盖范围：IAST主要关注应用程序的运行时行为，可能无法检测到一些静态或配置问题。

4. 用途：

   • 安全测试：IAST用于发现和评估应用程序中的各种安全漏洞，包括跨站脚本（XSS）、SQL注入、身份验证问题等。

   • 持续集成/持续交付（CI/CD）：IAST可以集成到CI/CD流程中，提供实时反馈，帮助开发团队及时解决安全问题。

   • 安全监控：IAST可用于实时监视应用程序的安全状况，帮助组织识别潜在的攻击和威胁。

需求

通过DAST进行业务扫描，虽然成功减少了安全漏洞的数量，但随着时间推移，越来越难以发现一些隐蔽的漏洞，尤其是那些难以触发和检测的问题，以及第三方组件的安全管理也变得日益重要。在这种情况下，我们迫切需要引入IAST技术，以深入地发现潜在的安全问题。

在选择适合的IAST产品时，需要考虑多个关键方面，以确保最佳的安全测试体验和结果。以下是一些主要考虑因素，并进行了扩展：

1. Agent稳定性与性能损耗：

   • 首要考虑的是IAST产品的Agent稳定性，它不应对业务性能造成过大的负担。一个高度稳定的Agent能够在应用程序运行时实施安全监控而不引起崩溃或性能下降。

2. 熔断机制：

   • 为了防止Agent过度消耗资源或导致应用程序不稳定，需要一个熔断机制。这可以确保在超过一定资源阈值之后，Agent会停止运行，以保护应用程序的健康运行。

3. 安全漏洞检出率：

   • 一个优秀的IAST工具应该具有高安全漏洞检出率。它应该能够准确地发现各种漏洞类型，包括常见的Web应用程序漏洞，如SQL注入、跨站脚本（XSS）等，以及其他安全问题。

4. 安全漏洞误报率：

   • 除了检出率之外，误报率也非常关键。IAST工具不应该频繁报告虚假的安全问题，以免浪费时间和资源。低误报率可以提高开发团队对工具结果的信任。

5. 支持安全组件扫描：

   • 为了确保应用程序的整体安全性，IAST工具应该能够扫描和评估第三方组件的安全性，因为这些组件可能存在潜在的漏洞和风险。

6. 链路追踪、安全方法白名单和污点链路自定义规则：

   • 一个强大的IAST工具应该允许用户定义自定义规则，包括链路追踪、安全方法的白名单和污点链路的规则。这使得工具可以根据具体应用程序的需求进行定制，提高了检测的精度和适应性。

综上所述，IAST产品的选择需要综合考虑稳定性、性能、熔断机制、检出率、误报率、支持的功能以及可定制性。

调研

与业内几家厂商进行技术交流后，发现它们的技术实现基本相似，但每家厂商都有一些独特特点和优势，这对于选择合适的IAST产品至关重要。

我们注意到在IAST领域，各家厂商之间的技术实现方式具有相似性。这包括了在应用程序中嵌入Agent以进行实时监控，以及收集并分析运行时数据以检测潜在的安全漏洞。这种相似性可以理解为一种行业标准，它确保了IAST技术的一致性和可靠性。

测试部署

跟技术交流和查询相关的部署文档中，我们发现有多种IAST Agent的部署方式，这些方式适用于不同的应用场景。以下是对这些部署方式的优化和扩展内容：

IAST Agent的多种部署方式：

• 宿主机部署：

  • 这是一种直接在宿主机上部署IAST Agent的方式，通常适用于传统的单机部署或虚拟机环境。通过在Tomcat的启动脚本中引入IAST Agent相关配置，可以在应用程序启动时加载Agent，实现实时监控和检测。

• 容器部署：

  • 在容器化环境中，有几种IAST Agent的部署方式可供选择：

    • 容器内镜像部署：将IAST Agent直接打包到应用程序的容器镜像中，使其与应用程序一起运行。

    • Kubernetes (K8S) Sidecar容器：通过在K8S中创建一个Sidecar容器，负责运行IAST Agent并与主应用容器共享信息，实现容器级别的安全监控。

    • K8S Webhook触发部署：通过K8S的Webhook机制，可以根据应用程序的部署和调整触发IAST Agent的部署，以实现动态适应K8S集群中的变化。

• 热部署：

  • 热部署方式适用于已经运行的Java应用程序。通过使用进程ID（PID）来引入IAST Agent，实现在应用程序运行时加载Agent，而无需停止或重新启动应用。

K8S Webhook部署，可以参考下面文章：

• https://cloud.tencent.com/developer/article/1964242

• https://cloudnative.to/blog/mutating-admission-webhook/

功能测试

这次我们在安全靶场的测试中涵盖了多家厂商各自的靶场，如BenchmarkJava、百度RASP测试用例、SecExample、webgoat等，同时采集了各个IAST产品发现的安全漏洞数据，形成了一份全面的安全漏洞数据对比报告。在这份报告中，我们将进行横向对比，评估各家厂商在规则的漏洞检测能力方面的表现。

后续为了方便自己检测，写了一键启动多个JAVA应用的安全靶场：https://github.com/lokerxx/JavaVul。包括了基本漏洞、fastjson、log4j2等安全漏洞

以下是一部分漏洞数据：

具体的对比数据就不展示，可以自己测试下。

测试第三方安全组件（Third-Party Security Components）时，确保SCA（Software Composition Analysis）库的更新时间处于最新状态以及高危组件漏洞信息的准确性是至关重要的。

压力测试

通过将多个业务上线IAST Agent，并编写脚本以批量执行Apache Benchmark (ab) 来进行压测，以自动获取QPS（每秒请求数）和请求时间等相关性能指标，以确定Agent的性能损耗比率。

性能损耗比率的确定：

• 在这个实验中，首先我们需要明确Agent的性能损耗比率，即在有Agent和无Agent的情况下，应用程序性能的变化。这可以通过以下步骤来实现：

  1. 上线IAST Agent到应用程序，并确保它已经启动和运行。

  2. 使用Apache Benchmark或其他性能测试工具，模拟一系列请求，分别测试有Agent和无Agent的情况。

  3. 收集并比较QPS、平均响应时间、CPU和内存利用率等性能指标。

  4. 通过比较不同情况下的性能数据，可以计算出Agent的性能损耗比率。

实验数据的解释和分析：

• 报告应该详细记录实验数据，包括有Agent和无Agent情况下的各种性能指标。然后，对数据进行解释和分析，重点关注以下方面：

  1. QPS变化：比较有Agent和无Agent时的QPS，以了解Agent对于应用程序吞吐量的影响。

  2. 响应时间变化：分析平均响应时间的变化，看是否Agent导致了响应时间的增加。

  3. 资源利用率：评估CPU和内存的利用率变化，以确定Agent对系统资源的需求。

性能损耗的合理范围：

• 报告还应提供有关性能损耗的合理范围。这个范围可以根据实验结果和应用程序的特性来确定。例如，性能损耗在5%到10%之间可能是可以接受的，但具体取决于应用程序的要求和预算。

后续写了多个分布式微服务来验证性能损耗：https://github.com/lokerxx/JavaVul/tree/master/microservice-eureka-service

生产部署

在我们的Kubernetes(K8S)应用环境中，决定采用容器化部署方式来上线IAST agent。综合考虑人力、沟通成本，我们决定放弃传统的部署模式，转而采取一种更为高效的策略。

首先，我们遇到了几个核心问题：

1. 使用Sidecar模式的挑战：采用这种方式意味着每个项目的yaml配置文件都需要添加IAST agent的相关内容。这不仅沟通成本高昂，还使得每当agent出现问题时，开发团队都需要反复修改yaml文件，这极大增加了工作量。

2. 镜像纯洁性问题：将agent直接打包进镜像会影响到生产环境使用的镜像纯洁性，这是我们无法接受的。

3. K8S Webhook的局限性：虽然这种部署方式可以自动监控并插入或卸载IAST agent，但实践中发现它无法精确控制特定deployment的插桩和卸桩。此外，当agent出现问题需要卸载时，无法自动重启pod，需要手动操作，这也增加了维护成本。

鉴于以上挑战，我们决定自主开发一套部署平台。利用K8S的机制，当应用的deployment更新时，会自动重启pod。我们的方案是，通过Python脚本调用SSH登录K8S worker节点，获取所有namespace和应用的deployment文件信息。然后，我们在本地自动修改这些deployment文件，插入IAST agent的配置（采用sidecar模式），再上传并apply这些yaml文件至K8S worker节点，实现IAST agent的插桩。卸桩也采用同样的方法，检查deployment文件是否包含IAST agent配置，若有则移除，并重新apply yaml文件以实现卸桩。

在实施过程中，我们也遇到了一些问题：

1. 应用健康检查的调整：当引入IAST agent后，部分应用的pod可能因健康检查配置不当而无法正常启动。为此，我们在yaml文件中对健康检查时间和次数进行了相应调整，以确保pod的正常运行。

2. 异常处理与回退策略：为应对agent异常或开发测试中的问题，我们监控deployment的状态。如果连续失败超过三次，系统会自动执行回退操作。同时，我们也提供了一个操作界面供开发和测试团队手动进行回退。

以下是IAST agent异常回退撤销：

以下是页面手动撤销IAST agent：

采用这种模式，开发和测试团队几乎无需关注底层操作（得益于K8S的滚动更新机制），同时我们也能有效地批量管理IAST agent的上线和下线。

此外，为了进一步优化我们的IAST agent部署策略，我们实现了一种高效的实时交互机制。具体来说，我们通过SSH与Kubernetes(K8S)的worker节点实时通信，这使我们能够即时获取哪些deployment应用发生了更新。根据K8S的机制，一旦deployment更新，系统会自动卸载IAST agent。为了保证IAST agent的连续性和有效性，我们在每个应用更新时（通过10秒的监控间隔，可调整）立即重新插入IAST agent。虽然这种方法在速度上可能略逊于webhook的实时拦截，但实际上它已经非常接近了。

我们确实考虑过开发专用的webhook插件来实现这一过程。然而，这涉及到相当的学习成本，而且对现有的开发流程产生较大的影响。因此，考虑到效率和实用性，我们选择了直接使用Python配合SSH来处理这一过程。这不仅简化了整个部署流程，还降低了对团队的技术要求，使得整个IAST agent的部署和管理变得更加高效和灵活。

通过这种方法，我们能够确保IAST agent在K8S环境中的平滑运行，同时最大限度地减少了对开发和测试团队的干扰。这种策略的实施，不仅提高了安全测试的效率，也增强了整个应用的安全性能，为我们的IT基础设施增添了一层坚实的保护。

运营

通过访问IAST 安全漏洞数据和组件接口，将数据采集到安全平台上面做数据的整合，实现一键生成安全漏洞工单