phpMyAdmin的WAF规则需精准绕过其合法POST请求：禁用全字段SQL匹配，改用上下文感知检测；启用XSS多层解码，白名单合法Content-Type与Referer；静态资源路径关闭SecRuleEngine；用curl直发包测试，避免浏览器插件干扰。
phpMyAdmin 的 WAF 规则必须绕过其合法 POST 表单提交
直接套用通用 sql 注入规则会把 phpmyadmin 自身的查询请求（比如执行 select * from users）当成攻击拦截，导致功能瘫痪。它大量使用 post 提交带 sql 片段的表单字段（如 sql_query、where_clause），而这些字段名和内容结构是固定的。
实操建议：
- 禁用对
/phpmyadmin/路径下所有POST请求的「SQL 关键字全字段匹配」规则（如匹配UNION SELECT或1=1出现在任意位置） - 改用「上下文感知」规则：只检测
GET参数（如token、server）或非表单字段中的可疑模式 - 白名单
Content-Type: application/x-www-form-urlencoded且Referer包含/phpmyadmin/的 POST 请求，避免误杀
绕过 phpMyAdmin 自带 token 验证的 XSS 尝试会被 WAF 二次拦截
phpMyAdmin 对用户输入有基础过滤（如转义 <script>），但某些旧版本或自定义插件仍可能漏掉双写、大小写混淆等 XSS 变体。WAF 若只做简单标签匹配（如拦截 <script），反而容易被 <ScRiPt> 或 <img src=x onerror=alert(1)> 绕过；若过度严格（如拦截所有 onerror、javascript:），又可能干掉管理员自己写的 JS 工具脚本。
实操建议：
- 启用 WAF 的「XSS 多层解码检测」，确保识别 URL 编码、HTML 实体编码后的 payload（如
%3Cscript%3E或<script></script>） - 禁止在
phpMyAdmin的GET请求中出现on*、javascript:、data:等字符串，但允许其出现在POST的sql_query字段里（因为合法 SQL 可能含字符串字面量） - 检查 WAF 日志里是否高频触发
403 Forbidden且Request URI含/phpmyadmin/import.php—— 这常是误拦了含 HTML 样例数据的 SQL 导入
Nginx ModSecurity 规则需跳过 phpMyAdmin 的静态资源路径
如果 WAF 插件（如 ModSecurity + OWASP CRS）对 /phpmyadmin/js/、/phpmyadmin/themes/ 下的 JS/CSS 文件也做规则扫描，可能因文件内含正则表达式字面量（如 /<script/i）或 Base64 字符串触发误报，导致界面加载失败或功能异常。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 在 Nginx 配置中为 phpMyAdmin 的静态资源 location 块显式关闭 ModSecurity：
location ~ ^/phpmyadmin/(js|css|images|themes)/ { SecRuleEngine Off; } - 确认
SecRequestBodyAccess On仅作用于/phpmyadmin/index.php、/phpmyadmin/import.php等动态入口，而非整个/phpmyadmin/路径 - 避免用
SecRule REQUEST_URI "@rx /phpmyadmin/" "phase:1,deny"这类粗粒度过滤，它会一并屏蔽合法资源请求
测试时用 curl 模拟真实攻击比浏览器插件更可靠
浏览器插件（如 XSStrike、sqlmap GUI）常自动添加冗余头（X-Requested-With）、启用 Cookie 会话、甚至触发预检请求，导致 WAF 日志里看到的是「被 phpMyAdmin 自身重定向后的请求」，而不是原始攻击载荷。你根本没法判断是规则没生效，还是被后端跳转掩盖了。
实操建议：
- 用
curl -X POST -d "sql_query=SELECT%20*%20FROM%20users%20WHERE%20id%3D1%20UNION%20SELECT%201,2,3" -H "Referer: https://example.com/phpmyadmin/" https://example.com/phpmyadmin/import.php直接发包 - 观察返回状态码：
403且响应体含ModSecurity或Web Application Firewall字样，说明 WAF 生效；若返回200且含SQL syntax error，说明规则未命中 - 别依赖
sqlmap -u "https://example.com/phpmyadmin/" --batch --level=5全自动扫描 —— 它默认不带 Referer 和正确 Cookie，大概率被拒之门外，结果无意义
真正难调的是规则粒度：太松拦不住变种攻击，太紧废掉 phpMyAdmin 本身。得盯着 WAF 日志里每一条被放行的可疑 POST，逐个看 REQUEST_BODY 和 ARGS_NAMES，而不是靠「开启防护」就以为万事大吉。
