原文链接:https://snyk.io/learn/application-security/iast-interactive-application-security-testing/#what-is
阅读时间:5分钟
在构建新型服务或应用程序时,将安全性放在首要位置至关重要。毕竟,安全漏洞可能在一眨眼间给您的业务带来不可估量的损失。有许多不同的方法来检查您的应用程序的安全性。虽然没有一种方法可以百分之百地保证安全性,但您应该始终努力保持应用程序的安全性并努力改进应用程序安全性。
什么是交互式应用程序安全测试 (IAST)?
交互式应用程序安全测试 (IAST) 是一种应用程序安全测试方法,它在应用程序实际使用时(由真实用户或自动化测试运行程序)测试应用程序的执行过程中的漏洞。一些 IAST 工具甚至带有 IDE 集成,允许您在开发应用程序时运行安全性分析。
IAST 工具的核心是传感器模块,这是包含在应用程序代码中的软件库。这些传感器模块在交互式测试运行时跟踪应用程序行为。如果检测到漏洞,将发送警报。
此类漏洞的例子可能包括在明文中硬编码 API 密钥、不对用户输入进行净化或使用没有 SSL 加密的连接。
IAST 如何与其他安全测试方法不同?
为了帮助您确定特定安全测试方法是否适合您的应用程序测试环境,重要的是要考虑它所提供的内容以及其局限性。让我们来看一下这些测试方法之间的区别。
静态应用程序安全测试 (SAST) 专注于代码。它在 CI 流水线的早期阶段工作,扫描源代码、字节码或二进制代码,以识别违反最佳实践的问题编码模式。SAST 是依赖于编程语言的。
动态应用程序安全测试 (DAST) 是一种黑盒测试方法,它在运行时扫描应用程序。它应用于 CI 流水线的较后阶段。DAST 是防止回归的良好方法,不依赖于特定的编程语言。
IAST 类似于 DAST,因为它关注运行时应用程序行为。但是 IAST 分析实际上是基于黑盒测试、扫描和分析内部应用程序流程的组合。IAST 的好处在于它能够将类似于 DAST 的发现与类似于 SAST 的源代码链接起来。这种方法的缺点是它使 IAST 依赖于编程语言,并且只能在 CI 流水线的较后阶段执行。
软件组合分析 (SCA) 专注于应用程序中使用的第三方代码依赖关系。在使用许多开源库的应用程序中,SCA 非常有效。这种方法也是依赖于编程语言的。
IAST 的优点和缺点
IAST 本质上是 SAST 和 DAST 的结合。IAST 方法仅分析在测试中执行的代码,类似于 DAST,但它也像 SAST 一样准确定位漏洞在代码中的确切位置。
IAST 与 DAST 和 SAST 有所不同,但为什么要使用它?让我们来看看 IAST 的主要优点:
扫描生产代码:IAST 最大的优点在于它能够扫描实际在生产环境中使用的代码。SAST 工具往往会给开发人员带来误报。有时一行代码可能指示一个安全问题,在代码库的其他部分已经得到解决。IAST 关注那些真正重要的问题。
扫描开发代码:虽然扫描生产代码是一个巨大的优势,但 IAST 也可以在开发过程中使用。一些 IAST 工具带有 IDE 集成,以便给工程师快速反馈他们正在实施的功能。这将安全检查向开发生命周期的左侧转移,这样在修复问题时更为经济高效。
快速修复:IAST 将问题与代码位置关联,这是它与 DAST 不同的地方。IAST 允许您浏览应用程序以查找问题,并提供快速修复的建议。这并不是没有风险的。只是因为您从未测试过代码,并不意味着它在生产环境中没有安全漏洞。另一方面,开发人员的时间有限,他们必须明智地投入。
IAST 也有其缺点:
依赖编程语言:IAST 的一个主要缺点是依赖于编程语言。虽然有些工具不需要您更改代码以包含其传感器模块,但它们仍然受限于特定的技术。如果您恰好使用了一个不太流行的技术,因为它完全适合您的用例,那么 IAST 可能不是适合您的选择。
耗时:IAST 测试方法需要构建和执行应用程序(而 SAST 不需要),因此在长期内需要投入大量时间。对于在开发中捕获的问题来说,这可能不是个问题,因为可以使用 IDE 插件进行快速反馈。但是,当您想要构建大型测试套件并在所有生产发布上运行时,事情可能会变慢。
没有 100% 的代码覆盖率:仅扫描实际执行的代码的缺点是 IAST 不会扫描所有代码。虽然它消除了许多误报,但它也忽略了您的质量保证在测试中忘记运行的代码。只是因为您没有考虑到它,并不意味着代码不会在生产环境中执行。
选择 IAST 之前了解您的需求 与每种应用程序安全测试方法一样,在选择之前分析您的技术堆栈和流程是很重要的。根据您选择的编程语言,IAST 可能甚至不是一个选项。在这种情况下,您必须退回到 DAST,它只检查应用程序的输入和输出,并不扫描代码。
虽然 IAST 可能为您的应用程序提供 SAST 方法无法得出的关键安全见解,但 IAST 也可能会显著减慢您的 CI 流水线。因此,基于 SAST 的解决方案在日常情况下可能是更好的选择。
这个文章存在一定的倾向性,可能因为Snyk是一家以SAST为主的厂商吧。
文章最后的结论是”基于SAST的解决方案在日常情况下可能是最好的选择“,而用于作为论据的第一条则是”(IAST)依赖编程语言“,实际上SAST和IAST都是依赖编程语言的,从这点并不能证明SAST的优势;对于第二条“耗时”的问题,如果对于有标准DevOps流程或测试流程的应用来说,IAST并不会显著增加应用发布的流程,这条不是很成立;而“没有 100% 的代码覆盖率”这一条所指的问题的确存在,特别是对于存量而不是增量的业务,但企业可以对存量业务做一次专项的测试来解决这个问题。
另外也更正一个原文提到的IAST的“优点“——能够扫描实际在生产环境中使用的代码。但实际上IAST因为深度的漏洞扫描会对应用的资源造成较大的消耗,虽然有对生产环境发现问题的能力,但IAST依然只适用于测试环境而不是生产环境。
实际上,我一直认为几款AST产品是互为补充的,将不同技术特点的产品用于其擅长的场景才是王道。但不同的企业可以根据自身的安全阶段和团队情况来决定导入相关产品的优先级。
我觉得你说的很有道理 alert(/xss/)