Azure Front Door WAF WTF: IP限制绕过
Azure Front Door Web应用程序防火墙（WAF）的"IP限制"选项可通过包含HTTP标头来绕过。更糟糕的是？这实际上是预期行为。
图1 - 为什么？？？
背景
Azure中有两种WAF可用——Front Door WAF和Application Gateway WAF。Front Door WAF是Azure的全局WAF，Application Gateway WAF是区域性WAF。
图2 - 在Azure中创建WAF策略
这种特定的IP限制绕过仅在Front Door WAF中有效。在Front Door WAF中，如果选择按IP地址限制访问，默认选择是名为RemoteAddr的变量。
图3 - Front Door WAF策略
如果选择"匹配变量"下拉菜单，我们可以看到选项：RemoteAddr或SocketAddr。
图4 - 谨慎选择
我们有两个名称模糊的变量可供匹配。那么，有什么区别呢？
图5 - 可能出什么问题？
在Front Door WAF文档中，Microsoft明确说明：RemoteAddr变量匹配原始客户端的IP地址，并通过尊重X-Forwarded-For HTTP标头（如果设置）来实现。另一方面，SocketAddr变量是WAF看到的IP地址，即真实IP地址。这是任何理智的人期望进行过滤的地方。
图6 - 叹息
所以，明确一点：Front Door WAF中的IP地址限制的默认选择可以通过简单地添加带有适当IP地址的X-Forwarded-For标头来绕过。此外，没有明确指示两个选项中有一个是糟糕的。
图7 - 我的意思是，IP地址到底是什么？
RemoteAddr变量也作为地理位置匹配规则中的选项存在，但在那里不是默认选择。
图8 - 看起来工作正常
当然，管理员应该仔细阅读所有文档，但有人会猜到其中一个选项完全不安全吗？它完全不可靠，无法保护任何东西。它甚至不应该被标记为IP限制，因为它给人一种增加安全性的错觉。
虽然文档中没有明确说明，但RemoteAddr将检查X-Forwarded-For值以及实际连接IP地址，看是否匹配。这意味着如果管理员使用RemoteAddr配置WAF并进行测试连接，只要实际IP地址匹配，无论是否设置了X-Forwarded-For标头，它都会允许连接。这可能会进一步混淆RemoteAddr和SocketAddr之间的区别，并可能导致危险的"休眠"规则，看起来按预期工作但可以轻松绕过。
在我的测试中，可以在约40分钟内暴力破解/16网络空间，并访问受RemoteAddr IP地址限制保护的站点。我使用Burp Intruder执行了此测试。如果攻击者能够获取用户发送的电子邮件以获取一些原始IP地址范围，或者目标有注册的CIDR，这会更容易。
图9 - 使用Burp Suite暴力破解允许的IP地址
当你假设时会发生什么…
如果你曾经使用过Application Gateway WAF（另一个Azure WAF），事情会变得非常混乱。在Application Gateway WAF中，IP限制的默认（且唯一）变量是RemoteAddr。
图10 - Application Gateway WAF
然而，在Application Gateway WAF中，RemoteAddr变量指的是WAF看到的IP地址（等同于Front Door WAF中的SocketAddr变量）。
没错！Microsoft在相关产品中使用相同的变量名来表示完全不同的事物！
| 服务 | 变量名 | 描述 |
|---|---|---|
| Front Door | RemoteAddr | 由X-Forwarded-For设置的IP地址或WAF看到的IP地址 |
| Front Door | SocketAddr | WAF看到的IP地址 |
| Application Gateway | RemoteAddr | WAF看到的IP地址 |
图11 - 他们为什么要这样做
这是一个功能，不是错误
一个古老的MSRC故事：这是预期行为。好在周转速度相当快。
2025.05.14：提交给MSRC 2025.05.15：MSRC审核中 2025.06.03：MSRC拒绝处理，因为此行为是故意的
图12 - 确认的功能！
测试设置
好吧，让我们演示一下！首先，设置一个简单的站点，我们将使用Front Door WAF保护并用于演示绕过。对于我们的测试，我们将使用一个显示"Hello world, [name]“的站点。
图13 - 测试应用程序
然后，配置Azure Front Door，设置到测试站点的路由。
图14 - Front Door路由
接下来，配置安全策略和WAF策略。
图15 - Front Door安全策略
然后，配置自定义规则以允许来自特定IP地址（本例中为123.45.67.89）的流量，并在RemoteAddr变量上匹配。这是唯一容易受到此绕过的变量；我无法找到在选择SocketAddr时有效的绕过方法。
图16 - 配置自定义规则
RemoteAddr变量可能更常被选择，因为页面上的差异没有明确定义，并且当选择IP地址进行过滤时，RemoteAddr变量是预先选择的。
最后，将WAF设置为预防模式。
图17 - 预防模式下的WAF
验证阻止规则
现在，验证它是否阻止任何正常流量，而不是源自123.45.67.89的流量。
图18 - 浏览器中WAF功能正常
完美。我们的请求按预期被阻止。
我们可以再次使用curl确认阻止：
图19 - 使用curl时WAF功能正常
这里只是curl的头部，显示403响应。
图20 - WAF功能 - HEAD响应
识别Front Door WAF
关于识别Front Door WAF与Application Gateway WAF的快速说明。如果是Front Door WAF，你应该看到x-azure-ref和x-cache标头都存在。
图21 - 指示Front Door WAF的标头
如果目标使用Application Gateway WAF，我没有找到积极的指示器。在这种情况下，你的指示器将是Microsoft IP地址和缺少上述标头。
绕过IP限制
通过简单地添加X-Forwarded-For: [IP地址]，你可以绕过此限制。
图22 - IP限制绕过
就这样。简单。
再次强调，如果规则配置为使用SocketAddr变量，这不起作用，但RemoteAddr变量在创建新IP限制时是预先选择的，并且可能由于对选项的无知而被选择。毕竟，在Application Gateway中，RemoteAddr是完全安全的。
图23 - “IP地址匹配”
额外奖励！
记住，当自定义规则匹配时，不会检查其他WAF规则。广泛的OWASP攻击检测列表完全被跳过。没有二次检查，全有或全无。所以，如果你能够使用此方法访问开发站点或管理员认为受保护的内容，你可能可以毫无顾忌地进行扫描。
图24 - 无法检测你不扫描的内容
检测
我整理了一个简单的PowerShell脚本，你可以从Azure Cloud Shell运行。只需转到"管理文件"并上传脚本：https://github.com/nyxgeek/frontdoor_waf_wtf/。
或者，你可以使用curl获取文件：curl -O https://raw.githubusercontent.com/nyxgeek/frontdoor_waf_wtf/refs/heads/main/azure_frontdoor_waf_wtf.ps1
然后运行脚本：./azure_frontdoor_waf_wtf.ps1
图25 - RemoteAddr检测
此工具将报告是否有任何Front Door WAF规则使用不安全的RemoteAddr变量。
此RemoteAddr WAF检查也已作为模块添加到GraphRunner（https://github.com/dafthack/GraphRunner）中。你需要执行额外步骤来检查此问题，因为GraphRunner令牌默认是Graph令牌。
导入GraphRunner模块后，获取管理端点的令牌，使用：Get-GraphTokens -Resource ‘https://management.azure.com/'
图26 - 获取管理令牌
接下来，运行：Check-FrontDoorWAF -Tokens $tokens
图27 - Check-FrontDoorWAF
注意：运行此模块后，你需要再次运行Get-GraphTokens以获取正常的Graph令牌。
修复
幸运的是，修复很简单：只需更新你的Front Door WAF配置以使用SocketAddr。但是，如果你实际使用RemoteAddr的功能并且需要能够区分代理后面的人，很容易添加第二个"If"条件，要求SocketAddr匹配代理服务器的IP地址。
以下截图显示了一个规则示例，该规则将允许代理后面的特定IP地址（例如，X-Forwarded-For: 123.45.67.89），同时仍然要求实际IP地址是你的代理地址（例如，1.2.3.4）
图28 - 结合RemoteAddr和SocketAddr
结论
从哪里开始？
Front Door WAF中的RemoteAddr选项不应列在IP限制下，因为它实际上只是匹配标头值。如果Microsoft想要包含预构建的X-Forwarded-For匹配选项，他们应该这样标记。Microsoft已经提供了匹配标头值中字符串的选项，那么这个RemoteAddr IP匹配"功能"增加了什么价值？是谁的想法假装HTTP标头匹配是IP或区域限制的选项？
变量名应在产品之间保持一致（RemoteAddr与SocketAddr）。在一个版本产品中安全可靠的内容不应在另一个版本中相反。他们为什么要这样做？也许每个WAF团队完全孤立运作，或者Front Door WAF开发人员从未实际使用过Application Gateway WAF。
RemoteAddr打开的巨大安全漏洞应在创建规则的页面上更清楚地记录。如果你要提供虚假的IP限制，它应该有巨大的闪烁字母说明它不能单独信任。
对用户控制的标头执行WAF过滤是愚蠢的，尤其是称之为IP限制。如果人们选择默认选项而不深入挖掘，他们会错误地认为他们实际上受到保护。如果他们以前使用过Application Gateway WAF，其中RemoteAddr变量实际上是安全的，这一点尤其正确。
图29 - 来吧，它锁定了
这就像卖一扇实际上不锁的前门，但看起来确实锁了。它会看起来工作，直到有人真正试图闯入。如果管理员想要仅根据用户提供的标头进行过滤，让他们构建自己的字符串匹配标头值，但不要将其作为IP限制类型提供，因为它在这方面确实做得很差。
如果你使用Azure Front Door WAF，请确保你在SocketAddr变量上匹配！
特别感谢Aaron James @TrustedSec的反馈。
参考
使用WAF为Azure Front Door配置IP限制规则 https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction