目录导航
这是一个教程，详细介绍了绕过基于签名的 WAF 或 IDS 软件的各种非常规方法。与其关注签名逃避和绕过列入黑名单的字符或关键字，不如关注可以让攻击者完全阻止 WAF 中的检查被应用的技术。使用这些技术意味着攻击者不再需要专注于制作payloads，从而绕过任何基于签名的检查，而是可以完全避开整个绕过过程，从而使 WAF 无效。
尽管了解用于制作绕过 WAF 实现的有效载荷的方法当然很有用，但有一些简单的方法可用于完全跳过此过程。我将概述这些技术中的每一种，并解释如何单独或组合使用它们来跳过过滤器规避过程。
通过直接 IP 访问发起连接：
这是绕过基于云WAF 解决方案的众所周知且有据可查的方法，但无论如何我都会介绍它（以及它的一些变体）——基于云的 WAF 解决方案与网站的 DNS 相关联，这意味着如果攻击者通过其直接 IP 地址加载 URL，则必须找到绕过其签名检查的有效负载的整个过程将被跳过。您只需访问包含您的有效负载的易受攻击的 URL，但使用服务器的直接 IP 地址代替 DNS。
例如，假设有一个影响 host.com 的 RCE 漏洞：
http://host.com/vuln/whois.php?url=http://google.com/%26cat${IFS}/etc/passwd
通过获取网站的直接 IP，您可以简单地导航到相同的 URL，但这次将主机名替换为直接 IP 地址。如果网站使用带有自己自定义名称服务器的 CDN，那么您需要找到一种方法来泄漏正在使用的直接 IP。以 Cloudflare 为例——当然，你可以采用传统的签名规避方法来尝试为他们的 WAF 寻找绕过……或者，你可以花更少的时间来寻找一种从 cloudflare 后面获取后端 IP 地址的方法，然后再一次，这只是将 DNS 切换到直接 IP 的情况，导致 cloudflare 的保护被规避，如下所示：
http://93.184.216.34/vuln/whois.php?url=http://google.com/%26cat${IFS}/etc/passwd
提示：无需在每次发出请求时输入 IP 地址代替 URL，您只需编辑 主机 文件（ Linux 上的/etc/hosts）即可加快流程。
如果您可以通过简单的 Ping 请求或类似方法找到后端 IP 地址，那么您很幸运。通常，需要更复杂的技术才能找到真实IP。这是因为 CDN 和 DDoS 保护解决方案也提供 WAF 保护（CloudFlare 是一个主要示例）将显示其 服务器的 IP 地址 作为 ping 响应，而不是显示网站的真实 IP 地址。值得注意的是，如果我们专门讨论 CloudFlare，网站已经存在（例如 CrimeFlare) 允许人们根据与此类网站关联的后端 IP 地址列表查询 DNS，如果幸运的话，正确的 IP 将已存储在这些数据库之一中，并可通过这些免费服务查看。下面我将解释几种不同的方法，这些方法可用于使用此类基于云的保护来泄漏网站的正确后端 IP 地址。
一些基本的侦察可能是揭示网站后端 IP 的最佳方式。历史记录可以揭示后端 IP，因此请尝试将 URL 输入到Netcraft等服务 。 错误配置在此类服务中也很常见，因此始终值得检查。当然，他们的主要 DNS 是通过 CloudFlare 路由的，您无法获得后端 IP，但是子域呢？有可能这些子域中的一些指向与主网站相同的服务器，并且可能有人忘记通过 CloudFlare 的名称服务器路由它们。应该对 FTP 服务器、MX 服务器等进行类似的检查。还值得检查 Shodan 和 Censys 之类的东西，看看是否有任何记录暴露了域的原始服务器。
如果所有的侦察技术都用完了，后端IP地址还没有暴露出来，那么你需要想办法让目标服务器主动连接到你自己服务器上的一个页面，导致IP地址结束在您的 access_log 中 – 有几种不同的可行方法可以做到这一点。mod_rewrite 可以与 .htaccess 一起使用，并且可以应用我在“利用 htaccess 进行开发” 博客文章中描述的一些技巧 来操纵服务器以揭示其真实 IP。
理想情况下，您希望找到某种方法让服务器启动与您的直接连接。这可能是通过 SSRF 漏洞实现的（你知道，就像那些“没有影响”的 SSRF 只允许您发出请求而几乎没有其他任何内容），或者它可能是站点的预期功能，将导致直接连接被制造。例如，如果该站点是一个论坛，并且用户的个人资料具有可自定义的头像图像，该图像可以更改为通过远程 URL 提交的新图像，那么您可以在属于您的服务器上托管图像，请求来自目标网站的图像，并 grep 您的 access_log 以获取 IP。另一种类似的技术是网站是否有电子邮件通讯或类似的东西。你可以订阅它，
切换协议：
除了更改 IP 地址之外，默认情况下通过 http 加载页面（反之亦然）时通过 https 加载页面等技术听起来很荒谬，但这会阻止某些 WAF。尝试通过不同的可用端口访问事物，并在 URL 中指定端口，例如：
https://example.com:443/vuln.php?payload=../../../etc/passwd
您还可以在 URL 中添加或删除“www”，这可以实现相同的结果（这种特殊方法使我能够在eBay的主域上获得有效的 XSS ）——或者如果目标具有用于服务器负载的镜像设置平衡（例如，当您看到“www2”、“www3”等时），然后加载其中一个镜像（例如，将“www”更改为“www2”），因为有时 WAF 不会应用于这些镜像。
另一种绕过 WAF 的半相关且经常被忽视的方法是通过 IPv6 而不是 IPv4 发送您的请求 – 有许多入侵检测系统也只监控 IPv4 流量，而任何 IPv6 流量都可以未被检测到。
HTTP 标头的操作：
在某些情况下，可以操纵某些 HTTP 标头以诱使 WAF 相信它正在与以下任一者对话：
- 本身
- 列入白名单的主机
- 本地网络上的一台机器
用户可以将特定标头的值设置为 localhost (127.0.0.1)、本地地址（例如 192.168.1.2）或目标站点的远程 IP 地址。可以通过这种方式操作以下标头：
X-forwarded-for
X-remote-IP
X-originating-IP
x-remote-addr
x-client-ip例如，如果使用以下标头值发送 HTTP 请求：
X-Originating-IP: 127.0.0.1然后，在某些情况下，WAF 会被欺骗，认为它是在与自己通信，因此会将 HTTP 请求视为已列入白名单。我第一次看到 Jason Haddix 记录的这种方法，尽管我不确定他是否负责找到它。
对每个发送请求的内容类型标头进行操作也可能导致绕过。这可以通过多种方式实现。这个值可以从请求中剥离，通过修改字符的方式进行畸形，或者欺骗到另一种内容类型，例如，采用以下内容类型：
Content-Type: text/html以下是一些如何修改它的示例
Content-Type: (删除内容类型值)
Content-Type: text/htmlzzzzzzzzz (输入错误的内容类型值)
Content-Type: application/octet-stream (修改内容类型值)在某些情况下， 为每个 HTTP 请求发送不同的 有效内容类型可能会导致绕过，如下所示：
Content-Type: application/octet-stream (请求#1)
Content-Type: text/html (请求#2)
Content-Type: text/xml (请求#3)我不确定为什么这个可以正常工作，但是在每个 HTTP 请求绕过防火墙发送不同的内容类型过去让我对 WAF 感到困惑，并获得了我正在寻找的确切最终目标。
将 MIME 类型设置为 multipart/form 数据然后对请求进行错误处理导致过去许多商业 WAF 被绕过，包括 mod_security，这可以这样做（这些示例来自 Ivan Ristic 的 Blackhat USA talk）：
Content-Type: multipart/form-data ; boundary=0000
Content-Type: mUltiPart/ForM-dATa; boundary=0000
Content-Type: multipart/form-datax; boundary=0000
Content-Type: multipart/form-data, boundary=0000
Content-Type: multipart/form-data boundary=0000
Content-Type: multipart/whatever; boundary=0000
Content-Type: multipart/; boundary=0000在某些情况下，还可以操纵 HTTP 主机头以试图绕过 WAF 软件。有时，简单地向主机值添加一个点可能会导致绕过。删除或修改主机头可能会导致绕过——有时 WAF 会根据主机名选择要实施的安全策略。如果无法识别主机名（由于用户的操作），则在某些情况下根本不会应用 WAF。由于主机标头中的差异，一些 WAF 在被欺骗认为请求不是针对该站点后将停止监视请求（出于性能原因），但随后可以使用正确的主机名提交进一步的请求，而不会受到任何监视。
参数名称的操作：
参数名称可以通过多种方式进行操作，具体取决于易受攻击的服务器上运行的服务器端语言。在这篇文章中，我将给出 PHP 和 ASP 的示例，然后解释为什么在 URL 中操作参数名称会导致有效绕过。
这对于绕过虚拟补丁特别有用，例如类似于通常可以将硬编码路径应用于 mod_security 作为“补丁”的一部分 – 操纵此硬编码值的能力可能会导致绕过。 PHP 中的 +符号可用于实现此目的，而 ASP 中的 % 符号将实现类似的结果。
在 ASP 中，可以将无效的 URL 编码添加到参数名称中，它会为您“清理”并删除任何无效的编码。请注意，编码必须无效才能正常工作：
/path/vuln.php?%value=payload
/path/vuln.php?%}9value=payload在 PHP 中，加号可以达到同样的效果：
/path/vuln.php?+value=payload在这里，PHP 将在类似于 ASP 的意义上进行清理。此处的目的是创建仍然有效的路径和参数名称，同时不匹配虚拟补丁中硬编码的路径。这些技术可以与本博客中进一步列出的路径操作部分结合使用。
CR/LF,空终止符和其他控制字符：
某些控制字符可能会导致 WAF 以意想不到的方式运行，在某些情况下，仅仅一个空字节 (%00) 就足以阻止它们完全工作——尽管应该注意，任何值得一提的 WAF 不仅不会受到注入的影响nullbyte 或 null 终止符，但也会有适当的签名来导致输入此类字符以产生 WAF 响应。话虽如此，一些控制字符通常可以产生丰硕的成果。
要查看服务器如何处理空字节，请尝试在服务器上存在的文件的扩展名之前添加一个，例如，更改：
到：
除了空字节之外，CR/LF 和其他类似控制字符的百分比编码等价物可能会触发有关某些 WAF 软件的意外结果。只需将它们附加到您的有效负载的末尾，我已经看到它使用以下字符：
%0d (CR)
%0a (LF)
%0d%0a (CRLF)
%09
%0B请注意，本节中的方法不仅无法与任何值得一提的现代 WAF 一起使用，而且任何现代 WAF 也可能会阻止它们。话虽如此，我遇到了很多自定义 WAF，这些方法确实有效，不仅不会通过它们的签名被捕获，而且还会导致 WAF 阻止应用额外的签名检查。
HTTP 参数污染: #
我假设阅读本文的人已经了解 HTTP 参数污染，但对于那些还没有了解的人，我将提供一个简短的解释。
HTTP 参数污染是用于描述由于在应用程序中多次提供相同的 HTTP 参数而可能导致的意外行为的名称。这可以指许多安全漏洞，从修改内部变量值的能力到全面的身份验证绕过。HTTP 参数污染的严重程度完全取决于应用程序的独特性以及因 HTTP 参数污染而产生的动作。
有几种主要方法可以使用 HTTP 参数污染来规避 WAF。第一种方法，只是简单地包含两次有效负载（每个参数中一次），如下所示：
http://example.com/vuln.php?page=cat /etc/passswd&page=cat /etc/passwd
一种变体是将参数包含两次，但只包含其中一个参数中的有效负载，而没有分配给另一个参数：
http://example.com/vuln.php?page=cat /etc/passswd&page=
这里的原因是它试图验证空的“页面”参数，同时允许其他同名参数在不被检测的情况下溜过。
一种涉及 HTTP 参数污染的有效绕过技术是将您的有效负载分成多个部分（如果允许），这是一个示例：
http://example.com/vuln.php?page=cat &page=/etc/passwd
http://example.com/vuln.php?page=cat &page=/etc&page=/passwd
HTTP 动词篡改：
请记住，您的请求不一定需要使用有效的 HTTP 动词发送。格式错误的动词可以正常工作，例如，请求可以通过“GETS”或“LOLOL”而不是“GET”发送，并且在许多情况下仍会按预期运行。人们期望使用格式错误的 HTTP 动词会导致错误，但在许多情况下不会发生这种情况。
使用不常见的 HTTP 动词也是一种可能，尤其是在 WAF 或 IDS 仅监视 POST 或 GET 请求的情况下。例如，如果您的恶意 GET 请求触发了 WAF 响应，则尝试尽可能通过 HEAD 或 PUT 发送相同的请求。例如，如果您尝试通过在地址栏中加载易受攻击的站点，并将负载存储在基于 URL 的 GET 参数中来发起 GET 请求，请尝试以下类似的方法：
PUT /path/vuln.php?value=PAYLOAD HTTP/1.1
host: www.example.com如果 WAF 应用于您的 GET 请求，请尝试通过 POST 发送它，反之亦然。例如，如果您有触发 WAF 的易受攻击的 URL 参数 (GET)，也尝试发送 POST 请求（连同指向易受攻击的脚本的 URL，但 URL 中不包含 GET 参数）
特别是在 PHP 中，根据配置，cookie 值可以被视为参数。例如，如果您有以下漏洞：
http://example.com/vuln/vuln.php?cmd1=;cat /etc/passwd
假设 WAF 将您作为 URL 的一部分提供的 GET 请求列入黑名单。您可以通过 cookie 值调用参数，方法是设置 cookie，如下所示：
GET /vuln/vuln.php
Cookie: cmd1=;cat /etc/passwdHTTP 请求走私：
HTTP 请求走私，正如恰当命名的术语所暗示的那样，是一种走私 HTTP 请求的方法，可以避免检测。
此攻击向量是通过攻击者修改 HTTP 请求在其到达目的地的路由上实现的。此类漏洞的存在是由于对变形的入站 HTTP 请求处理不当的直接结果。我不会在这里详细介绍（尽管您会在我们即将发布的 wiki 上找到详细的解释）——这需要自己的博客文章来详细解释它以及可能的结果（网络缓存中毒、XSS、会话固定， 和更多）。在这里提到它的原因是因为它允许攻击者在另一台设备不知道的情况下将请求“走私”到一个设备。这意味着如果设计得当，攻击者可以将请求“走私”到目标服务器，同时潜入未检测到的 WAF 或 IDS。我绝对建议研究这种技术及其在 WAF/IDS 规避方面的应用。尽管我没有详细说明（因为这需要自己的博客文章），一个简单的谷歌搜索以及对 HTTP 作为协议如何工作的原始理解应该会向你解释为什么这对于绕过 WAF 或 IDS 软件如此有用。对于本指南的读者，您的家庭作业是阅读 HRS（HTTP 请求走私）并尝试发起现实世界的攻击，让您绕过防火墙（当然是合法的！）
击败虚拟补丁：
一些写得不好的虚拟补丁将依赖路径数据来使用他们的补丁。路径可以以与虚拟补丁指定的路径不匹配的方式进行操作，但仍将被解释为相同的路径。
例如，对 Apache 采取以下 mod_security 规则。这是已应用的通用虚拟补丁：
SecRule REQUEST_FILENAME “@streq /path/vuln.php” \
“chain,phase:2,deny”
SecRule ARGS:user “!^[a-zA-Z0–9]+$”有多种方法可以以仍然加载预期路径的方式访问此路径，同时绕过 mod_security 中的虚拟补丁，例如：
/path//vuln.php (附加斜线)
/////////////////path/////////////////vuln.php?value=PAYLOAD (更多的斜线 -针对PHP)
/path/./vuln.php?value=PAYLOAD
/path/blah/../vuln.php?value=PAYLOAD (回溯目录+添加任意不存在的目录)
/path/blah/blah/blah/../../../vuln.php?value=PAYLOAD (与之前相同，但多次遍历)
/PaTh/VULN.PHP?VaLuE=PAYLOAD (区分大小写的变化)有一些特定于语言的怪癖可用于规避虚拟修补。例如，尾部斜杠在 PHP 中很好，但在其他语言中就不一定了。下面的示例专门用于 Apache Tomcat：
/path;/vuln.php?value=PAYLOAD (添加分号)
/path/;lol=lol/vuln.php?value=PAYLOAD (添加任意参数“;lol=lol”并应用于分号)PATH_INFO（通过 Apache 设置的环境变量）也可以按以下方式操作：
/vuln/vuln.php/lolol?value=PAYLOAD (向路径添加任意值)
/path/vuln.php;lol=lol?value=PAYLOAD (向路径添加任意参数)只是提醒一下，这些技术可以与本指南中前面描述的参数名称操作方法结合使用：
/path/blah/../vuln.php?+value=PAYLOAD这可以允许额外的混淆层来击败虚拟补丁。我不会在这里深入讨论虚拟补丁，但如有必要，请随意谷歌主题或 DM 任何其他问题。您真正需要知道的是，它们有时以具有硬编码路径的方式实现，可以使用上述许多方法绕过该路径。
会话拼接：
会话的拼接或分段涉及将您的有效负载拆分为更易于管理的块。
本文中已经列出的一些技术试图实现与会话拼接或会话分片类似的最终目标。这方面的一些例子是，正如已经提到的，HTTP 参数污染（其中有效载荷被分成块，每个块通过相同的 GET 参数“注入”），或 HTTP 请求走私。
一种用于执行会话拼接的著名工具称为 Whisker ，它将帮助攻击者自动执行此类过程。实际上，这样做是将有效载荷拆分为多个较小的数据包，使它们能够不被检测到——这意味着为了让 IDS 检测到这一点，它必须重新组装数据包流。额外的规避技术可以通过乱序发送数据包并在每个传输的数据包之间延迟来实现。这种技术背后有很多技术信息，要全面详细地解释它，需要专门写一篇博文。请记住，这是一种潜在的技术，并且有可用的工具来自动化这样的过程。我不会在这里详细介绍，但请查看 Whisker 如果您想了解更多信息，请使用工具。再一次，这接近于签名规避，所以我不会深入讨论这个话题。
拒绝服务和资源耗尽：
WAF 或入侵 防御 系统会阻止恶意请求，而入侵 检测 系统只会提醒管理员或任何恶意请求。这意味着攻击者可以通过拒绝服务或其他类似技术触发 误报 ，以迷惑或操纵系统管理员——例如，如果他们收到每次尝试 DoS 攻击的警报， 同时 收到 RCE 尝试的警报，然后，在利用 RCE 的同时，具有良好时机的攻击者可以通过 DoS 触发一系列警报。如果一切按计划进行，假设所有警报都是由于 DoS 尝试而生成的，管理员将无法注意到由于人为错误而导致的 RCE 尝试。
在 IDS/IPS 或 WAF 中触发资源耗尽或缓冲区溢出等也是一种可行且有些有效的技术。
可以实现资源耗尽的一种方法是，攻击者是否利用基于签名的 WAF/IDS 软件使用模式匹配算法来检查签名这一事实。一些签名需要比其他签名更多的计算能力来获得匹配，因此，考虑到这一点，攻击者可以发送一堆包含攻击签名的特制数据包，这些数据包将消耗最多的 CPU 能力。这里的最终目标是在 CPU 上造成高负载，填满缓冲区并由于缓冲区已满而导致 IDS 忽略发送的任何新数据包。
攻击者还可以强制 IDS 消耗其所有 RAM，在这种情况下，它会恢复到 HDD 上的虚拟内存（比 RAM 慢得多），这可能导致 IDS 丢弃（读取：忽略）潜在的恶意数据包。这通过如上所述的算法复杂性攻击实现了与资源耗尽类似的最终结果。内存耗尽可以通过将大量数据包分割成更大量的小数据包来实现，或者通过同时启动大量 TCP 连接（最好结合无序 TCP 段来执行此操作）。
尝试资源耗尽的目的是使 IDS 忽略任何传入的恶意数据包，因为它的缓冲区已满或由于 IDS 从 RAM 恢复到虚拟内存而产生的性能问题。
这就是现在的全部，尽管我最终会跟进第 2 部分。同时，我将专注于使用更传统的方法（例如过滤规避/签名规避）击败 WAF/IDS 软件的指南.