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