能启用SQL注入防护，但需手动配置enable_sql_injection=true、加载有效规则、重启服务并实测拦截效果；仅安装或修改部分配置无效。
能，但前提是正确启用并配置 SQL 注入防护规则——PHPWAF 本身不自动开启所有防护，enable_sql_injection 默认常为 false 或未显式设为 true，不改配置就等于没开防。
怎么确认并启用 SQL 注入防护
PHPWAF 的 SQL 注入检测不是“装上就生效”，它依赖明确的开关和规则加载：
-
config.php中必须存在且设为true：$config['enable_sql_injection'] = true; - 确保规则文件（如
rules.php或sql_injection.rule）已存在，且内容包含典型特征，例如：union.*select|select.*from|insert.*into|drop\s+table - 若使用扩展模式（
php_waf.so），需在php.ini中确认：php_waf.enable=1且php_waf.rule_path指向含 SQL 规则的目录 - 修改后必须重启 PHP-FPM 或 Apache，仅刷新页面无效
为什么开了还是被绕过？常见失效场景
启用开关只是第一步，以下情况会让防护形同虚设：
- 规则路径错误或权限不足——PHPWAF 读不到
sql_injection.rule，日志里会报failed to open stream - 正则写得太松或太死：比如只匹配
union select（忽略大小写变体），而攻击者用UnIoN/**/SeLeCt绕过 - 规则未覆盖 POST body 或 JSON 请求体——默认可能只扫
$_GET和$_COOKIE，需手动开启scan_post_data或scan_raw_body - 白名单误配：把测试 IP 加进白名单后忘了删，结果攻击流量也跟着放行
怎么验证 SQL 注入规则真在起作用
别只看配置文件有没有改，要实测拦截效果：
立即学习“PHP免费学习笔记（深入）”；
- 用 curl 发送典型 payload：
curl "http://yoursite.com/login.php?username=admin' OR '1'='1"，观察是否返回 403 或跳转到拦截页 - 检查日志文件（如
/var/log/phpwaf.log），确认有类似记录：[2026-02-03 13:05:22] 192.168.1.100 - GET /login.php?username=admin' OR '1'='1 - sql_injection - 临时在
waf.php入口加一句error_log("WAF loaded: " . print_r($config, true), 3, "/tmp/waf-debug.log");，确认enable_sql_injection确实读进来了 - 注意：测试时关闭浏览器缓存，避免误判 304 响应为“没拦截”
最易被忽略的一点：PHPWAF 是请求层过滤，它拦不住已经用 PDO 预处理语句写错的逻辑漏洞（比如 prepare 后又拼接了变量），也拦不住绕过 WAF 直连数据库的 SSRF 或内部调用。SQL 防护必须是「WAF + 参数化查询 + 最小权限」三层共存，少一层都可能被穿透。
