WAF 是什么？

核心解释

WAF 常与 CDN 或反向代理结合，可根据规则、信誉和行为特征过滤流量。

WAF 在应用前方检查什么

WAF（Web Application Firewall）位于客户端与 Web 应用之间，检查 HTTP/HTTPS 请求和部分响应，根据规则、信誉、行为与速率识别 SQL 注入、XSS 探测、路径遍历、恶意机器人等模式。它可以部署在 CDN 边缘、云负载均衡、反向代理或主机前方。

WAF 看到的是协议和应用流量，不自然理解全部业务语义。规则过宽会漏过变体，规则过严会误伤合法用户；加密流量需要在可检查的位置终止 TLS。它适合降低常见攻击压力和争取修复时间，不能代替安全开发。

规则、评分与行为检测如何协同

• 签名规则匹配已知攻击语法，异常评分把多个较弱信号累计后决定阻断，降低单条规则过度敏感的问题。
• 正向安全模型只允许符合 API schema、参数类型和业务范围的请求，精度更高但需要持续维护。
• IP 信誉、设备特征、速率限制和挑战机制可处理扫描与自动化流量，合法高频 API 需要单独基线。
• 检测模式先记录事件，阻断模式执行拒绝；成熟上线会结合日志回放、灰度和例外管理减少误报。

为什么绕过源站会削弱 WAF

如果攻击者能发现并直接连接源站 IP，请求可能绕开边缘 WAF。源站应只接受来自受信代理的流量、验证回源证书或签名，并保护历史 DNS、邮件头和错误页面不泄露真实入口。

另一个问题是只保护首页域名，API、上传域、旧子域或备用端口没有接入同一策略。资产清单与统一流量入口决定覆盖范围，不能从主页面出现某个 WAF 标头推断所有服务都受保护。

实际应用与信息解读

挑战页面、特定 Cookie、响应头和网络归属可以作为 WAF 线索，但厂商可能隐藏或自定义这些特征。只有实际观察到拦截行为或明确平台信息时，才适合确定使用情况。

发现 WAF 可以推测网站具备一层流量防护，不能推断应用没有漏洞。未发现特征时状态应为未知，而不是直接写成“无防护”或“源站暴露”。

重点关注

WAF 能降低常见攻击压力，但不能代替修复应用本身的漏洞。

常见问题

有 WAF 就不需要修复漏洞吗？

仍然需要。WAF 规则可能被绕过，也无法理解所有业务逻辑，根本措施仍是修复代码、依赖和权限设计。

WAF 为什么会拦截正常用户？

合法参数可能与攻击模式相似，或速率、地区和设备行为触发策略。需要用日志和业务基线调整规则。

页面没有 WAF 标头就代表没用 WAF 吗？

不代表。平台可以隐藏特征、使用白标或仅保护部分路径，证据不足时应显示未知。