AWVS WAF绕过

最近，各类绕过技术需要变大，在这针对 AWS Web 应用程序防火墙的各种绕过技术做下复现整理。这些绕过不仅暴露了某些关键功能的缺失，而且还暴露了对自定义规则和托管规则常用的默认配置的依赖问题。

虽然 AWS WAF 针对各种 Web 应用程序威胁提供了强大的保护，但使用者必须意识到由于默认配置和功能设计缺陷而可能出现的潜在“规则绕过”。

在这篇文章中，我们将分开其中一些绕过技术，并分析真实绕过原因，提供有关保护应用程序的意见。

长话短说

• AWS WAF 缺乏针对表单 urlencoded 或 XML 内容类型主体的检查功能，仅支持纯文本和 JSON。
• 当 JSON 正文包含重复key时，AWS WAF 会认为其无效，并且默认情况下会继续处理而不阻止请求。
• 可以使用 unicode 转义序列绕过 JSON 正文中特定参数的虚拟修补。

AWS WAF 和 ACL列表

AWS WAF 服务在通过过滤和监控 HTTP 请求和响应来保护 Web 应用程序。它充当“第一道防线”，有效阻止常见的 Web 漏洞，例如 SQL 注入、跨站点脚本 (XSS) 攻击和分布式拒绝服务 (DDoS) 攻击。通过与其他 AWS 服务无缝集成，WAF 允许客户强化其应用程序以抵御已知漏洞和新出现的威胁。

AWS WAF 服务的一个常见用例是与负载均衡器 (ELB) 或 Amazon CloudFront（AWS 提供的一种内容分发网络）结合使用。通过将 AWS WAF 与 ELB 或 CloudFront 集成，客户可以实施安全策略并防止恶意请求到达其应用程序实例。此设置可确保潜在有害流量在到达后端服务器之前被拦截并消除。

基本上，用户可以将ACL分配给 ELB 或 CloudFront，其中可能包含托管或自定义规则。

托管规则？AWS WAF 提供了一组预配置的托管规则，用于防范常见的 Web 应用程序威胁和漏洞。这些托管规则由 AWS 安全专家创建和维护，他们不断更新这些规则以应对新出现的威胁。用户可以选择并启用这些托管规则，为其 Web 应用程序添加额外的保护层，而无需手动创建规则。

自定义规则？除了托管规则之外，AWS WAF 还允许用户根据自己的特定应用程序需求创建自己的自定义规则。用户可以定义自己的规则条件，例如匹配 HTTP 请求或响应中的特定模式，并设置要采取的相应操作当规则被触发时。

功能设计缺陷

AWS WAF 使您能够仅以 两种不同的方式检查 HTTP 请求正文：纯文本或 JSON。正如您可以想象的那样，这意味着您必须将 www-form-urlencoded 请求正文作为纯文本进行检查，而不是像其他 WAF 上那样检查 key=value 序列的解析版本（例如 ModSecurity 所做的）。

在我看来，这些限制使得创建精确的规则来准确识别请求体内的恶意模式或行为变得很有难度。需要仔细设计和微调规则，在安全性和最大限度地减少误报之间取得平衡至关重要。定期监控、日志分析和规则迭代完善对于优化 AWS WAF 的有效性和降低误报风险至关重要。

JSON 重复键

在 JSON 领域，重复键的处理一直是讨论和不同解释的话题。ECMA-404 “JSON 数据交换语法”等官方标准对此事保持沉默，留下了歧义的空间。然而，RFC 8259 “JavaScript 对象表示法 (JSON) 数据交换格式”对建议的行为提供了一些启示。

根据 RFC 8259，JSON 对象中的名称（键）理想情况下应该是唯一的。规范中“应该”的使用意味着虽然可能有合理的理由偏离此建议，但在选择替代方法之前必须仔细考虑其含义。

坚持在 JSON 对象中使用唯一名称的主要理由在于实现互操作性。通过唯一的名称，不同的软件实现将就对象内的名称-值映射达成一致。然而，当存在重复名称时，接收此类对象的软件的行为变得不可预测。

不同的实现以不同的方式处理重复项。某些实现仅报告最后遇到的名称-值对，而其他实现可能会报告错误或无法完全解析对象。另一方面，某些实现可能会报告所有名称-值对，包括重复项。

为了添加到混合中，ECMA-262 “ECMAScript®语言规范” 指定应覆盖对象内相同键的词法前面的值，这意味着“最后一个值获胜”方法。

作为一个实际示例，尝试使用 Douglas Crockford（JSON 的创建者）的 Java 实现来解析具有重复名称的 JSON 字符串将导致由于违反唯一性要求而引发异常。

AWS WAF对JSON 重复键的处理方式

可以利用 AWS WAF 在请求正文中遇到无效 JSON 时的默认行为来绕过其保护。当 AWS WAF 检测到无效的 JSON 时，它会提供多个选项来处理请求。默认选项为 "None"，这意味着无论 JSON 无效，AWS WAF 都不会采取任何操作并继续处理请求。

另一个选项是选择“以纯文本形式评估”。在这种情况下，AWS WAF 将在遇到无效 JSON 之前评估其已解析的令牌。

通过利用默认行为，攻击者可以故意触发无效的 JSON 条件并确保 AWS WAF 不会阻止或发出任何警报。这使得他们能够潜在地利用漏洞或将恶意内容注入系统而不被发现。

让我们看看不同的网络语言如何处理这种情况。

PHP

在 PHP 中，如果 JSON 文档包含重复的键，则json_decode()用于解析 JSON 的函数将通过用较晚出现的键覆盖较早出现的键来处理该问题。例如，在 JSON 文档中{"a":1,"a":2}，生成的 PHP 数组将为['a' => 2]. 键“a”第二次出现会覆盖初始值 1，导致最终值 2。

Python

在Python的JSON模块中，当使用该json.loads()函数解析包含重复键的JSON数据时，其行为类似于“其他JSON解析器”。它只保留最后一次出现的键值对。

例如，json.loads('{"a":1,"a":2}')确实会生成字典{'a': 2}。键“a”第二次出现会覆盖初始值 1，导致最终值 2。

说到 Flask，当 Flask 遇到包含重复键名的 JSON 数据的请求时，它遵循标准 JSON 解析规则，只保留最后一次出现的键值对。Flask 的request.json对象将反映这种行为，并通过仅保留最后一个出现的键来提供对具有重复键的 JSON 数据的访问。

例如，如果传入的 JSON 请求正文是{"a": 1, "a": 2}，Flask 将解析它，并且生成的request.json对象将包含{"a": 2}. 键“a”的第二次出现将覆盖初始值 1，符合 JSON 规范。

需要注意的是，Flask 不提供任何内置选项或标志来修改处理 JSON 中重复键的默认行为。如果您需要对重复键进行不同的处理，则需要实现自定义解析逻辑（不要这样做）或使用外部库来操作 Flask 应用程序中的 JSON 数据。

JavaScript

在 JavaScript 中，该JSON.parse()函数用于解析 JSON 数据。当遇到重复的键时，JSON 解析器将仅保留最后一次出现的键值对。例如，{"a":1,"a":2}将导致键“a”的对象的值为 2。

为什么这是一个问题？

在许多情况下，AWS WAF 规则是使用无效 JSON 处理程序的默认行为创建的。通过利用默认设置，攻击者可以通过发送相同的 JSON 参数密钥名称两次来绕过规则，每次都包含不同的值，一个是无害的，另一个包含攻击负载。

让我们尝试创建一个规则来检查字符串“etc/passwd”是否位于 JSON 请求正文的任何值内。

因此，基本上我们在这里说“如果 JSON 请求正文的任何值包含字符串 etc/passwd，则使用 403 状态代码阻止该请求”。

现在，发送带有 JSON 主体的请求，其中包含针对 etc/passwd 文件的 RCE 或 LFI，将产生一个块：

请求被 AWS WAF 阻止

因为我们在无效 JSON 主体处理程序上选择了默认行为，我们只需发送两个“cmd”键即可绕过此块：

规则绕过

JSON Body上的虚拟修补

Web waf的主要且广泛认可的应用之一是虚拟修补。虚拟补丁是一种有效的策略，可以在不更改底层代码库的情况下解决 Web 应用程序中的漏洞。

让我们考虑一个示例，其中 Web 应用程序接受名为“id”的 JSON 参数，该参数容易受到 SQL 注入攻击。攻击者可以通过将恶意 SQL 代码注入“id”参数来利用此漏洞，从而可能获得对应用程序数据库的未经授权的访问。

为了使用虚拟补丁解决此漏洞，WAF 可以配置专门设计的规则，将“id”值限制为仅数字值。该规则充当临时补丁，确保作为“id”参数提交的任何非数字输入在到达应用程序后端之前被阻止或清理。

使用 AWS WAF 来实现这一点有点棘手。您需要有 2 个语句：第一个语句检查“id”参数长度是否大于 0，第二个语句检查“id”参数的值是否仅包含 0 到 9 之间的字符。

在第一个语句中，我们说：“如果请求 JSON 包含键“id”并且该键值的大小大于 0，则执行某些操作...”。此外，正如您在上面的屏幕截图中看到的，我们必须指定要使用 JSON 指针进行检查的 JSON 键。例如：给定此 JSON{"foo": {"bar":{"id":1}}}仅检查“id”值，我们应该配置以下 JSON Pointer /foo/bar/id。

现在，第二个声明：

在此语句中，我们说：“如果 JSON 参数 'id' 值不只包含数字字符，则使用 403 状态代码阻止请求”。

这条规则很有效，如下：

如果我尝试在值中注入 SQL 语法：

请求被 AWS WAF 阻止

AWS WAF 在其当前实现中，在匹配规则的给定 JSON 指针时，不会解码 JSON 键内的转义序列。可以利用此行为绕过专门针对参数值（例如“id”参数）的规则。通过用 Unicode 转义序列替换密钥的任何字符，攻击者可以有效地规避规则，并可能在未被检测到的情况下传递恶意内容。

因此，在我们的示例中，我可以通过用 unicode 转义序列替换“id”JSON 键的“i”字符来轻松绕过我的规则u0069：

规则绕过

其他 WAF 如何处理这个问题？

ModSecurity 是一个功能强大的开源 Web 应用程序防火墙 (WAF) 模块，可为 Web 应用程序提供高级安全功能和保护。ModSecurity 提供广泛的安全功能，包括基于规则的过滤、HTTP 流量监控、实时日志记录和威胁情报集成。

在这种情况下，ModSecurity 能够在匹配任何规则之前解码 JSON 键中的 Unicode 转义序列。让我们做一个示例规则并检查它是否按预期工作。

ModSecurity WAF 规则

在上面的规则中，我们配置 ModSecurity 以检查参数“id”的值中是否仅包含数字字符。如果是这样，则使用 403 响应状态代码阻止请求。

带注释的 ModSecurity 规则

请求被 ModSecurity 规则阻止

即使我尝试用 unicode 转义序列替换某些字符（如之前所做的那样），ModSecurity 也会阻止我的请求：

无法绕过 ModSecurity 规则

在此请求之后，ModSecurity 会写入一条日志，显示“id”参数在执行我的规则之前已被解码：

ModSecurity: Access denied with code 403 (phase 2). Match of "rx ^[0-9]+$" against "ARGS:id" required.

结论

AWS WAF 是一项有价值的服务，可提供针对一系列 Web 应用程序攻击的保护。然而，了解其局限性和潜在的旁路 技术非常重要。虽然 AWS WAF 为 Web 应用程序保护提供了便捷且可扩展的解决方案，但考虑到本文中讨论的特定绕过方式，利用 ModSecurity 可以提供额外的防御层。

根据我的经验，在虚拟补丁方面，ModSecurity 比 AWS WAF 具有明显的优势。借助 ModSecurity，虚拟补丁功能更加灵活和强大，可以全面防护 Web 应用程序中的漏洞。ModSecurity 广泛的规则集和可定制的规则引擎使安全从业者能够创建有针对性的虚拟补丁来解决特定的应用程序漏洞。

更多：CRS 或非 CRS

在 AWS WAF 中，有一个称为核心规则集 (CRS) 的托管规则组，由于其与著名的 OWASP 核心规则集 (CRS) 项目相似，可能会引起一些混乱。但需要注意的是，AWS WAF 核心规则集在规则范围和数量方面与 OWASP CRS 不同。

AWS WAF“核心规则集”由 22 条规则组成，专门用于解决常见的安全威胁和漏洞。虽然此规则集提供了基本级别的保护，但与广泛的 OWASP CRS 相比，其规模要小得多，后者由分为 10 多个攻击类别的 500 多个规则组成。

原文始发于微信公众号（军机故阁）：AWVS WAF绕过