现场是这样的。WAF 开了响应体内容检查,规则里包含 SQL 注入关键词。一篇讲 MySQL 优化的文章正文出现 select 语句,页面被替换成拦截提示,返回码还是 200,蜘蛛把拦截页收进了索引。
中间走过弯路,把「规则没有排除 text/html 的文章页」当成主因,改完现象没变。
排查方向其实有限,先把可能性排一排。响应体检查把教学用的语句当成注入结果;拦截页返回 200 蜘蛛当成正常页面;缓存把拦截页存了下来 改规则后仍旧出现。
动手时先对比源站和边缘返回的内容长度
curl -s https://www.example.com/p/1 | wc -c
然后用蜘蛛 UA 复现拦截
curl -s -A 'Baiduspider' https://www.example.com/p/1 | grep -c '拦截'
再往下把文章目录排除在响应体检查之外
SecRule REQUEST_URI '!@beginsWith /p/' 'chain'
等前面都确认过,再清掉被缓存的拦截页
curl -X PURGE https://www.example.com/p/1
怎么算真的好了,看的是同一批现象。文章页返回完整正文,拦截提示只在真正的攻击请求上出现。
这里还有个坑。响应体检查最容易误伤技术类内容,规则要按路径和内容类型收窄。改动前把原配置备份一份,出问题能马上回滚,这比任何技巧都实用。
