ModSecurity默认启用的OWASP CRS规则会误判phpMyAdmin合法操作为攻击，因其对/phpmyadmin/等路径及SQL、base64、LFI相关规则过于敏感；应通过Apache的<Location>块配合SecRuleRemoveById和SecRuleUpdateTargetById对特定规则ID和参数（如token、sql_query）精准放行，而非全局禁用。
因为 modsecurity 默认启用的 owasp crs 规则集，会把 phpmyadmin 的合法请求（比如含 sql_query、token、base64 编码参数）当成 sql 注入或路径遍历攻击来拦截，不是你写错了 sql，而是规则没区分管理后台和普通接口。
为什么 CRS 会把 phpMyAdmin 当成攻击目标
OWASP CRS 中的 REQUEST-930-APPLICATION-ATTACK-LFI 和 REQUEST-942-APPLICATION-ATTACK-SQLI 规则，对 /phpmyadmin/ 或 /pma/ 这类路径下的所有请求一视同仁地扫描。只要参数里出现 SELECT、UNION、%2e%2e%2f（即 ../ 编码）、base64 字符串，就直接匹配并阻断。
典型错误现象是返回 403 Forbidden，日志里出现类似：
Matched "Operator `Rx' with parameter `(?i:(?:%2f%2e%2e|%2e%2e%2f|.\.|./.)`'
或
SQL injection detected
- phpMyAdmin 的登录、表结构导出、SQL 执行都依赖这些“敏感”字段，规则却没做白名单适配
-
token参数常被 base64 编码，触发932100（CSRF 检查）误报 -
collation_connection、lang等下划线命名参数，也可能被942100规则误判为恶意变量名
别全局关规则，只对 phpMyAdmin 路径精准放行
全局禁用 SecRuleEngine Off 或删掉整个 CRS 文件，等于卸掉防弹衣去打仗。正确做法是在 Apache 的 <Location> 块里做局部豁免——它按 URL 路径匹配，比 <Directory> 更可靠（尤其当 phpMyAdmin 是 alias 或软链接时）。
立即学习“PHP免费学习笔记（深入）”；
确认你的实际访问路径（比如是 /phpmyadmin 还是 /pma），然后在虚拟主机配置中加入：
<Location "/phpmyadmin">
SecRuleRemoveById 930100 930110 942100 942150 942200
SecRuleUpdateTargetById 932100 !ARGS:token
SecRuleUpdateTargetById 942100 !ARGS:sql_query !ARGS:import_text
</Location>
-
930100/930110：LFI 类规则，导出/导入功能常触发 -
942100/942150/942200：SQLi 核心规则，但只需跳过特定参数，而非整个规则 -
!ARGS:token表示对token参数不执行932100检查，否则登录总失败 - 别漏掉
import_text—— 它是 phpMyAdmin 导入页面提交 SQL 的主字段，不放行照样 403
其他常见干扰源：安全狗、云 WAF、CSP 协同误杀
ModSecurity 不是唯一拦路虎。如果你用的是国内服务器，大概率还装了“网站安全狗”，它也会对 /phpmyadmin/ 请求做关键词扫描。错误提示常是：“您的请求带有不合法参数，已被网站管理员设置拦截！”
解决方法不是改 phpMyAdmin，而是进安全狗控制台，在“主动防御 → 白名单”里添加完整访问地址，例如：
-
115.47.7.213:888（IP+端口） -
localhost:888（本地调试时） - 注意必须和浏览器地址栏里输入的完全一致，包括端口和协议前缀（不用写
http://）
另外，如果同时启用了 CSP（Content-Security-Policy），且 script-src 包含了 'unsafe-inline' 或未同步生成 nonce，WAF 可能因 JS 文件里的正则字面量（如 /<script>）再次误报——这种多层防护叠加时，最易漏掉的恰恰是“各层之间没对齐”。</script>
