攻击者如何绕过常用的Web应用防火墙？

许多Web应用防火墙（WAF）很容易被攻击者绕过。攻击阅读本文后，绕过你就可以知道如何判断自己的常用WAF是否易受攻击以及如何修复它了。

基于云的应用Web应用防火墙（WAF）提供了一系列出色的保护，然而许多黑客声称
，防火他们连最复杂的攻击WAF都能轻松绕过 ，能对受保护的绕过资产执行攻击查询，而不受到惩罚。常用

应用程序交付和安全平台NetScaler的应用威胁研究团队发现 ，许多基于云的服务器租用防火WAF确实很容易被绕过。如果你打算购买WAF服务
，攻击就需要运行测试以确保WAF能够起到应有的绕过功效
，以保护你的常用应用程序和API。

建议你对自己的应用环境进行一番简单的测试
，以检查WAF服务是防火否提供最佳保护。

在本文末尾概述了几个经常被忽视的简单步骤 ，以帮助你确定是否有人已经绕过了WAF，并危及Web应用程序和API的高防服务器安全性。

首先不妨看看攻击者绕过WAF防御的最常见方法。

最常见的WAF攻击

基于云的WAF和本地的WAF是作为一项服务提供的安全解决方案
 ，旨在帮助保护Web应用程序和API免受开放Web应用程序安全项目（OWASP）记载的各种攻击
。最常见的WAF攻击包括如下 ：

注入

说到通过像Web应用程序这样的入口窃取大量数据 ，SQL注入是一种切实可行的免费模板方法。注入攻击最早记录于25年前，至今仍被广泛使用。

数据库查询的开始 ，常常被设计成检索所有信息，然后是过滤器仅显示一条信息。比如说，一个常用的查询首先检索所有客户信息
，然后过滤特定的客户ID，数据库对照表中的每一行执行此命令，并返回该语句为真的模板下载表行上所请求的信息 ，通常这是单单一行。攻击者操纵用于填充此类查询以插入数据库命令的表单字段，导致对表中的每一行计算结果为true的语句 ，从而在响应中返回整个表的内容 。在理想情况下，开发人员总是会保护表单安全，因此注入攻击不可能得逞。然而 ，源码下载开发人员有时可能容易出错，因此并非所有表单字段都一直受到保护。

最新的OWASP十大列表如今在注入类别中包含了跨站脚本攻击。在跨站脚本攻击中
，攻击者将脚本插入到你的网站或Web URL中，以便毫无戒备的受害者在浏览器中执行这些脚本，从而允许攻击者将cookie、会话信息或其他敏感数据传输到他们自己的Web服务器。

失效的访问控制

失效的访问控制允许攻击者在应用程序或API开发人员的预期行为之外进行操作 。源码库该漏洞可能导致未经授权的信息泄露、所有数据被篡改或破坏 ，以及能够越权执行业务功能。

OWASP最近将失效的访问控制严重性提升到了Web应用程序十大漏洞的第一位
。新发现的重要性在于 ，这个漏洞类别特别适用于API——与已经存在了很长时间的Web应用程序相比
，API是一条比较新的攻击途径 ，攻击者发现API并试图从中泄露信息。由于API不是为人工输入而设计的，因此用于Web应用程序的相同类型的验证输入和检查可能不是开发人员最关心的 ，有时API是在安全团队和运维团队不知情的情况下发布的 。

易受攻击和过时的组件

每当在常用组件中发现新的漏洞
，就会导致大量机器人生成的流量扫描互联网，寻找可能被破坏的系统。如果你搭建了一台Web服务器，允许别人通过互联网来访问
，很快就会看到向新搭建的Web服务器上 ，并不存在的特定类型的应用程序发出请求的日志条目 ，这种活动只是黑客在互联网上广撒网，寻找易受攻击的服务器。

WAF的主要功能是检查HTTP请求的内容——包括攻击载荷所在的请求体和请求头，并决定是应该允许请求还是阻止请求 
。一些WAF还会检查响应 ，以评估是否存在未经授权的数据或敏感信息泄露，它们还将记录响应结构（比如Web表单或cookie），从而有效地确保后续请求不被篡改 。

WAF的三种类型

Web应用程序和API防火墙通常有三种模式：消极模式
、积极模式和混合模式 ：

消极安全模式

使用简单的签名，并预加载已知攻击  ，如果存在匹配 ，将阻止请求 。你可以把这当成“拒绝列表”
。换句话说 ，默认操作是“允许”，除非找到匹配项 。

积极安全模式

积极安全模式预加载已知“良好”行为的模式。它将请求与该列表进行比较 ，只有在找到匹配项时才允许请求通过 ，其他的一切统统被阻止 ，这将被视为“允许列表”。在这种情况下 ，默认操作是“阻止”，除非找到匹配项。积极安全模式被认为比消极安全模式安全得多——它可以阻止零日攻击 。

混合安全模式

使用签名作为第一遍机制 
，然后处理请求以查看它是否与允许列表匹配。你可能会问：“既然攻击不在允许列表中，为什么使用允许列表
？”原因是所需的处理更少 ，因为消极安全模式使用签名来阻止请求，而不是像积极安全模式那样处理一切。更多的处理意味着更庞大的WAF设备或更高的基于云的托管成本。

所有三种WAF安全模式都有一个共同点：它们检查入站请求并查找威胁。请求端检查的有效性取决于WAF在寻找什么以及它们检查请求负载的细粒度。

攻击者如何利用WAF限制和IT部门缺少摸底调查大做文章 ？

攻击者意识到，对于大多数组织来说，寻找流量中的攻击需要庞大的计算开销  ，而商业检查解决方案旨在尽可能高效地匹配实际用例 。他们知道实际的HTTP（s）GET或POST请求通常只有几百字节，对于一些大的cookie而言可能是1-2千字节。

攻击者知道
，许多WAF解决方案在寻找攻击流量时，只会扫描一小部分有限的字节 。如果WAF没有找到匹配项，或者根据NetScaler的测试，如果请求大于8kb，许多WAF将不会扫描请求，它们会认为这是异常，仅仅转发而已。

需要着重强调的是：许多WAF只是简单地转发请求，不阻塞 ，也不记录。

WAF“黑客活动”解释

为了绕过WAF，攻击者利用SQL注入或跨站脚本，用垃圾内容填充请求，使其超过8kb的大小，然后点击发送 ，填充请求就像在登录表单中添加一个巨大的请求头或cookie或其他POST正文文本一样简单。请求不被扫描
，而是被传递到执行负载的后端服务器。

一些WAF经配置后可以应对填充攻击 ，但默认情况下这种保护并没有开启
。至于为什么会这样
，我只能得出这样的结论：开启这种保护需要额外的处理
，这也就增加了WAF用户的成本
。供应商不希望其WAF被认为比竞争对手更昂贵，因此任由额外的保护被禁用 。

请注意，如果不更改默认设置 ，你的Web应用程序和API将完全暴露 。

一些解决方案采用的单遍式WAF架构其表现比传统的代理策略好得多，这就是为什么可以在不增加成本的情况下直接防范填充攻击
。

这些WAF漏洞是新漏洞吗？

填充攻击并不新颖 ，WAF供应商很清楚这个问题 ，但整个WAF行业还没有满足默认开启最有效保护的要求 。

一些分析师已经向相关的供应商提出了安全方面的缺口，供应商的回应是“这是一个已知的限制
，如果客户想要这种保护 ，应该运用这条特定规则 。”但是解决方法常常隐藏在WAF配置指南的具体细节中，管理员和部署操作员可能（也确实）忽略了它 。

如今，用户希望系统开启后“完全可用”
，IT部门使用的每个解决方案都能简化任务，并减少管理开销，因此需要从一开始就保护WAF。当然，如果合法的请求需要更庞大 ，那么它将被阻止。这时候可能会出现例外，当管理员这么做时要意识到风险 。但是任由整个站点暴露在外是绝对不允许的 。

攻击者知道许多WAF在默认情况下没有启用保护，这就是为什么他们借助填充攻击利用这个漏洞 。NetScaler测试的几个WAF不容易受到这种攻击方法的影响，但很多WAF都容易受到影响，一些WAF的请求限制稍微大一些（128 kb），但是一旦请求体被填充 ，就同样很容易绕过
。一些解决方案倾向这种“fail open”方法，以避免额外处理带来的额外成本，防止意外的误报，并允许更简化（不过不太安全）的设置 。

然而，“fail open”方法违反了安全供应商理应提供的网络安全“强默认”原则 。在选择WAF时，你需要确保默认情况下已受到保护
，可以防范填充攻击 。

保护WAF的3个简单步骤

你的WAF解决方案可能没有正确配置 ，从而使Web应用程序和API完全暴露在攻击者面前 ，他们可以通过SQL注入和跨站脚本轻松部署填充攻击 。

当你急匆匆地检查WAF配置时，必须要做以下三件事：

用填充请求测试你的Web应用程序（包括内外的Web应用程序） 。检查Web应用程序日志 ，查找意料之外的庞大请求：比如说，查看登录POST表单 ，它通常只包含用户名和密码 ，大小从大约20字节到300字节不等
。如果你看到POST请求的大小大于8kb ，那么这可能是填充攻击尝试 。评估是否可以更改配置以应对填充攻击，如果可以 ，确保比较前后的成本
，以便获得加大保护所需的确切成本
。

如果遵循这篇简单的指南文章，你就可以正确地配置WAF，以提高Web应用程序和API的安全性。