资源

RASP 和 WAF 终极对比

前言

Web 应用程序是一种很常见的数据泄露源,经常被网络攻击者用以渗透网络。这些应用程序通常都非常复杂,但是 Web 开发者一般没有太多安全知识,同时开发者和管理者对如何编写安全的程序和安全的重要性都存在严重的误解,这种误解也经常会导致安全问题频发,进而导致灾难性的后果。

那什么技术既有助于保护组织的安全,又具备足够的灵活性并且能够满足 Web 应用程序设计者的要求呢?许多行内人士会推荐“ Web 应用程序防火墙”(WAF)。WAF过滤技术通常设在 Web 应用程序的入口,提前拦截并分析所有用户请求,如果其中存在与某种攻击模式相匹配的内容,则禁止这些内容到达 Web 应用程序。WAF 需要提前收集签名,需要使用模式匹配引擎,而 WAF 的好坏就取决于这些签名和引擎的质量。于是攻击者就想尽办法去绕过 WAF 过滤,这正是安全研究领域的一个研究热点。

于是,猫鼠游戏就这样开始了。攻击者不断研究出更新、更聪明的方法,能够生成恶意输入,绕过 WAF 的输入过滤器,攻击应用程序达到预期效果。(毕竟 WAF 并不清楚应用程序是如何处理这些请求,因此,只要 WAF 认为这些输入可能被用于攻击,就加以阻止,而不考虑是否真会发起攻击,这就可能造成比较高的误杀率)。

如果我们不再通过猜测哪些输入可能存在恶意攻击,而是转而监视应用程序本身,仅阻止那些会实际改变应用程序行为特性的输入,效果如何呢?首先这种方法在应用程序本身防护,攻击者无法绕过,同时防护理解应用程序本身,能非常精确、准确的检测和拦截攻击,能有效的减低误杀率。

“运行时应用程序自我保护(RASP)”就是基于这种理念实现的。Gartner 对 RASP 的定义:一种安全防护技术,内置或链接到一个应用程序运行时环境,用于控制应用程序的运行过程,实时阻止攻击。OneASP 的 OneRASP(以下简称“ OneRASP ”)是本评估项目的核心对象,它向托管 Java 或 .NET 应用程序的服务器中增加了这一保护措施,具体做法是向 Java 虚拟机(JVM)或 .NET 公共语言运行时(CLR)中加载一个防护探针。这个探针在应用程序代码中建立一些程序点(program point), OneRASP 将只使用这些程序点来识别攻击,在不需要改变应用程序代码的情况下提供 RASP 功能。 OneRASP 的实施非常简单,只需通过简单配置将探针关联到应用程序并重启应用服务器即可; OneRASP 会将防护代码注入到重要的关键点,并实时监控这些关键点,当函数调用可能会被攻击者利用时,自动为其提供保护。

在本次评估中,我们将 OneRASP 与一个匿名WAF进行了对比,研究了它们各自的防御与检测功能。WAF就是在应用程序之前筑起一道墙,而 RASP 则是自内向外为应用程序提供保护。通过对运行时环境的检测,它无须修改源代码即可消除漏洞。与 WAF 相比, OneRASP 捕获的事件更多,极大的降低了误报率,对程序漏洞和攻击路径完全可视,并且能找到程序中未知的漏洞。

WAF与RASP比较之功能对比

在讨论我们的测试结果之前,先介绍一下WAF的定义及其缺点,并进而解释 RASP 框架的意义所在。 WAF 设置在 Web 应用程序的前方,提前截获发往 Web 应用程序的所有用户请求,并根据预定义规则对其进行评估,查看其输入内容是否可能攻击应用程序。要实现这个过程需要进行非常繁琐的配置,而且,通常 WAF 会设置“失效开放”开关以避免在高负荷情况下造成大量的误杀以及对性能的过大影响,WAF转入“失效开放”状态后会放行所有通信流量,不再进行监测,当然也不再为 Web 应用程序提供保护,而这正是 Web 应用程序最需要保护的时候。为使 WAF 在高负荷情况下也能正常工作,需要非常了解 web 应用程序的哪些输入中存在漏洞,这样才能为这些输入字段采取合适的保护措施。

RASP 技术的实现方式则完全不同,它将框架与底层代码库集成在一起,从源代码级别为应用程序中易受攻击的区域提供保护。当客户端发出一个函数调用,而调用中的参数可能会伤害 web 应用程序时, RASP 会在运行时截取该调用,然后根据具体配置,对该次调用进行记录或阻止。这种保护方法与 WAF 有着本质的区别。

用户对使用WAF的感受

安全防护咨询师对 WAF 是爱恨交加的,因为 WAF 在刚投入使用时往往是最有效的,但接下来,它的有效性会变得越来越低。

“有效性逐渐降低”这种现象发生的原因如下:一家组织决定部署 WAF ,往往是使用某项渗透测试攻击发现很多漏洞,或者是因为发生了某种安全事故。在经过成本分析之后,认为部署 WAF 的费用要低于修复程序源代码的费用(在现在开发环境下,应用程序往往需要大量的第三方工具,这些工具是无法获得源代码的,更谈不上修复代码漏洞了,部署WAF是最简单有效的方案)。在刚开始部署 WAF 时,所有参与人员都清楚地知道哪些字段和输入是容易受到攻击的,也知道对应哪些攻击类型,所以这时部署的 WAF 非常具有针对性,当然就非常有效。但随着时间的推移,清晰的信息变得越来越少,WAF的针对性也越来越差,防御效果也就相应的随之降低。

通常在 Web 应用程序新版本发布前或 WAF 修改配置后,一定要执行渗透测试,以保证没有引入新的漏洞。但许多组织缺乏足够的内部专家,无法在每次修改时都执行渗透测试,这样就错过了修改漏洞或者 WAF 配置的最佳机会。组织内部的其他部门为了能保护更多的应用程序,往往会修改 WAF 的配置,使 WAF 偏离了原来的保护意图。最后, WAF 终于不堪重负,无法正常工作。供应商通常会将 WAF 默认设置为“失效开放”状态,以避免在高负载情况下过多误杀对用户正常业务的影响。这一方案的最大弊端就是,攻击者可以有意发送超乎寻常的大量通信,远程触发高负荷条件,从而使 WAF 进入“失效开放”状态,不再为Web应用程序过滤输入内容,使Web应用程序没有任何防护。

RASP的独特能力

RASP 保护应用程序的方式与 WAF 有着本质的区别。打个比方,我们可以将 WAF 看作医用手套和口罩。医护人员在治疗受感染病人时穿戴这些手套和口罩,可以阻止部分病毒进入人体,但却不能完全阻断感染,一旦病毒突破防护,这些防护措施就失效了。而 RASP 相当于一种疫苗,使应用程序具备自我保护能力,即使恶意内容已经混入内部,也能保护应用程序免受攻击。表1对比了 RASP 工具与WAF的基本特性和功能。

表1 RASP 与 WAF 的特性对比
RASP WAF
准确性 只在可能发生攻击的关键函数调用处检查是否有恶意内容输入。并且监视输入和输出数据以及整个数据逻辑流。 基于相对原始的模式匹配对所有输入内容均进行检测。
实现价值的时间 无须了解应用程序代码中现有漏洞的位置;可以充当针对某一漏洞的虚拟补丁。 需要进行大量测试和配置,才能充分涵盖应用程序。
可靠性 不会在高负荷情况下进入“失效开放”状态——无论服务器的负载如何,总会对代码进行检测。 单一故障点;可能会在高负荷情况下进入“失效开放”状态,使原本受到保护的 Web 应用程序处于攻击威胁之下。
平台 任意能注入的应用程序。 Web 应用程序。
可视性 可以向开发人员提供详细的攻击路径和攻击信息,让修补代码漏洞异常简单。 没有提供有关应用程序的详尽信息。
网络协议 不受协议限制;可以轻松地处理各种协议如:HTTP、HTTPS、AJAX、SQL和SOAP。 只能处理能解析的协议
语言涵盖情况 理论上不限制语言,但每种语言需要开发单独的探针——目前已支持 Java ,后续会推出 PHP , .Net 等。 不限语言;不受程序设计语言类型的限制。
维护 自动获知对应用程序的修改 必须针对每个具体的应用程序学习并完全应用程序上下文才能使 WAF 达到最好的效果;同时需要根据应用程序的修改对配置进行修改以保持同步。

威胁与漏洞检测能力对比

我们对 OneRASP 和普通 WAF 的威胁检测功能进行了测试。本文后续部分全部用来讨论这一测试结果。表2给出了这两种产品的主要性能差异。

表2 测试中发现的主要差异
OneRASP WAF
能检出的攻击种类更多 由于无法在应用程序级别进行检测,所以某些攻击类型可能逃过检测
准确识别大多数攻击类型 会产生误报,尤其是 SQL 注入检测。
能检测出未知漏洞 无法检出代码中的未知漏洞,比如未经处理的异常。
在检查输入的同时也会检查输出 仅关注输入
没有精细的规则配置 配置选项精细,实现复杂

下面各节将讨论具体测试结果。

攻击类型检测

我们分别测试了 OneRASP 和 WAF 对一些常见攻击类型的检测能力,这些类型包括 SQL 注入、跨站点脚本(XSS)和强制浏览。测试结果如表3所示;在该表之后,详细讨论了针对每种攻击类型得出的结论。

表3 OneRASP 与传统 WAF 可检出攻击类型的对比
攻击类型 OneRASP 是否检测 WAF 是否检测
跨站点脚本(XSS)
命令注入
ShellShock
查询注入 查询注入 真正有威胁时检测;仅当 SQL 注入字符串真正进行查询时才会进行检测,但会漏过 XPath 注入 过度检测;由于其采用相对原始的模式匹配方式,所以会检测所有输入,会产生虚警。 过度检测;由于其采用相对原始的模式匹配方式,所以会检测所有输入,会产生虚警。
未经处理的异常
缺少内容类型
缺少 Accept 标头
不受支持的方法
漏洞扫描
强制浏览 必要时;仅检测事先配置的扩展名 强制浏览 必要时;仅检测事先配置的扩展名 最高级别;其配置选项优于 OneRASP
方法调用失败
敏感数据泄露

特别需要提出的是, OneRASP 可以提供一些非常有用的攻击和漏洞信息,大幅提高漏洞修补的效率。 WAF 是无法提供这类信息的。

跨站点脚本

在跨站点脚本(XSS)攻击中,攻击者发送 JavaScript 输入,然后由网站反馈给网站用户(这种 XSS 可称为“反射型 XSS ”)。随后,攻击者利用这一输入内容,从用户那里盗取用于身份验证的 cookie ,或者将用户引向一个恶意网站。

OneRASP 探针可以轻松检出 XSS 攻击。在测试过程中发现,它检测 XSS 攻击的方法就是在请求参数中查找字符串 <script ,只要输入内容中包含这一字符串,则禁止上传该内容。 OneRASP 可以有效地防止向 web 应用程序中注入新的 XSS 。但如果网站本来就允许用户上传 JavaScript (比如向某个消息留言板发送),那可能会产生误报。

尽管 OneRASP 在防御上述“反射型 XSS ”方面表现得非常出色,但还有另外一类 XSS ,称为“存储型 XSS ”。这种 XSS 提前将恶意内容存储在一个未受保护的数据库中,在发起攻击时再将这些内容传送到要攻击的受保护数据库中。 OneRASP 虽然可以禁止插入新的存储型 XSS ,但对于已经提前完成加载的存储型 XSS ,却是无能为力的。WAF也不能检测这种存储型 XSS 攻击。无论采取什么方法来检测这种攻击类型,都必须逐一检查所有回送给用户的 JavaScript ,查看其中是否存在恶意应用程序。但进行这种检测的结果,要么是检出率低的可怜,要么是误报率高得出奇,从而严重影响可用性。

命令注入

命令注入是对 web 应用程序最具破坏力的攻击之一;如果开发人员从不受信任的用户那里接收了输入,没有事先筛选危险字符,就在 shell 命令中加以使用,就可能发生这种“命令注入”。 XSS 攻击的是浏览器, SQL 注入是为了窃取数据,命令注入与它们不同,它首先找到运行 web 应用程序的用户,然后在它的上下文环境中运行代码,但矛头却直接指向服务器。遗憾的是,一些管理员并没有意识到这一点,仍然以根用户身份运行 Web 服务器,在这种情况下,命令注入漏洞会使运行 Web 应用程序的服务器遭受全面感染。即便以非根用户身份来运行 web 应用程序,命令注入漏洞也极具破坏性,攻击者可以将其攻击矛头由 Web 服务器转向内部主机。

OneRASP 探针可以非常可靠地检出命令注入,有时,实际注入的命令中可能会存在语法问题,无法真正在服务器上执行代码,但 OneRASP 探针依然正确检出这种命令。我们尝试了多种方法,希望能够绕过过滤检查,但 OneRASP 每次都能捕获发起的攻击。WAF也能捕获命令注入,这是因为这些注入中会有一些字符组合,通常是不会在正常用户脚本中出现的。

RASP 进行上下文相关检测的能力是独一无二的,而传统的 WAF 解决方案要么检测所有输入字段,要么仅局限于事先定义的字段。

ShellShock

ShellShock 漏洞类似于命令注入,它首先通过“用户-代理”字符串或其他请求参数,将恶意函数的定义传送给 shell ,然后滥用 bash shell 的行为特性来执行任意代码。 及时打了最新补丁的 Web 服务器是应当可以抵御 ShellShock 攻击的,但 OneRASP 在默认情况下阻止这一攻击的做法,绝对是非常恰当的。

为检测 ShellShock , OneRASP 会在窗体字段的开头搜索字符串 “()[空格]{” ,但在其文档中并未说明:是否会在请求中查找字符串 elsewhere 。 我们已经确认,只要请求中包含了这个字符串,无论它出现在请求参数中的什么位置,都会正确触发关于 ShellShock 攻击的警报。 WAF 也会在窗体字段的所有位置检测这些字符,从而可以识别 ShellShock 攻击。

查询注入

查询注入通过输入一些数据,强制目标系统进入一种错误状态,向攻击者返回他们想要的数据。这种注入也分两种形式,一种是实时发送查询,一种是提前将相关查询存储到某一位置,供日后使用。查询注入一般在针对 SQL 数据库的攻击中使用,但在任何支持查询语言的数据环境中都可能出现。

在发起 SQL 注入攻击时,攻击者会传送一些输入内容,修改开发人员设定的 SQL 查询结构,将其引向符合自己意愿的轨道。 OneRASP 首先尝试用符号来标记查询,并查找其中是否存在1=1这样的语句,以及其他不符合常理的 SQL 语法,它们是一些常见的 SQL 注入模式。(不过,一些开发人员的编程习惯不佳,会因为偷懒而在合法查询中使用这些字符串, OneRASP 文档非常恰当地对此种情况做出了提醒。)

RASP 具有独特的上下文相关威胁检测能力,而传统的 WAF 解决方案要么检测所有输入字段,要么仅局限于由管理员事先定义的字段。 WAF 方法的问题在于:要生成一组可实际应用的配置,必须提前了解那些可能存在漏洞的字段。 RASP 就没有这种困扰, OneRASP 不会检查所有输入,只有在将输入内容传送给数据库查询字符串时,才会进行检查,这样,如果可以肯定相关字段不存在漏洞,就不会将这样的字段输入误判为 SQL 注入,管理员也就不必再浪费时间,去查找那些根本无法对自己环境造成危害的攻击了。 WAF 则是另一种状况,它仍然会检测这种输入,将其误判为攻击,如图1所示

图1 被误判为 SQL 注入

除了针对一些相对原始的 SQL 模式(比如 or 1 = 1)进行测试之外,我们还尝试了其他几种“同义反复”短语,也就是将两个意义相同的词语再重复一遍,希望通过这种方式,从数据库中提取出更多数据。尽管这些同义反复短语有时的确骗过了WAF技术,但却无一逃过 OneRASP 的检测。 OneRASP 探针是根据一份参数黑名单来查对字符串,黑名单中包括了传送给 SQL 查询字符串的引号和布尔运算符。这种做法很有意义,因为任何包含布尔运算的查询都必然会改变查询的结构。。

但有某些情况下, WAF 使用的原始模式匹配方法也可能成为最佳检测工具,比如对 XPath 注入的检测就是如此, XPath 注入是另一类查询注入攻击。 OneRASP未能检测出一种非常基本的 XPath 注入字符串,而 WAF 则成功检出。(我们对其底层代码进行分析后发现,如果没有直接将输入字符串传送给对 SQL 库的调用, OneRASP 探针就不会检测“查询注入攻击”,而我们这个例子正好属于这种情况。)图2给出了一种使用同义反复短语的典型 XPath 注入。

4 XPath 查询语言从 XML 数据库(一些 Web 应用程序使用 XML 数据库来存储数据)提取数据,其方式与 SQL 非常相似。

图2 使用同义反复短语的 XPath 注入

OneRASP 在应用程序级别进行检测,我们尝试执行的所有标准 SQL 注入均被检出,偶尔有一些非标准 SQL 查询注入攻击则逃过了检测。(尽管 WAF 也捕获了我们尝试执行的 SQL 注入,但从理论上来说,RASP 的检测方法在对抗 SQL 注入攻击方面的保护效果,要优于诸如 WAF 之类的防火墙技术。将来应当还会出现利用 SQL 注入来绕过 WAF 的规避技术,我们预计 RASP 的这种低级检测方式也能捕获此类攻击。)

强制浏览

OneRASP 成功地抵御了强制浏览攻击,尽管经验丰富的用户可能并不希望配置这种保护方式。 OneRASP 探针只检查这些扩展名:.log、.bak、.old、_log、_bak 和_old。其他一些渗透测试中的常见扩展名包括.1、.2、.2015(年份)和.012015(年份和月份)无法通过配置 OneRASP 来检测的。大多数 WAF 可以禁止访问所有此类扩展名。

方法调用失败

只有在支持面向对象程序设计的语言中才会出现“方法调用失败”。发生这种错误的一般情景是:某个类型的一个对象错误地调用了其基类的一个方法。这种性质的 Bug 特别危险,因为只要它们没有生成错误日志或者其他明显的输出内容,就可以一直隐藏下去。如果在数据库处理事务期间发生 SQL 异常, OneRASP 可以检测出“方法调用失败”,这时发生的“方法调用失败”不会向用户显示任何输出结果。

通过检测“方法调用失败”,既可以识别底层漏洞,也可以识别攻击。在此次评估期间,我们使用的 Web 应用程序是在过去使用过的, OneRASP 在其中检出的许多错误却是我们过去所不知道的。所有这些错误都没有出现在标准的 Web 应用程序日志中,也都未向用户显示。尽管对于用户来说,通常不会看到 Web 应用程序中的此类错误,但攻击者也许可以编写一些新颖的、不同寻常的攻击代码,来利用这些错误。 OneRASP 在检测这些错误时,检测的是 API 调用本身,而不是查看输出内容,因此,可以在生产环境中,用它识别底层应用程序错误。

WAF基本上不能检测“方法调用失败”,如果应用程序不显示错误信息,即使 WAF 对返回数据进行检查也无能为力。

未经处理的异常

通过“未经处理的异常”,攻击者可以深入了解一个应用程序的工作方式。有一个潜在风险:攻击者通过研究服务器的堆栈跟踪输出,可能会发现应用程序使用了哪些存在漏洞的库函数,从而找出攻击路线图。

我们在对被测 Web 程序进行配置时,有意使其抛出未经处理的异常,用以模拟 Web 应用程序的一种常见错误配置。

OneRASP 能够检出这些异常,而 WAF 仅关注输入,同时没有一种通用输入可以触发“未经处理的异常”,因此无法检出“未经处理的异常”。

侵犯隐私

尽管在泄露敏感数据后可能会被处以高额罚款,但开发人员往往没有意识到,自己的应用将敏感信息存储在什么位置。甚至一些经过审核的应用程序,也可能在遭受攻击时泄露敏感数据。应用程序可能会将敏感数据写到它们的日志文件中。当应用程序未能正确处理攻击者发送的输入内容时,尤其可能向日志中写入敏感数据。于是,攻击者可以利用他对应用程序的访问权限,查看应用程序的日志文件,从中提取敏感数据,比如支付卡号之类。

OneRASP 在检测敏感信息时共有两类规则,一类用于信用卡号,一类用于社会保障号( SSN ),这两种信息都属于攻击者最希望得到的数据。这两类规则的默认操作都是改写(或遮罩)输出内容,这一操作将可用性和安全性完美地结合在一起。如果敏感数据的输出是正常操作的结果,而不是由于攻击造成的,此操作可以继续进行,但日志文件中的敏感数据将被遮罩起来。

图3是将敏感数据发往服务器日志文件时, OneRASP 对其进行检测的示例。

图3 敏感数据检测

在库函数调用的级别来检测和遮罩此类数值时,即使应用程序本身已被攻破,也可以保证敏感数据不被泄露。在遮罩信用卡和 SSN 时, OneRASP 采用的算法是模式匹配方法;比如,用###-##-####表示 SSN 。但是,各组织需要对 OneRASP 进行配置,使其能够识别和匹配其他模式——比如过滤医疗记录号或银行账号,该产品目前缺少的特性。

OneRASP 不仅检测出了 WAF 未能检出的敏感数据,我们相信它的这一功能对于审核人员也非常有用。在应用程序中,可能会在一些出乎意料的位置存有敏感数据, OneRASP 的这一功能可以帮助审核人员找出这些位置。

不受支持的方法

有些请求会用到一些不太常用的HTTP请求方法, OneRASP 可以提供保护措施,有效的屏蔽此类请求。它将除 GET 、 POST 和 PUT 之外的所有 HTTP 方法都看作“不受支持的方法”。(但是,有一些代码质量较差的客户端,可能使用混合大小写形式发送这些请求方法,从而触发误报。)受保护的应用程序可能还会用到其他一些请求,对于诸如 DELETE 、 OPTIONS 或 TRACE 之类的方法提供合法支持。 RASP 产品需要提供可配置的白名单供企业自定义那些方法是支持的。

(对于我们使用的 WAF ,在阅读其配置注意事项后发现,让传统 WAF 来检测“不受支持的 HTTP 请求”是可以实现的,但心理承受能力较差者慎用。)

OneRASP 和 WAF 都能成功地检测出不受支持的 HTTP 方法。

图4给出了 OneRASP 在检测这一攻击时的屏幕显示。

图4 不受支持的 HTTP 请求方法

缺少内容类型

攻击者可能故意省去请求标头中的内容类型,借以绕过对文件类型设定的上传限制条件。 OneRASP 和 WAF 都能轻松地检测出这一攻击矢量。

缺少 Accept 标头

HTTP 并没有严格要求必须提供 accept 标头(这个标头就是告诉应用服务器,客户端支持什么语言,或者支持哪些字符集),但几乎所有合法的客户端都会在请求中发送这一标头。许多自动扫描引擎无法包含这些标头,因此,可以将缺少 Accept 标头看作出现自动攻击的一个预警。 OneRASP 和 WAF 都检出“缺少 accept 标头”的情况。 OneRASP 的详细输出结果在图5中给出。

图5 HTTP 请求中缺少 Accept 标头

已知漏洞扫描器

漏洞扫描器经常在其探测中嵌入一个预定义的用户代理字符串,显然,安全防护分析员们会努力阻止攻击者使用它们。 OneRASP 和 WAF 都可以检测出已知漏洞扫描器的用户代理字符串,不过, OneRASP 的文档中未明确说明能够检测哪些漏洞扫描器,而且这个扫描器清单也无法进行配置。

总而言之,我们的测试表明, OneRASP 能够对抗的攻击类型要多于 WAF ,有些攻击类型甚至是 WAF 根本就无法看到的。

结论

在我们的测试中, OneRASP 的性能要优于传统 WAF ,它可以对抗一些会被 WAF 漏过的漏洞类型。虽然我们是针对某一具体 WAF 进行测试的,但可以放心地推广其测试结果,同样适用于其他查看 HTTP 请求参数的 WAF 产品。

此外, OneRASP 在测试过程中证明了它的另外一项价值:在应用程序中检测出我们之前并不知道的漏洞,并可以提供可用于补救工作的具体信息——这是 WAF 根本无法完成的。 OneRASP 可以让人们深入了解它所保护的应用程序,在这方面远远超过了 WAF 。

OneRASP 能够在 API 层进行监测,这使它可以检出传统 WAF 会漏过的一些攻击。它的误报率也要远低于传统的 WAF ,这是因为它在进行匹配时会考虑上下文环境。

尽管在配置 OneRASP 时,其精细程度可能无法达到 Web 应用程序专家的期望值,但大多数商用 WAF 引擎也缺乏这种精细配置功能,因此,这一功能无法在市场上区分这两类产品。 OneRASP 可以进行自定义配置,其精细程度要高于通过标准用户界面完成的配置,这样多少可以减少我们的一些顾虑。

由于 OneRASP 具有即插即用方法,所以其可用性要高于所有传统 WAF ,可以通过最少量的配置工作(甚至完全不需要进行配置),即可立即为 Web 应用程序提供保护。这一功能可以在部署后立即为应用程序提供保护,从而极大地降低了风险。最后, OneRASP 可以防御未经处理的异常、方法调用失败和敏感数据泄露:这三类攻击是 WAF 看都看不到的。由于它提供与上下文有关的保护措施,所以在检测 SQL 注入时的误报率也较低

准备采用 WAF 来保护 Web 应用程序的人们,应当考察一下 RASP 解决方案,比如 OneRASP ,将其作为有效的替代方案。如果已经部署了 WAF ,但发现攻击者可以绕过它,或者误报率过高,那也应当考虑 RASP 解决方案,扩展其保护方法。