您的方法应该是双重的：

技术：
检查：

• 各种转义序列（例如 \x00、%s、\\ 等）
• Unicode 技巧（例如以 0x22 结尾的多字节字符以产生“”）
• 替代 XSS 方法（例如<img src=0 onerror=alert(1) />，代替<script>alert(1)</script>）
• cookie 和 HTTP 标头中的各种讨厌的东西（例如 XSS、SQL 注入） - 通常 WAF 会忽略这些！

忠告：
确保客户了解 WAF 只是贴膏药，不能修复断肢。如果应用程序以可利用的方式被破坏，WAF可能会阻止攻击或减轻一些影响，但无法确定它是否有效。

这也是一把双刃剑，因为人们通常认为 WAF 使不可利用的错误始终是不可利用的，因此不需要修复（至少需要匆忙修复）。浏览器和 HTML / CSS / JavaScript / SQL / XML / 服务器端语言等不断发展，因此可能会出现新的漏洞利用技术，使旧漏洞可被利用。

我想补充一点：如果测试是针对 Web 应用程序，而不是专门针对他们部署的 WAF 解决方案，那么我强烈建议客户在他们的暂存站点上禁用 WAF测试的持续时间。让它保持打开状态会使您更难为他们提供对应用程序安全状况的合理估计，这意味着他们从测试中获得的价值更少。如果他们真的对测试 WAF 感兴趣，他们可以在之后进行额外的测试，比较启用和不启用 WAF 的发现问题的可利用性。

有三种方法可以攻击 Web 应用程序防火墙 (WAF) 后面的 Web 应用程序。如果您查看现有的 WAF 绕过漏洞，您会发现它们分为两大类。您可以绕过一组规则，因为它过于严格或与实际攻击不准确匹配，或者攻击将绕过每个规则集的预处理器。还有第三类 WAF 绕过，它不需要 WAF 绕过漏洞利用。

1. WAF 预处理器攻击旨在在由 WAF 的规则集处理之前尝试从请求中隐藏或删除攻击负载。以下是 WAF 预处理器攻击的两个漏洞：

   PHPIDS 有一个不安全的“删除重复项”预处理器，可用于隐藏任何重复 33 次的有效负载。（免责声明：这是我的利用）

   IBM WebSphere 有一个不安全的“删除评论”预处理器，可用于隐藏任何有效负载。

2. WAF 规则集攻击正在利用一个弱规则集，允许攻击者提交有效的攻击字符串。在这种情况下，规则过于简单，可以修改攻击以避免检测。攻击 Web 应用程序防火墙后面的 Web 应用程序有两个方向。

   一个方向是尝试利用常见漏洞，例如 XSS 或 SQLi。确定您违反了哪些规则，并尝试修改您的攻击负载以绕过此规则。可以使用Regex Debugger审核规则，RegEx Buddy 是我最喜欢的这个过程的工具。在您能够利用 SQLi 之后，然后在应用程序中搜索 SQLi 漏洞。例如，如果您有一个修改后的字符串，该字符串将sleep(30)在 MySQL 数据库上执行而不会被 WAF 检测到，您可以使用此字符串来模糊应用程序中的盲 SQLi。 这是一个修改为绕过 mod_security 的 SQL 注入负载示例. 这是一种黑盒方法，您无法访问 Web 应用程序本身，但攻击者应始终访问 WAF。

   另一个方向是相反的，在没有 WAF 的情况下利用带有 SQLi 等漏洞的 Web 应用程序，然后尝试创建攻击字符串来利用此漏洞而不被 WAF 检测到。这是一种灰盒方法。

3. 攻击 WAF 背后的 Web 应用程序的第三种方法是完全避免该问题。WAF 不可能检测到 每一次攻击。Web 应用程序中存在 WAF 无法阻止的常见漏洞。CSRF、 批量分配、不安全的直接对象引用、点击劫持、加密预言机、身份验证/授权逻辑错误...... 发挥你的想象力。