宝塔面板SQL注入防护需分层配置：先确认WAF已运行并绑定站点，再启用SQL规则组、禁用宽松模式，接着为高危参数设白名单，最后规避WAF与后端解析差异。
宝塔面板的SQL注入防护不是开个开关就完事，必须分层配置：全局规则防通用攻击、站点级规则保业务可用、代码侧规避才是根治手段。
确认WAF服务已真正启动并绑定到目标站点
很多人以为点了“启动”就生效了，其实WAF模块和具体站点之间是松耦合关系。没绑定站点的WAF形同虚设。
- 进入【软件商店】→ 找到【宝塔网站防火墙】→ 确认状态为“正在运行”，不是“已安装”或“已停止”
- 点击【设置】→ 左侧选【网站防护】→ 检查目标域名右侧是否显示“已启用”，若为灰色“未启用”，需手动点击开启
- 注意：Nginx/Apache服务重启后，WAF有时会自动解绑站点，建议每次重启后都复查一次绑定状态
- 验证方式：临时发一个带
union select的请求，看返回的是 403 还是后端真实错误；返回 403 且页面含“宝塔WAF”字样，说明已生效
开启SQL注入规则组并禁用“宽松匹配”模式
默认规则组里很多SQL相关条目是关闭的，且“兼容模式”会主动放宽检测强度，这等于给注入留后门。
- 在WAF【规则管理】页 → 展开【SQL注入】分类 → 勾选全部子项，尤其不能漏掉：
SQL延时函数检测、information_schema访问检测、嵌套括号绕过检测 - 关闭【兼容性优化】或【宽松匹配】选项（不同版本叫法略有差异，通常在规则组顶部或全局设置里）
- 避免只依赖“关键词黑名单”：比如
select单独出现不拦，但select * from会被拦——这意味着业务字段含select（如商品名“Select Edition”）可能误杀，得靠白名单补救 - 保存后务必点右上角【重载规则】，部分版本不点这个，新规则不会加载进内存
为高风险接口添加参数级白名单或放行规则
WAF的拦截逻辑是“先匹配再放行”，所以哪怕你开了全局SQL防护，也必须显式告诉它：“这个参数我信得过”。否则正常业务请求也会被干掉。
- 进入站点对应的【防火墙】→ 【GET/POST 放行】→ 添加新规则
- 参数名填真实字段名，例如：
content、description、search_keyword - 放行类型选
POST或GET，取决于实际提交方式 - 放行值留空表示“该参数所有值都放行”；若要限制格式，填正则如
^[a-zA-Z0-9\u4e00-\u9fa5\s\.\,\!\?]{1,500}$（注意必须以^开头、$结尾） - 切勿对
id、page、sort这类易被误判的参数做全放行，应改用更安全的校验方式（如整数强转、枚举值比对）
警惕WAF与后端解析不一致导致的绕过漏洞
WAF和PHP/Python等后端对同一段输入的解析结果可能不同，这种“语义差”是绕过高危防护的关键缝隙，也是最容易被忽略的点。
- WAF通常按原始HTTP请求体解析，而PHP的
$_GET会自动URL解码两次，$_POST只解一次——这意味着%2527（即%27的编码）可能绕过WAF但最终变成单引号 - MySQL支持
/*!50000 SELECT */这种内联注释，WAF若未开启“注释符深度检测”，就会放过它 - 某些旧版WAF不识别
&&和||作为逻辑运算符，而MySQL完全支持，id=1 || 1=1可能逃逸 - 最稳妥的做法：在代码里统一做输入归一化（如强制UTF-8、剥离BOM、标准化空格），让WAF和后端看到的字符串完全一致
