这篇文章是ContrastSecurity的CTO和共同创始人，JeffWilliams于年末写的一篇文章，对IAST描述的非常清楚，其中谈到的技术，我们今天还在做。对于IAST的深刻理解，非常值得我们学习。
一、介绍
交互式应用安全测试（InteractiveapplicationsecuritytestingIAST）是一个在应用和API中自动化识别和诊断软件漏洞的技术。如果从名字的缩写来看，插桩（Instrumented）式应用安全测试或许是一个更好的说法。IAST不是一个扫描器，重要的事说两遍，它不是一个扫描器，IAST持续地从内部监控你应用中的漏洞，在整个开发生命周期中，IAST通过你在开发和测试中使用的工具，实时地提供报警。
IAST最显著的特性是它使用插桩来收集安全信息，直接从运行中的代码发现问题，不是源代码扫描（SAST），也不是HTTP扫描(DAST)。但那并不意味着你要等到产品上线时才使用它，恰恰相反，你可在IDE中，当开始编写和测试第一行代码时，就使用IAST。
了解IAST在完整的应用安全技术策略中的位置非常重要，有两个主要自动化应用安全的方法，你都要考虑到：
1、在开发时阻止漏洞
IAST自动地发现应用和API的漏洞，这样可以在开发过程早期就进行修复，成本不会那么高。IAST在检测速度，精确度，流程上都比传统的SAST和DAST有优势，某些IAST还包括开源软件安全分析功能。
2、在生产阶段检测攻击和阻止漏洞利用
RASP在运行时阻止漏洞被利用，而不是像Web应用防火墙（WAF）那样通过检查网络流量来阻止攻击。RASP并不仅在精确度和扩展性上优于传统的Web防护方法，还能提供在几分钟内将多个业务系统部署新的防护手段的所需架构。（注：RASP也使用插桩的方法，和IAST技术基本一样，有时会把这两个技术等同。）
我们强烈推荐你把IAST加入到认可的应用安全测试技术名单中，它在年出现，许多最大的金融、技术和医疗保健公司已经采用了IAST技术。在本文中，我们将探索如何把IAST集成到整个软件生命周期中，实现最经济的漏洞检测。
二、什么是IAST？
交互式应用安全测试使用软件插桩收集安全信息，并直接从运行中的代码发现问题，以实现自动化识别和诊断在应用和API中的软件漏洞。
IAST可以访问代码本身，能够在每行代码执行SAST，而且，IAST可以访问HTTP流量，也能够在每一次请求和响应时，执行类DAST的分析，因此，IAST的规则是SAST和DAST的一个功能合集。
接下来，我们会探索你使用IAST能够做到的事情，IAST的两个主要能力如下：
·自有代码安全测试：IAST能够自动化地分析应用和API中的自有代码，找出以前没有发现的（零day）漏洞，能够识别很宽范围的漏洞，包括并不限于OWASPTop10，还有其他更复杂的漏洞。
·开源软件安全测试：IAST也能用来测试开源库和框架的安全性，一般有两个维度。首先，IAST能识别困扰开源软件的已知漏洞（如CVE发布），其次，IAST能识别开源软件中以前未知的（潜在）漏洞。
1、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使用这个信息识别出架构缺陷和安全缺陷。
·配置—IAST能访问应用、框架、应用服务器、和平台的配置，保证正确的安全配置。IAST甚至能查询应用组件的运行时配置，如XML解析器。注意某些平台，如.NET，重度依赖配置来实现安全。
2、IAST分析引擎如何工作
IAST探头生成一个安全相关事件的数据流，导入进分析引擎，这个引擎能强制实施多个规则。
事实上，IAST为一个程序建立了一个安全护栏，如果探头探测到的数据流，表明程序的行为已经违法越过了这些护栏，就会被报告为漏洞。
IAST常常使用多个不同的信息源来证实一个漏洞，例如，当一个暴露的端点，是non-XHR，或者状态正在改变，或者没有包含token检查，就可以确定是一个CSRF（跨站请求伪造）漏洞。IAST能够访问HTTP请求，分析是否一个交易修改了文件或写到存储设备里，评估是否一个控制流包含一个token检查，通过在漏洞分析中，使用所有这三种类型的数据，IAST得出准确的结果，不会漏报也不会误报。
三、我们为什么需要IAST？
问题很简单，我们在应用安全方面，有大量的问题。但应对这些问题的安全专家有限，全世界几乎有万的开发人员。传统的工具要求安全专家和应用一起工作，训练工具，解释结果。这些工具80%的费用是有效使用工具的“人的费用“，没有真正的自动化。
1、“工具困境”不起作用
“工具困境”是指你为工作准备的工具都不是很好用，因此，你不得不运行一系列工具，希望能得到一个好的结果。
在安全领域，十余年来，我们一直在尝试这种“混合”的方法，但确实没什么作用。
想像一下，使用SAST，DAST，还有SCA工具的结果去检测CSRF漏洞的情形：
静态分析:
静态分析工具仅仅能尝试检测没有被token检查保护的数据流，不管他们是状态变更还是通过XHR访问。结果或者是花费大量时间的误报，或者是危险的漏报。
动态分析：
DAST工具能够标记不包含CSRF令牌的表单，但无法知道是否他们在状态变更，因此，结果结果或者是花费大量时间的误报，或者是危险的漏报。
开源软件分析：
SCA工具只能标记含有已知漏洞的库，将会错失所有没有被安全专家暴露和发布的安全漏洞。
运行所有这些工具，浪费时间和宝贵的安全技能。但更重要的是，很难关联安全测试结果。静态工具能够报告源代码行数，动态工具报告HTTP请求，开源工具报告库版本号，没有好的方法来关联这些报告。最好的关联工具减少15%-35%发现结果。因此，如果你有两个工具，每份报告了个发现结果（对于静态工具，一个保守的估计），你会得到缩减后的个结果。总之，仅仅合并噪音和不精确的报告是不经济的。
2、传统的应用安全工具和现代软件不兼容
现代软件开发速度更快，正在加速发展。许多项目按周、天，甚至小时的频率来部署代码。不幸的是，像SAST、DAST、模糊测试、人工渗透测试、人工代码检查无法跟上现代软件的速度和规模。
传统应用安全工具的最大挑战是：
·精确性：传统工具的最大问题是精确度。SAST和DAST产生大量的误报（不是真实的漏洞）和漏报（错失真正的漏洞）。工具不精确的时候，安全专家必须执行手动步骤来解决问题，这个流程耗费大量时间，导致软件开发的很大瓶颈。相比传统工具，IAST有一个巨大的信息优势，精确度的提高意味着开发人员能够直接使用结果，不需要专家介入。
·兼容性：现代应用，特别是API，基于复杂的框架打造，自动把客户端流量和和功能对应到一起，从复杂的数据结构中解析出结果，如XML，JSON，序列化对象。没有大量定制的情况下，SAST无法跟踪这些路径，DAST无法模拟测试要求的复杂流量，IAST对这些问题具有很好的免疫力，因为它只观察运行时的复杂应用和API。
·速度：现代软件方法，像敏捷和DevOps，进展得非常快。目标是在开发者和上线之间完全自动化。然而传统的工具花费许多小时去执行一个完全的分析（甚至不考虑使用专家分诊，去除误报）。当一个开发人员在他们的IDE环境中编译和测试代码时，IAST提供及时的反馈。IAST还能和QA一起运行测试，如果发现安全问题，能够马上停止编译。
·扩展：安全工具必须能够使用多个规则，持续分析应用的整个组成。传统的扫描按顺序运行，无法扩展到整个企业。IAST是一个针对应用安全，完全分布式和持续的方法，意味你所有的应用和API能够被持续并行访问，因此你的安全也就能一直保持在最新的状态。
·流程适合：IAST位于已经存在的开发工具和流程的顶端，不需要额外的步骤。做正常开发和测试时，IAST在后台运行，因为IAST非常精确，能在不了解漏洞的情况下发现它们，不需要专家，任何人都可以使用IAST做安全测试，生成干净的代码。
四、IAST架构
既然许多人仍然不熟悉IAST，这里有助于说明IAST和其他类型的安全防护如何配合。
上图显示IAST在NIST的CybersecurityFramework中的位置。IAST完全集中在应用安全这一行。除了检测和识别漏洞，某些IAST实施能帮助识别和分析应用。
网络到应用全栈中的IAST
使用基于插桩的方法来实现安全，并不限于应用层。安全专家已经认识到，我们可以不再只从外部来检测漏洞，外部的视角，并不能提供足够的上下文信息精准地识别漏洞，从内部做漏洞检测更容易，更精确。这种基于插桩的安全测试（和基于扫描的安全测试对比）趋势正在网络到应用的全栈中实现。
IAST是基于插桩的方法保护应用层。许多其他插桩方式的安全产品也都承认插桩的好处。不管在哪一层，直接访问都比从外部视角来测试，有很大的优势。
既然IAST直接把安全搭建在软件栈中，应用在任何环境下都会非常安全，包括在云、PAAS、VM和数据中心中。
五、部署一个IAST方案
对企业组织，IAST是一个能够横跨整个应用和API组件集，建立持续安全测试的有效方法。使用IAST，组织能在所有的应用组件中，持续并行地执行应用安全测试。
1、保护企业的应用组件集
许多组织仅仅测试应用组件集中的一小部分，一些组织只测试重要的应用，其他组织的策略是测试所有面向外部的应用。更可能的是，你主要的网站没有受到攻击，而是合作伙伴的网站、一个复杂的移动API、或内网的业务应用受到攻击。这就是为什么保护所有应用和API，甚至非webAPI的重要性。
对许多外部和面向公共的应用，许多组织保留安全测试。事实上内部应用和外部应用的概念，取决于工作安全边界。不幸的是，由防火墙和其他网络安全设备建立起来的边界，已经变得千疮百孔，意义不大。例如，一台员工工作站，被攻击者变成内部的跳板，边界变得无关紧要。考虑测试你的整个应用组件集，包括内部应用。
2、在管道中的IAST
记住，IAST不像一个扫描器，IAST有效地变成了应用的一部分。它能在应用运行的任何地方运行，包括开发人员的IDE，本地测试服务器，QA机器等。作为CI/CD构建的一部分，在容器中，在云中，你代码运行的任何地方。在整个软件生命周期中，你软件运行的任何地方，你都可以使用IAST。在集成和测试环境，在上线环境，尽早的使用IAST有很多好的理由。
下图描述了一个简单开发管道，使用IAST持续的发现漏洞。
你能够选择在软件生命周期中的哪个阶段使用IAST。因为IAST不需要额外的步骤。IAST和所有软件开发的不同方法兼容。特别适合DevOps，DevOps对工具敏感，需要专家贴身服务很长时间。
3、安装和配置
安装的过程非常简单，一个典型的IAST方案通常包括两部分，IAST代理，和IAST控制台。你在控制台生成一个账户，下载一个IAST代理，执行分析，发送结果给控制台。
第一步是在你的环境中增加IAST代理，和增加一个库一样，设置环境变量，当你使用应用，IAST代理自动在后台做安全测试，重要的是，你不需要攻击应用，得到安全结果。IAST能被任何人使用，甚至刚开始做开发工作的新人。
IAST控制台让你管理整个应用组件集的安全，并行地处理。管理安全策略，配置安全控制，和其他常见开发工具集成，实现漏洞通知。
4、在开发中部署IAST—流程和集成
在开发中，我们的目标是赋能开发人员发现和修复他们自己的漏洞，提交清洁的代码。但我们必须避免拖累他们，或给出误报结果，浪费他们时间。
IAST是实现这些目标的好伙伴，因为他提供即时反馈，定位准确的代码行，在本地环境中测试。IAST可以通过IDE、或者聊天程序、缺陷追踪、其他软件的集成来报警。因为IAST提供精确的代码行，完整的HTTP请求，完整的数据和控制流，开发者的工作变得容易。他们能够修复代码，使用HTTP请求来再测试，验证问题是否解决，提交清洁代码。
5、在CI/CD和QA环境中部署IAST-流程和集成
在QA环境中，我们保证开发人员已经做了正确的事情，消除了任何漏洞。我们有自信在上线之前，消除了漏洞。万一遇到严重的安全漏洞，我们需要有停止构建的能力。但我们不能放慢构建的速度，也不需要安全专家的介入。
IAST非常适合在QA环境中做安全测试，因为它和你正常的自动化和人工测试一起，在后台自动化执行安全测试。在这个环境中，IAST通过其他CI/CD工具提供通知，也能根据审计和合规的要求，出具报告。
6、生产环境部署IAST
在生产环境做安全测试并不是一个很好的主意。理想情况下，你应该在上线之前很久就修复任何安全问题。然而，常常有许多不再主动开发的传统应用，还有第三方产品，只能在生产环境。我们仍然需要持续保证这些应用没有漏洞，我们也希望知道，是否有新的漏洞会影响这些应用。
虽然没有开发和测试环境中使用的这么普遍，IAST也能有效的使用在生产环境。因为IAST不要求源代码。能够在任何可以安装IAST代理的应用中使用，但也要考虑到IAST的性能问题。虽然速度很快，在开发和测试环境中没有被注意到，在生产中，即使几微秒也无法接受。注意，IAST可以配置，如“取样模式”，能明显地改善生产中的性能，并能随着时间提供很大的安全保护。
六、选择一个IAST方案
在这部分，我们会探索一些当你评估IAST解决方案的时候，你要考虑的关键标准。所有IAST产品工作起来都有区别，你要仔细地评估他们，保证他们能在你的环境中工作。
1、相关部门
在这个选择的过程中，你要考虑多个不同的部门：
安全部门—安全部门，很显然在漏洞管理中，扮演着一个重要的角色。在整个组织的应用和API组件中，IAST是一个主要的漏洞提供者，应用得好，IAST能够帮助开发在早期消除大多数漏洞，不需要安全部门的介入。
开发团队—开发团队有很大的责任，保证应用和API没有漏洞。开发团队经常有使用安全工具的噩梦经历，也许会怀疑IAST能力，因此关键是确保他们理解IAST的优点，得到他们的支持。
DevOps—DevOps团队一个重要的工作是推动软件快速上线。这和静态及动态扫描都不兼容，因为他们要花费很长时间来扫描，要求大量工作去消除误报。IAST能帮助DevOps团队把自己的安全做好，提供完全自动化的方法，在安全上很自信地推动代码上线。
管理团队—对应用安全的自信能够帮助管理层做出数字化转型的决定，向DevOps转移，或向云上转移。保证IAST作为认可的应用安全测试技术，能帮助业务转型。
2、技术考虑
语言支持—不同的厂商支持不同的语言，因此你要保证IAST支持你重要的应用和API正在使用的语言。
框架支持—应用框架和语言同样重要，除非IAST支持你正在使用的框架，否则在检测漏洞方面不会有效。
精确度—你会想使用一个包含一系列真实漏洞的应用，来评估精确度。仔细测试IAST的识别能力，没有误报。使用OWASPBenchmark看到操作详情，来衡量应用安全测试工具的好坏。
扩展性—考虑到应用组件集的数量，包括API，内部应用和产品。是否IAST能够扩展到持续分析所有的应用？达到这个水平需要多少人来支持。
规则集覆盖—寻找一个宽泛的规则集，覆盖你关心的攻击。包括CVE。
可见性—IAST有它自己的仪表盘吗？或仅仅是依赖缺陷跟踪系统。输出什么样的报警，通知、报告？有IDE和CI/CD插件支持吗？
安装—大多数IAST产品安装简单，不要求流程变更。安全可以自动化吗，是否可以被增加到容器和镜像里面，可以自动地支持新的应用？
配置—是否IAST要求复杂的配置，来实现精确的分析？常见的安全控制和规则是否容易地添加到IAST里面？
管理和更新—是否有统一管理的方法更新IAST规则和功能？软件更新是自动化的吗？IAST包含企业级特性，如LDAP集成、强认证、企业级访问控制、数据传输和保存加密、完整的安全日志等？
集成—IAST提供插件，能够和常见的安全及DevOps工具及管道集成吗？对收集到的数据有完整的API吗？这个API也包含管理员操作的功能吗？
IAST能够快速评估，因为在一个非常短的时间内，你就会知道它是否能在你的应用上工作。你可以只在几个应用上部署IAST，运行测试，得出评估结果。
七、在常见的使用场景中应用IAST
在这部分，我们探索如何使用IAST解决常见的安全问题。一般来讲，IAST能够识别和诊断软件本身的漏洞，不是容器，也不是操作系统或者网络攻击。
每个产品都不一样，但因为IAST可以访问代码、HTTP流量、许多其他的安全信息资源，它能解决一个宽范围的漏洞。
注意下列的IAST发现的漏洞名单包括深入到代码的漏洞（传统上只有SAST能够发现），和HTTP流量的漏洞（传统上只有DAST能发现）
注入—SQL注入，NoSQL注入，反射式跨站脚本，存储式跨站脚本，路径遍历，命令注入，LDAP注入，XPath注入，表达式语言注入，OGNL注入，,ExpressionLanguageInjection,OGNLInjection,HibernateInjection,头注入,Java反射注入，日志注入，不安全代码执行，XML外部实体注入(XXE)
HTTP头–Caching,Anti-ClickjackingControls,HSTS,不安全Cookie,ResponsewithInsecurelyConfiguredContent-Security-PolicyHeader,ResponsewithInsecurelyConfiguredStrict-Transport-SecurityHeader,ResponseWithX-XSS-ProtectionDisabled,ResponseWithoutContent-Security-PolicyHeader,ResponseWithoutX-Content-TypeHeader,VersionHeaderEnabled
解析-XMLExternalEntities,UntrustedDeserialization,ParameterPollution,RegularExpressionDoS,UnvalidatedRedirect,UseofreadLineonUntrustedStreams,TrustBoundaryViolation,UncheckedAutobinding
认证–InsecureAuthenticationProtocol,UnprotectedConnectionStrings,SessionCookieHasNosecureFlag,SessionRewriting,ExpiredSessionIDsNotRegenerated,FormsAuthProtectionMode,FormsAuthenticationCross-AppRedirect,FormsAuthenticationSSL,FormsWithoutAuto