攻击者如何绕过常用的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的安全性。