1.利用waf性能缺陷
1.1垃圾字符填充
对于通用性较强的软WAF来说，不得不考虑到各种机器和系统的性能，故对于一些超大数据包超长数据可能会跳过不检测
因此可以填充大量垃圾字符来逃避waf对数据包的检测如下
1.2发送大量请求包
可以采取高并发的攻击手段，waf同样出于性能考虑可能会直接放行部分数据包。
2.利用waf适配组件的缺陷
由于后端web容器、中间件、数据库、脚本语言的多样性，waf很难覆盖全，容易导致waf解析不了而后端可以正常解析读取导致的绕过
2.2IIS+asp
在IIS+ASP的环境中，如果url中出现了百分号，但后面邻接的字符拼起来后又不在url编码表之内的话，ASP脚本处理时会将其忽略
例如假设有如下请求xxx.asp?id=1 union se%lect 1,2,3,4 fro%m adm%in
waf规则不严放行后，后端由于该特性成功处理执行了xxx.asp?id=1 union select 1,2,3,4 from admin导致绕过
2.3TOMCAT
tomcat的特性也可以构造出许多绕过的方式，可以参考探寻Tomcat文件上传流量层面绕waf新姿势这篇文章
3.2.1.参数前后添加空白字符绕过
filename="1.jsp"的filename字符左右可以加上一些空白字符%20 %09 %0a %0b %0c %0d %1c %1d %1e %1f，比如%20filename%0a="1.jsp"这样导致waf匹配不到我们上传⽂件
%20：对应空格（空格的 ASCII 码是 32）
%09：水平制表符（Tab 键，ASCII 码 9）
%0a：换行符（LF，ASCII 码 10）
%0b：垂直制表符（ASCII 码 11）
%0c：换页符（ASCII 码 12）
%0d：回车符（CR，ASCII 码 13）
%1c：文件分隔符（FS，ASCII 码 28）
%1d：组分隔符（GS，ASCII 码 29）
%1e：记录分隔符（RS，ASCII 码 30）
%1f：单元分隔符（US，ASCII 码 31）
这些编码在 Web 安全中有时被用于绕过过滤规则（例如 SQL 注入、XSS 攻击中），因为某些系统可能只过滤了可见的空格，而忽略了这些特殊的空白字符编码。例如，在 SQL 注入中，攻击者可能用%0a代替空格来构造注入语句，以绕过简单的输入验证。
2.3.2.utf-16、cp037等各种编码绕过
utf-16
cp037（原始payload为’ and (7=len(db_name())) and ‘a’ = ‘a）
json下的unicode编码
2.3.3.利用waf适配协议的缺陷
3.1畸形请求（与Web应用所处的中间件有关，在部分中间件下不适用）
将HTTP请求头变为随机字符串例如xxxxT
请求方法后加一个table等空字符
使用get请求方法但带上post体（需要服务端能正常接受）
3.2分块传输
利用chunked-coding-converter插件功能一键分块传输编码
仅仅适用于post传输方法
分块传输不少waf现在也都可以识别了，可以结合waf性能缺陷的思路综合利用-延时分块传输
分块传输编码（Chunked Transfer Encoding）是一种HTTP数据传输机制，允许服务器将数据分成多个块发送给客户端，而无需预先知道数据的总大小。这种机制可以通过在HTTP头部添加Transfer-Encoding: chunked来启用。每个数据块包含两部分：块的长度（以十六进制表示）和实际数据，最后以一个长度为0的块表示结束。
这种技术在绕过WAF（Web应用防火墙）时非常有效，因为WAF通常会对完整的HTTP请求进行分析，而分块传输将数据拆分成小块，使得WAF难以识别恶意内容。
绕过WAF的实现步骤
- 构造分块传输请求： 在HTTP请求头中添加Transfer-Encoding: chunked，并将请求体拆分为多个小块。每个块的长度用十六进制表示，块之间用CRLF分隔，最后以一个长度为0的块结束。例如：
4
id=1
5
and
3
1=1
4
--
0
- 使用工具辅助： 借助工具如Burp Suite的Chunked Coding Converter插件，可以快速将原始请求转换为分块传输格式。插件会自动对请求体进行编码，并生成符合分块传输规范的请求。
- 结合SQL注入工具： 使用sqlmap与分块传输插件联动，通过代理发送分块传输的SQL注入请求。例如：
sqlmap.py -r post.txt –proxy=http://127.0.0.1:8080 –batch
--batch：启用批量模式，sqlmap 会使用默认选项自动运行，无需手动输入确认
- 优化注入效率： 使用sqlmap的–threads参数提高并发数，例如：
sqlmap.py -r post.txt –proxy=http://127.0.0.1:8080 –batch –threads 10
注意事项
- 分块长度：每个块的长度不宜过大，否则可能引发服务器错误。根据实际情况调整块大小。
- WAF处理能力：一些高级WAF能够重组分块数据并检测恶意内容，此时需要进一步优化分块策略，例如在块长度后添加注释（如4;test）以增加混淆。
3.3非预期请求方式
get改为post、Content-Type: application/x-www-form-urlencoded改为multipart/form-data等
2.跳过waf直接访问服务器
云waf通过配置NS或者CNAME记录，使得对网站的请求报文优先经过WAF主机，经过WAF主机过滤之后，将被认为无害的请求报文再送给实际的网站服务器进行请求,此时只要找到服务器的真实ip,修改host为服务器真是ip即可绕过云waf
NS（Name Server，域名服务器）和 CNAME（Canonical Name，规范名称）是 DNS（域名系统）中两种重要的记录类型，用于实现域名解析
1. 通过 CNAME 记录配置（最常用）
原理
将网站域名（如www.example.com）的 DNS 解析记录设置为云 WAF 提供的 CNAME 地址（如xxx.wafcloud.com），用户请求会先被解析到 WAF 节点，经 WAF 过滤后再转发到源服务器。
配置步骤
在云 WAF 控制台添加需要保护的域名（如www.example.com），获取 WAF 分配的 CNAME 地址（如防护域名.waf厂商前缀.com）。
登录域名解析平台（如阿里云 DNS、Cloudflare 等），找到该域名的解析记录。
将原 A 记录（指向源服务器 IP）修改为 CNAME 记录，值设置为 WAF 提供的 CNAME 地址。
等待 DNS 生效（通常几分钟到几小时），此时流量会经过 WAF 节点。
2. 通过 NS 记录配置（较少用）
原理
将整个域名（如example.com）的权威 DNS 服务器（NS 记录）修改为云 WAF 提供的 NS 地址，所有子域名的解析请求都会先经过 WAF 的 DNS 服务器，由 WAF 控制流量走向。
配置步骤
在云 WAF 控制台添加主域名（如example.com），获取 WAF 提供的 NS 服务器地址（如ns1.waf厂商.com、ns2.waf厂商.com）。
登录域名注册商平台（如万网、GoDaddy），找到域名的 NS 记录设置。
删除原 NS 记录，替换为 WAF 提供的 NS 地址。
在 WAF 控制台配置各子域名的解析规则（指向源服务器 IP 或其他地址）。
常见寻找真实ip的方式有如下几种
1.证书信息查询 亚数信息-SSL/TLS安全评估报告
2.dns历史解析记录
3.搜集子域名ip c段(考虑到费用问题，一些子域名并不会部署)
4.超级ping
……
3.寻找没有部署waf的nginx反代机器
当waf在nginx服务器上部署，且存在nginx集群时，可以试试尝试寻找能反代服务却又没用部署waf的机器访问进行绕过
以下面这个为例，测试某接口发现被拦截
搜集ip信息为xxx.xxx.200.1xx
查找c段服务，一个个访问尝试
利用成功
4.利用waf白名单
WAF存在某些机制，不处理和拦截白名单中的请求数据
例如特定的ip,来自于搜索引擎爬虫的访问数据等
特定ip
可以使用https://github.com/TheKingOfDuck/burpFakeIP插件将xff等头部设置为127.0.0.1等进行绕过尝试
搜索引擎爬虫的访问数据
User-Agent修改为谷歌搜索引擎等