利用超大请求绕过WAF防护
作者:Alan Buxbaum(特邀作者)|| 合作者 Jeff Barbi
Alan Buxbaum是驻日本的渗透测试员。他对区块链技术和加密货币的兴趣引领他进入信息安全领域,自2025年起专业从事相关工作。业余时间,他是热爱的阿斯汤加瑜伽练习者和音乐家。
内容提要
许多Web应用防火墙(WAF)只需在请求体中携带大量额外数据即可被绕过。大多数WAF仅处理特定大小限制内的请求。WAF如何处理这些超大请求的配置决定了可利用性,但某些常见WAF默认允许此行为。
WAF简介
在渗透测试过程中,当应用本身存在漏洞但有效载荷被WAF阻止时,会令人感到沮丧。这种情况并不少见,特别是在可获取服务器端代码的白盒或灰盒测试中。
在这种情况下,WAF通常可以通过有效载荷混淆或其他规避技术来绕过,这表明规则集或其应用方式存在差距。我们的研究探索了一种我们称之为“超大请求绕过”的规避技术。
WAF限制与您
由于检查大请求需要更多处理时间和资源,许多WAF对其处理的最大请求大小设置了限制(通常可配置)。WAF对此大小限制以上的请求的处理方式是一个重要的考虑因素——不仅关乎安全,还关乎应用功能。
某些应用在正常使用期间会生成非常大的用户请求。对于这些应用,WAF不会通过阻止大但合法的请求而导致拒绝服务问题,这一点很重要。我们的研究调查了不同WAF如何处理此问题,并展示了在渗透测试中如何利用这些配置。
简单示例
考虑一个前端部署了基于OWASP规则集的WAF的Web应用example.com。该应用的主页用户名参数中存在SQL注入漏洞。
攻击者发送带有恶意有效载荷的请求。WAF检查请求并返回403禁止访问拒绝:
|
|
然而,攻击者了解到此特定WAF的请求大小限制为8172字节。他们在有效载荷前添加一个额外的POST主体参数foo,包含8172个字符,刚好超过WAF的大小限制。结果,主体内容被忽略,有效载荷被传递给应用:
|
|
我们的目标
我们的研究目标是测试和记录常见WAF在面对上述情况时的默认行为。为此,我们创建了一个简单的Flask应用,在其登录表单的用户名和密码参数中存在SQL注入漏洞。然后,我们通过将应用程序置于每个WAF之后,测试它们对超大请求绕过攻击的防护效果。
开始之前…
由于WAF开发人员无法知道其产品将来要保护的应用程序的性质,因此WAF被设计得非常灵活。因此,上述“不安全”设置通常源于在安全性与功能性之间取得平衡的不可能任务。
我们想明确说明,本文的目的是阐明这些权衡,而不是指责WAF设计者和/或他们的设计选择。
Cloudflare
产品链接:Cloudflare WAF
文档:Cloudflare WAF文档
默认可绕过?
是。对于免费账户,在有效载荷前添加8216或更多字节的请求将绕过WAF。这些大小可能因使用的账户而异(详见下文)。
详细信息
Cloudflare在其文档中直接讨论了超大请求处理。企业级客户的最大主体大小限制为128 KB,这明显大于免费套餐的约8 KB。
加固提示
为了自定义Cloudflare的WAF如何处理超大请求,企业客户可以配置请求主体字段,如http.request.body.truncated和http.request.headers.truncated。对于免费套餐客户,任何超过8 KB大小限制的POST主体都将被发送。
Barracuda
产品链接:Barracuda WAF(通过AWS Marketplace试用测试)
文档:Barracuda WAF文档
默认可绕过?
否。
详细信息
Barracuda的WAF默认不对POST主体请求实施大小限制。因此,攻击者没有大小差异可插入有效载荷。但是,可以实施大小限制。
加固提示
确保开启Active模式。
ModSecurity
产品链接:ModSecurity Github
文档:ModSecurity文档
默认可绕过?
是。ModSecurity以检测模式启动,且SecRequestBodyLimitAction设置为Reject。虽然后一个参数是安全设置,但由于SecRuleEngine设置为DetectionOnly,它不会产生任何效果。
一旦SecRuleEngine更改为On,将SecRequestBodyLimitAction设置为ProcessPartial是不安全的:
|
|
超过x字节后的字符将绕过WAF。
详细信息
如上所述,ModSecurity的配置文件起始设置SecRequestBodyLimit为13107200,SecRequestBodyLimitAction为Reject。这意味着任何主体大小超过13 MB的请求都将被拒绝。
加固提示
将SecRequestBodyLimitAction设置为Reject,这样对于SecRequestBodyLimit x,ModSecurity将阻止任何超过x大小的请求。
AWS
产品链接:AWS WAF
文档:AWS WAF文档
默认可绕过?
是。当与应用程序负载均衡器结合使用时,默认情况下,请求主体大小超过8KB时不安全。大小因服务而异(详见下文)。
详细信息
AWS在此处明确讨论了关于超大有效载荷的风险。具体来说:
主体和JSON主体 – 对于应用程序负载均衡器和AWS AppSync,AWS WAF可以检查请求主体的前8 KB。对于CloudFront、API Gateway、Amazon Cognito、App Runner和Verified Access,默认情况下,AWS WAF可以检查前16 KB,并且您可以在Web ACL配置中将限制增加到64 KB。
AWS还在此处讨论了不同服务的大小限制:
对于CloudFront、API Gateway、Amazon Cognito、App Runner和Verified Access,默认限制为16 KB,您可以按16 KB的增量增加任何资源类型的限制,最高可达64 KB。设置选项为16 KB、32 KB、48 KB和64 KB。
加固提示
在部署期间,将“不匹配任何规则的请求的默认Web ACL操作”设置为“阻止”。
Azure(应用程序网关)
产品链接:Azure WAF
文档:Azure WAF文档;应用程序网关上的Azure WAF
默认可绕过?
否。由于在防护模式下采用“故障关闭”设计,任何配置下都不安全。
详细信息
由于应用程序网关WAF的“故障关闭”设计,任何超过大小限制的请求主体都不会传递给应用程序。尽管如此,您仍然可以通过其配置设置应用程序网关WAF的各种限制大小。
加固提示
不适用
Azure(Front Door)
产品链接:Azure WAF
文档:Azure WAF文档;Front Door上的Azure WAF
默认可绕过?
是。AFD默认请求主体大小限制为128KB。此外,WAF默认为检测模式,必须更改为防护模式才能阻止大小限制下的请求。
详细信息
Azure策略最近改变了要求使用高级许可证才能使用托管规则集的情况。截至2025年,此功能也包含在标准版中。
加固提示
如Azure最佳策略中所述,确保切换到防护模式。
Google Cloud Armor
产品链接:Google Cloud Armor
文档:Google Cloud Armor文档
默认可绕过?
是。Google Cloud Armor的默认设置包括8 KB的字符大小限制。
详细信息
设置比其他一些更复杂。为了使用预配置的规则集,WAF必须设置为高级模式。
加固提示
Google Cloud Armor可以设置为过滤和阻止超过特定大小的请求。这可以在Cloud Armor策略 > [策略名称] > 编辑规则下找到。
Riyaz Waliker的文章讨论了特殊情况下的选项:
…可以沿着Content-Length检查添加进一步的条件,以微调Cloud Armor过滤和阻止请求的时间。例如,可以添加一条规则,允许特定端点的请求大于8 KB。
您可以在此处找到有关各种允许/阻止配置的更多信息。
Sucuri
产品链接:Sucuri WAF
文档:Sucuri WAF文档
默认可绕过?
是。Sucuri的WAF默认为1.25 MB。
详细信息
安全级别必须设置为“高”才能允许POST请求。设置为“偏执”时,不允许POST请求。
Sucuri的字符大小限制的具体信息既不在文档中,也无法从用户的GUI配置。需要注意的是,Sucuri的WAF默认规则没有阻止我们用于测试其他WAF的有效载荷' OR '1'='1';--,因此我们使用了被阻止的' UNION SELECT 1,2,3;--。
加固提示
不适用
Fortinet
产品链接:Fortinet FortiWeb WAF(通过Azure试用测试)
文档:Fortinet FortiWeb文档
默认可绕过?
是。Fortinet的字符大小限制为64 MB。
详细信息
Fortinet的WAF默认“阻止模式”关闭。
加固提示
在“设置”中,启用“阻止模式”:
此外,可以设置各种敏感度级别来控制FortiWeb WAF的行为。
您可以在此处找到有关FortiWeb默认设置的更多详细信息。
结论
超大请求揭示了WAF设计中的一个基本矛盾:平衡性能、可用性和安全性。我们的发现强调了测试WAF的重要性——不仅是为了规则覆盖,也是为了了解它们如何处理规模和资源限制。
安全默认值很重要,但理解它们如何与现实世界的应用程序行为交互也很重要。最终,弥合这些差距的责任在于防御者和他们配置的工具。