交互式应用安全测试（Interactive application security testing IAST） - 郑瀚Andrew
2024-5-7 10:49:0 Author: www.cnblogs.com(查看原文) 阅读量:15 收藏

交互式应用安全测试（Interactive application security testing IAST）是一个在应用和API中自动化识别和诊断软件漏洞的技术。如果从名字的缩写来看，插桩（Instrumented）式应用安全测试或许是一个更好的说法。IAST不是一个扫描器，IAST持续地从内部监控你应用中的漏洞，在整个开发生命周期中，IAST通过你在开发和测试中使用的工具（比如说DAST、漏洞扫描等），实时地提供报警。

IAST最显著的特性是它使用插桩来收集安全信息，直接从运行中的代码发现代码风险问题（代码漏洞、不规范的编码方式等），不是源代码扫描（SAST），也不是HTTP 扫描(DAST)。但那并不意味着你要等到产品上线时才使用它，恰恰相反，你可在IDE中，当开始编写和测试第一行代码时，就使用IAST。

了解IAST在完整的应用安全技术策略中的位置非常重要，有两个主要自动化应用安全的方法，你都要考虑到：

  1. 在开发时阻止漏洞。IAST自动地发现应用和API的漏洞，这样可以在开发过程早期就进行修复，成本不会那么高。IAST在检测速度，精确度，流程上都比传统的SAST和DAST有优势，某些IAST还包括开源软件安全分析功能。
  2. 在生产阶段检测攻击和阻止漏洞利用。RASP在运行时阻止漏洞被利用，而不是像Web 应用防火墙（WAF）那样通过检查网络流量来阻止攻击。RASP并不仅在精确度和扩展性上优于传统的Web防护方法，还能适配各种业务系统架构（因为其注入单元是最小的进程单元）（注：RASP也使用插桩的方法，和IAST所使用的底层技术基本一样，区别仅在于RASP更关注运行时的0Day防护，IAST除了具备漏洞拦截能力之外更关注漏洞源头的溯源和定位）

IAST技术在2010年出现，许多最大的金融、技术和医疗保健公司已经采用了IAST技术。在本文中，我们将探索如何把IAST集成到整个软件生命周期中，实现最经济的漏洞检测。

参考链接：

https://www.youtube.com/watch?v=J5XV41Lt2RQ
https://www.contrastsecurity.com/glossary/interactive-application-security-testing
https://www.contrastsecurity.com/search-results?term=IAST&type=BLOG_POST&type=LISTING_PAGE

问题很简单，我们在应用安全方面，有大量的问题。但应对这些问题的安全专家有限，全世界几乎有2000万的开发人员。传统的工具要求安全专家和应用一起工作（安全深度介入开发过程），训练工具，解释结果。这些工具80%的费用是有效使用工具的“人的费用“，没有真正的自动化。

痛点一：工具困境

“工具困境”是指你为工作准备的工具都不是很好用，因此，你不得不运行一系列工具，希望能得到一个好的结果。

在安全领域十余年来，业内一直在尝试这种“混合”的方法，但确实没什么作用。想像一下，使用SAST，DAST，还有SCA工具的结果去检测CSRF漏洞的情形：

  • 静态分析：静态分析工具仅仅能尝试检测没有被token检查保护的数据流，不管他们是状态变更还是通过XHR访问。结果或者是花费大量时间的误报，或者是危险的漏报。
  • 动态分析：DAST工具能够标记不包含CSRF令牌的表单，但无法知道是否他们在状态变更，因此，结果结果或者是花费大量时间的误报，或者是危险的漏报。
  • 开源软件分析：SCA工具只能标记含有已知漏洞的库，将会错失所有没有被安全专家暴露和发布的安全漏洞。

运行所有这些工具，浪费时间和宝贵的安全技能。但更重要的是，很难关联安全测试结果。静态工具能够报告源代码行数，动态工具报告HTTP请求，开源工具报告库版本号，没有好的方法来关联这些报告。最好的关联工具减少15%-35%发现结果。因此，如果你有两个工具，每份报告了200个发现结果（对于静态工具，一个保守的估计），你会得到缩减后的340个结果。总之，仅仅合并噪音和不精确的报告是不经济的。

痛点二：传统的应用安全工具和现代软件不兼容

现代软件开发速度更快，正在加速发展。许多项目按周、天，甚至小时的频率来部署代码。不幸的是，像SAST、DAST、模糊测试、人工渗透测试、人工代码检查无法跟上现代软件的速度和规模。

综合来看，传统应用安全工具的最大挑战，IAST都可以具备比较好的解决方案：

  • 精确性：传统工具的最大问题是精确度。SAST和DAST产生大量的误报（不是真实的漏洞）和漏报（错失真正的漏洞）。工具不精确的时候，安全专家必须执行手动步骤来解决问题，这个流程耗费大量时间，导致软件开发的很大瓶颈。相比传统工具，IAST有一个巨大的信息优势，精确度的提高意味着开发人员能够直接使用结果，不需要安全专家介入，从而大幅度加快流程。
  • 兼容适配性：现代应用中大量使用到API封装，同时基于复杂的框架进行二次开发，程序从从复杂的路由和数据结构中解析出结果（如XML，JSON，序列化对象）。在缺少大量的规则定制的情况喜爱，SAST无法跟踪这些路径，DAST无法模拟测试要求的复杂流量，IAST对这些问题具有很好的免疫力，因为它只观察运行时的复杂应用和API。
  • 速度：现代软件方法，像敏捷和DevOps，进展得非常快。目标是在开发者和上线之间完全自动化。然而传统的工具花费许多小时去执行一个完全的分析（甚至不考虑使用专家分诊，去除误报）。当一个开发人员在他们的IDE环境中编译和测试代码时，IAST提供及时的反馈。IAST还能和QA一起运行测试，如果发现安全问题，能够马上停止编译。
  • 扩展性：安全工具必须能够使用多个规则，持续分析应用的整个组成。传统的扫描按顺序运行，无法扩展到整个企业。IAST是一个针对应用安全，完全分布式和持续的方法，意味你所有的应用和API能够被持续并行访问，因此你的安全也就能一直保持在最新的状态。
  • 流程兼容：IAST位于已经存在的开发工具和流程的顶端，不需要额外的步骤。做正常开发和测试时，IAST在后台运行，因为IAST非常精确，能在不了解漏洞的情况下发现它们，不需要专家，任何人都可以使用IAST做安全测试，生成干净的代码。

交互式应用安全测试使用软件插桩收集安全信息，并直接从运行中的代码发现问题，以实现自动化识别和诊断在应用和API中的软件漏洞。

  1. 运行时代码级别的上下文感知能力。IAST可以访问代码本身（能够在每行代码执行SAST），而且IAST可以访问HTTP流量（能够在每一次请求和响应时，执行类DAST的分析）。因此，IAST的规则是SAST和DAST的一个功能合集。
  2. 业务代码安全测试。IAST能够自动化地分析应用和API中的自有业务代码，找出以前没有发现的0Day漏洞，能够识别很宽范围的漏洞，包括并不限于OWASP Top 10，还有其他更复杂的漏洞。
  3. 开源软件安全测试。IAST也能用来测试开源库和框架的安全性。首先，IAST能识别困扰开源软件的已知漏洞（如CVE发布），其次，IAST能识别开源软件中以前未知的（潜在）漏洞。
  4. 风险数据泄露链路追踪。IAST利用其API和应用拓朴追踪能力，可以从敏感数据泄露现场，反向追溯出沿途的应用和API链路拓朴，最终定位到某一行业务代码中。本质上说，风险数据泄露也属于一种特殊的漏洞，和反序列化/代码执行这类漏洞的区别仅在于触发点和风险行为模式不同。

除了在独立场景中发挥作用之外，在实际的应用安全体系建设中，IAST可以和其他工具和防护手段有效配合。下图显示IAST在NIST的Cybersecurity Framework中的位置，IAST完全集中在应用安全这一行，除了检测和识别漏洞，某些IAST实施能帮助识别和分析应用。 

使用基于插桩的方法来提供安全能力并不限于应用层。安全专家已经认识到，我们可以不再只从外部来检测漏洞，外部的视角并不能提供足够的上下文信息精准地识别漏洞，从内部做漏洞检测更容易更精确。这种基于插桩（和基于扫描的安全测试对比）的安全测试趋势，正在从网络向应用全栈中扩展。

下表详细介绍了现代网络应用程序堆栈的各层及其基于插桩的安全解决方案。

LAYERINSTRUMENTATIONEXAMPLE PRODUCTSTESTING
Application IAST
  • Contrast
  • Seeker
 Tests the security of applications and APIs by instrumenting software
Container Container Security
  • Twistlock
  • Aqua
  • Anchore
  • Sysdig
 Tests the container security by instrumenting the container
Operating System Endpoint
  • Carbon > Black
  • ThreatStack
  • Tanium
 Tests operating system security by instrumenting the OS
Network Network Security
  • ZScaler
  • Tenable
 Tests network security by instrumenting the network stack.

如您所见，IAST是一种针对应用程序层的基于插桩的安全方法，许多针对其他堆栈层的安全产品也认识到了基于插桩方法的优势。在所有层面上，直接访问比从外部角度测试安全性具有巨大优势。

由于IAST将安全性直接构建到软件堆栈中，应用程序可以安全地部署在任何环境中，包括云、PAAS、VM和数据中心。

参考链接：

https://dzone.com/refcardz/introduction-to-iast

IAST探针如何工作

通常，IAST使用类似APM工具的技术，使用安全探针对插桩的应用和API进行调试排错，探针从运行的应用中直接检查安全相关的事件，并传递给分析引擎，引擎重新组装这些事件，识别出代码执行中的漏洞特征。

当一个应用或者API被加载到内存中，应用中的插桩是动态执行的。插桩本身很安全，并被广泛应用到日志、性能测试、及其他目的。许多常见的框架已经在运行时使用隐藏的插桩技术，很可能你已经在应用和API中使用过某种形式的插桩。

现代应用常常在运行时组装，使用依赖注入、动态加载、反向控制等其他技术。因为这个原因，源代码分析只能提供一个局部观察，验证安全最好的方法是直接检查运行时应用，IAST支持这种直接的检测。

IAST安全探针能够从应用中实际地提取任何信息。在许多方面，IAST是SAST和DAST的一个合集，包括代码和HTTP流量的分析，但IAST在它的分析中考虑到更多类型的信息，包括：

  • 代码。IAST能访问所有和应用一起部署的源代码和二进制代码。代码探针对应用中每一行代码做二进制的静态分析，包括库和框架。
  • HTTP流量。IAST能够看到HTTP请求和响应，使用和DAST非常类似的技术，发现和这些流量相关的漏洞。
  • 库和框架。IAST能看到部署的每一个库和框架，分析应用和API如何使用它们。不仅IAST能够根据已知漏洞（CVE）来评估库，也能识别部分或整体隐藏在库里面的未知漏洞。重要的是，因为IAST能精确知道库里面的哪一部分被应用真正调用，它能够过滤掉从未被调用的和库相关的漏洞。
  • 应用程序状态（敏感参数检查）。IAST能够检查程序执行时的应用状态。例如，IAST能看到调用安全方法时使用的参数来发现弱点，如传递“DES”参数给加密密码构造函数。
  • 污点数据流追踪。从开始进入应用的时候开始，IAST就追踪不信任的输入数据。这是识别最重要的漏洞种类（注入类漏洞、指令注入类漏洞）的关键。这个技术，有时称之为“污点追踪”，跟踪真实数据在应用中的流动，非常精确。
  • 敏感控制流监控。IAST了解应用的控制流，能够识别出应用行为中漏洞的特征。例如如果一个应用要求在每个web服务中，采用service()方法检查访问控制，这个特征将很容易被IAST发现。要实现这个需求，往往需要产品支持自定义规则配置，用户可根据企业自身的实际业务情况配置针对性的敏感类/方法规则。
  • 后端连接检查。IAST能够检查围绕着后端连接的所有细节，如数据库、操作系统调用、目录、队列、套接字、电子邮件和其他系统。IAST使用这个信息识别出架构缺陷、安全缺陷、以及应用/API拓朴信息。
  • 配置检查。IAST能访问应用、框架、应用服务器、和平台的配置，保证正确的安全配置。IAST甚至能查询应用组件的运行时配置，如XML解析器。（注：某些平台，如.NET，重度依赖配置来实现安全）

IAST常常使用多个不同的信息源来证实一个漏洞，例如，当一个暴露的端点，是non-XHR，或者状态正在改变，或者没有包含token检查，就可以确定是一个CSRF（跨站请求伪造）漏洞。IAST能够访问HTTP请求，分析是否一个交易修改了文件或写到存储设备里，评估是否一个控制流包含一个token检查。通过在漏洞分析中，使用所有这三种类型的数据，IAST得出准确的结果，不会漏报也不会误报。

对企业组织，IAST是一个能够横跨整个应用和API组件集，建立持续安全测试的有效方法。使用IAST，组织能在所有的应用组件中，持续并行地执行应用安全测试。

场景一：保护企业的应用组件集

许多组织仅仅测试应用组件集中的一小部分，一些组织只测试重要的应用，其他组织的策略是测试所有面向外部的应用。更可能的是，你主要的网站没有受到攻击，而是合作伙伴的网站、一个复杂的移动API、或内网的业务应用受到攻击。这就是为什么保护所有应用和API，甚至非webAPI的重要性。

对许多外部和面向公共的应用，许多组织保留安全测试。事实上内部应用和外部应用的概念，取决于工作安全边界。不幸的是，由防火墙和其他网络安全设备建立起来的边界，已经变得千疮百孔，意义不大。例如，一台员工工作站，被攻击者变成内部的跳板，边界变得无关紧要，企业需要测试你的整个应用组件集，包括内部应用。

场景二：在CI/CD管道中的IAST

记住，IAST不像一个扫描器，IAST有效地变成了应用的一部分，它能在应用运行的任何地方运行，包括开发人员的IDE，本地测试服务器，QA机器等。作为CI/CD构建的一部分，IAST可以运行在容器中，在云中，你代码运行的任何地方。在整个软件生命周期中，你软件运行的任何地方，你都可以使用IAST。

下图描述了一个简单开发管道，使用IAST持续的发现漏洞。

  • 使用IAST，确保开发人员提交”清洁”的代码

在开发中，我们的目标是赋能开发人员发现和修复他们自己的漏洞，提交清洁的代码。但我们必须避免拖累他们或给出误报结果，避免浪费研发人员的时间。

开发人员使用IAST，在开发环境中，当生成和测试代码时，实时地做安全分析。开发人员必须要做的是把IAST代理增加到本地的服务器环境中，一旦IAST安装好了，开发人员可以做日常的工作和测试，自动或者手动，不用再做一次安全测试。开发人员通过他们使用的安全工具，如Eclipse，IDEA，VisualStudio，Slack，Hipchat，Chrome，JIRA，VSTS等，实时地收到安全漏洞通知。同时IAST可以提供精确的代码行，完整的HTTP请求，完整的数据和控制流，开发者的工作变得容易，他们能够修复代码，使用相同HTTP请求来再测试，验证问题是否解决，最后提交清洁代码。

  • 在部署前，使用IAST提供强大保证

IAST也可以用在QA、测试、CI/CD阶段，保证开发阶段没有漏洞。

不管是用来做自动化测试的测试服务器，还是CI/CD构建流程的一部分，只要把IAST代理添加到用来做QA的服务器中就可以实现目的。对于完全组装的应用，在QA中使用IAST是一个有效的最后检查手段，因为它会被配置和部署。

同时，IAST可以配置成自动化生成缺陷跟踪ticker，或停止软件构建。

  • 使用IAST保证API安全

传统的静态和动态工具不擅长测试API安全，这些工具无法处理复杂协议（JSON，XML，二进制，或其他payload），或者架构中用来构建API的复杂数据流和控制流。

大多数API使用软件框架，包含自动化payload解析，对象映射（object mapping，注释等手段把数据发送到合适的方法。因为IAST从API内部收集安全信息，和常见web应用工作方式一样，能够很容易识别API漏洞。

  • 易于集成和安装 

另一方面，IAST安装的过程非常简单，一个典型的IAST方案通常包括两部分，

  • IAST代理
  • IAST控制台

第一步是在你的环境中增加IAST代理，方法和增加一个库一样只需要设置环境变量即可，当你使用应用时，IAST代理自动在后台做安全测试，重要的是，你不需要攻击应用就可以得到安全测试结果。IAST能被任何人使用，甚至刚开始做开发工作的新人。

IAST控制台让你管理整个应用组件集的安全，并行地处理和管理安全策略，配置安全控制，和其他常见开发工具集成，实现漏洞通知等。

场景三：在生产环境部署IAST提高对传统应用的持续保证

在生产环境做安全测试并不是一个很好的主意。理想情况下，你应该在上线之前很久就修复任何安全问题。然而，常常有许多不再主动开发的传统应用，同时还有一些只存在于生产环境的第三方产品，我们仍然需要持续保证这些应用没有漏洞。我们也希望知道，是否有新的漏洞会影响这些应用。

虽然没有开发和测试环境中使用的这么普遍，IAST也能有效的使用在生产环境。因为IAST不要求源代码。能够在任何可以安装IAST代理的应用中使用，但也要考虑到IAST的性能问题。虽然速度很快，在开发和测试环境中没有被注意到，在生产中，即使几微秒也无法接受。

场景四：使用IAST测试开源软件中已知漏洞

虽然开源软件漏洞常常看起来像洪水猛兽，但事实也许比看到的更严重。目前有几百万个开源库，但只有有限的安全专家在测试他们。

IAST根据CVE库，能自动地分析开源软件漏洞。因为IAST能持续运行并行地遍历整个应用的组件，可以在几分钟内检测新引入库中的增量问题，而传统的开源软件扫描器需要重新扫描整个企业。

除此之外，IAST能精确地告诉你，在开源软件库中到底调用了哪些代码，以及具体在哪些地方被调用。据统计，平均72%的库只包含在应用程序的编译依赖中，从来没有被应用程序真正调用。IAST能节省您升级不真正带来风险的库的工作。

场景五：使用IAST来持续审计和合规

IAST工具支持很宽范围的安全标准，包括：

  • PCI DSS
  • HIPPA
  • NIST 800-53
  • OWASP Top 10
  • OWASP ASVS
  • DISA AppSec STIG

IAST工具能生成报告，证明应用被完全安全测试过，没有漏洞被发现。因为这些报告任何时候都能生成，能显著的加快审计和合规流程。

场景六：使用IAST加强安全编码指南

IAST不仅支持漏洞规则，同时也支持代码编码规范相关的规则，它可以加强你组织自身的安全编码指南。你可以生成“正向”的规则，如“每个API必须调用AccessController.isAuthorized()方法来授权“。IAST能加强这些规则，给与开发人员即时反馈，告诉开发人员组织是如何实现安全的。

随着时间推移，组织能使用这个能力，从负面的“阻止漏洞模型”向正向的“使用企业安全控制”模型转变。

场景七：使用IAST提升企业向DevOps转型速度

软件开发项目向DevOps转变过程中，构建和测试软件的流程加速了，使得SAST和DAST越来越难以使用。IAST格外适合DevOps，因为它赋能开发者得到及时和精准的反馈，不要求任何额外的流程步骤就可以发现和修复他们自己的安全漏洞。这就最小化了安全工作对开发的影响，明显减少了下游的安全工作。

使用IAST，你和以往一样构建、测试、部署代码，唯一的区别是IAST在后台运行，确保你不会引入任何危险的代码或库漏洞。

如上图所示，IAST扩展性好，非常容易的在几百上千个应用上，并行地持续执行应用安全测试。 

参考链接：

https://dzone.com/refcardz/introduction-to-iast

相关部门

在IAST解决方案选型的过程中，你要考虑多个不同的部门：

  • 安全部门。安全部门很显然在漏洞管理中扮演着一个重要的角色。在整个组织的应用和API组件中，IAST是一个主要的漏洞提供者，应用得好，IAST能够帮助开发在早期消除大多数漏洞，不需要安全部门的介入。
  • 开发团队。开发团队有很大的责任，保证应用和API没有漏洞。开发团队经常有使用安全工具的噩梦经历，也许会怀疑IAST能力，因此关键是确保他们理解IAST的优点，得到他们的支持。
  • DevOps。DevOps团队一个重要的工作是推动软件快速上线。这和静态及动态扫描都不兼容，因为他们要花费很长时间来扫描，要求大量工作去消除误报。IAST能帮助DevOps团队把自己的安全做好，提供完全自动化的方法，在安全上很自信地推动代码上线。
  • 管理团队。对应用安全的自信能够帮助管理层做出数字化转型的决定，向DevOps转移，或向云上转移，同时保证IAST作为被企业内所有人认可的应用安全测试技术，能帮助业务转型。

技术考虑

  • 语言支持。不同的厂商支持不同的语言，因此你要保证IAST支持你重要的应用和API正在使用的语言。
  • 框架支持。应用框架和语言同样重要，除非IAST支持你正在使用的框架，否则在检测漏洞方面不会有效。
  • 精确度。你会想使用一个包含一系列真实漏洞的应用，来评估精确度。仔细测试IAST的识别能力，没有误报。使用OWASP Benchmark看到操作详情，来衡量应用安全测试工具的好坏。
  • 扩展性。考虑到应用组件集的数量，包括API，内部应用和产品。是否IAST能够扩展到持续分析所有的应用？达到这个水平需要多少人来支持。
  • 规则集覆盖。寻找一个宽泛的规则集，覆盖你关心的攻击。包括CVE。
  • 可见性。IAST有它自己的仪表盘吗？或仅仅是依赖缺陷跟踪系统。输出什么样的报警，通知、报告？有IDE和CI/CD插件支持吗？
  • 安装。大多数IAST产品安装简单，不要求流程变更。安全可以自动化吗，是否可以被增加到容器和镜像里面，可以自动地支持新的应用？
  • 配置。是否IAST要求复杂的配置，来实现精确的分析？常见的安全控制和规则是否容易地添加到IAST里面？
  • 管理和更新。是否有统一管理的方法更新IAST规则和功能？软件更新是自动化的吗？IAST包含企业级特性，如LDAP集成、强认证、企业级访问控制、数据传输和保存加密、完整的安全日志等？
  • 集成。IAST提供插件，能够和常见的安全及DevOps工具及管道集成吗？对收集到的数据有完整的API吗？这个API也包含管理员操作的功能吗？

IAST能够快速评估，因为在一个非常短的时间内，你就会知道它是否能在你的应用上工作。你可以只在几个应用上部署IAST，运行测试，得出评估结果。


文章来源: https://www.cnblogs.com/LittleHann/p/18174901
如有侵权请联系:admin#unsafe.sh