许多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的安全性。
原文链接:https://thenewstack.io/how-attackers-bypass-commonly-used-Web-application-firewalls
邮件:xiongyong@cybersecbase.com