如何配置 WAF 规则拦截 WordPress 常见 SQL 注入攻击?

文章导读
配置 WAF 拦截 WordPress SQL 注入,最推荐的做法是启用云平台或面板自带的 WAF 模块,开启 SQL 注入防护规则组,并重点确保 POST 数据和 JSON body 被纳入扫描范围,同时配合 WordPress 插件更新。
📋 目录
  1. 快速处理思路
  2. 为什么会这样
  3. 分步处理
  4. 怎么验证是否生效
  5. 常见坑与误报处理
  6. 参考来源
A A

配置 WAF 拦截 WordPress SQL 注入,最推荐的做法是启用云平台或面板自带的 WAF 模块,开启 SQL 注入防护规则组,并重点确保 POST 数据和 JSON body 被纳入扫描范围,同时配合 WordPress 插件更新。

先说结论:单纯依赖 WAF 规则不够,需结合扫描范围配置与 WordPress 内部加固。

  • 先判断:确认当前 WAF 是否已启用且规则库为最新。
  • 优先做:开启 SQL 注入防护并配置 POST/JSON 数据扫描。
  • 再验证:通过日志确认拦截记录并使用测试 payload 验证。

快速处理思路

如果急需止血,请按以下顺序操作:

  1. 登录服务器面板或云控制台,确认 WAF 服务状态为“运行中”。
  2. 在 WAF 规则管理中,勾选"SQL 注入"相关规则组,防护等级调至“严格”。
  3. 检查配置项,确保开启了 POST 数据体扫描(部分 WAF 默认只扫 GET)。
  4. 观察 WAF 拦截日志 24 小时,确认无误报后再切换为拦截模式。

为什么会这样

WordPress 本身核心代码较为安全,但大量第三方插件和主题可能存在 SQL 注入漏洞,例如历史上 Fontsy 插件曾存在未授权 SQL 注入漏洞,攻击者可通过 AJAX 接口直接构造恶意参数。

如何配置 WAF 规则拦截 WordPress 常见 SQL 注入攻击?

WAF 的作用是在请求到达 PHP 应用之前,通过正则匹配或语义分析识别恶意特征(如union selectsleep())。但很多站长配置后发现拦不住,常见原因是 WAF 默认只扫描 URL 参数,而现代 WordPress 攻击常通过 POST 请求或 JSON body 提交,若未开启对应扫描范围,规则再生效也检测不到流量。

分步处理

1. 主流云 WAF 配置示例

不同云厂商配置路径略有差异,以下是常见平台的操作指引:

如何配置 WAF 规则拦截 WordPress 常见 SQL 注入攻击?
  • 阿里云 WAF:进入【网站配置】>【防护配置】>【Web 入侵防护】,确保 SQL 注入防护开关开启。在【高级设置】中检查是否启用了"POST 身体检测"。
  • Cloudflare WAF:进入【Security】>【WAF】>【Managed Rules】,启用 OWASP Core Rule Set。若需自定义,可在【Custom Rules】中添加表达式,如http.request.body contains "union select"
  • 腾讯云 WAF:在【防护配置】>【Web 攻击防护】中开启 SQL 注入防护,并在【高级防护】中开启"Body 检测"。

2. 自建 WAF 规则编写 (ModSecurity)

若使用 Nginx + ModSecurity 自建 WAF,需编写具体规则。默认规则可能漏掉变种,建议补充自定义正则。真正匹配union select需覆盖大小写、空格干扰和注释插入,参考规则如下:

SecRule ARGS|ARGS_NAMES|REQUEST_BODY "@detectSQLi" \
  "id:1001,phase:2,deny,status:403,\
  msg:'SQL Injection Attack Detected',\
  logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}'"

注意:自定义正则必须加边界符并启用 URL/十六进制解码预处理,否则UnIoN/**/SeLeCt可能绕过。建议在正式启用前先在SecRuleEngine DetectionOnly模式下运行测试。

3. 开启 POST 与原始 body 扫描

多数 WAF 默认只扫描$_GET$_COOKIE。需在配置中手动开启 POST 数据扫描。云平台 WAF 通常在“防护配置”中有“请求体检测”开关,务必启用。自建环境需确保 ModSecurity 配置了SecRequestBodyAccess On

如何配置 WAF 规则拦截 WordPress 常见 SQL 注入攻击?

4. WordPress 内部加固

WAF 是外部防御,内部代码需配合:

  • 及时更新 WordPress 核心、主题和插件,修复已知漏洞。
  • 开发自定义插件时,使用$wpdb->prepare()方法处理 SQL 查询,避免直接拼接用户输入。
  • 限制数据库用户权限,仅授予必要操作权限。

怎么验证是否生效

配置完成后,不要直接假设生效,需通过以下方式验证:

  • 日志检查:查看 WAF 拦截日志,确认是否有 SQL 注入相关的拦截记录。
  • Payload 测试:在测试环境尝试发送包含' OR 1=1 --union select sleep(5)的请求。可使用 curl 命令测试:
    curl -v -d "id=1' OR '1'='1" https://example.com/wp-admin/admin-ajax.php
    观察是否被阻断或返回 403/406 状态码。
  • 业务验证:确保正常登录、搜索、表单提交不受影响,避免误杀。

常见坑与误报处理

  • 规则加载路径错误:配置写了规则路径但文件实际位置不符,WAF 启动日志会报failed to open stream,需确认文件存在且进程有读权限。
  • 误报导致业务中断:初次部署建议先开“监测模式”,运行 24-48 小时采集正常流量日志,优化规则后再切换为“防护模式”。
  • 编码绕过:攻击者可能使用 Base64、Unicode 或十六进制编码混淆 payload,确保 WAF 开启了解码还原功能。
  • 漏扫 JSON 请求:现代应用大量使用 JSON POST,若 WAF 未配置扫描原始 body,此类请求将直接穿透。
  • 白名单配置:若发现正常业务被拦截(如某些插件含特殊字符),需在 WAF 后台将该 URL 或参数加入白名单,避免影响业务。

参考来源