Plesk服务器WordPress站点ModSecurity SQL注入告警：真实攻击还是误报？

大概率是误报，原因如下：

• 站点导出到本地环境运行正常，说明代码本身不存在恶意注入逻辑，也没有触发本地安全规则的异常内容。
• sbjs_first这个cookie通常来自前端的访问统计或滚动跟踪类脚本（比如记录用户首次访问时间、滚动深度的工具），正常情况下只会存储时间戳或简单标识字符串，不会包含SQLmap的攻击特征。触发拦截是因为Comodo的这条SQL注入规则（ID 218500）正则匹配范围过宽，误将正常的cookie内容识别为攻击payload。
• 若为真实SQLmap攻击，通常会伴随多次带有不同注入特征的请求，或者后台出现异常登录、数据库操作记录，不会仅针对部分前端页面触发单一规则拦截。

验证与解决方法 #

验证步骤 #

1. 查看sbjs_first的实际cookie值：在浏览器开发者工具的「应用」-「Cookie」里找到该cookie，确认内容是否包含UNION、SELECT这类SQL注入相关字符串（正常情况下应该是数字或短字符）。
2. 临时禁用规则测试：在Plesk的ModSecurity管理界面，找到ID为218500的规则并临时禁用，再访问之前报错的页面，若恢复正常则坐实误报。

解决建议 #

• 直接排除规则：在Plesk的ModSecurity设置中，添加规则例外，忽略ID 218500的拦截。
• 针对cookie做例外：在ModSecurity配置文件中添加自定义规则，允许sbjs_first cookie的内容通过：

  SecRule REQUEST_COOKIES:sbjs_first ".*" "phase:2,nolog,allow"
  

• 排查前端脚本：找到站点中生成sbjs_first cookie的插件或主题脚本，确认其输出格式，必要时修改cookie值的生成逻辑，避免触发安全规则。

内容的提问来源于stack exchange，提问作者Next level web