2. HTTP协议与Web应用通信解析
WAF要判断一个请求是正常业务还是攻击，前提是它必须先把HTTP报文“看懂”。HTTP是Web应用与客户端之间的应用层通信协议，采用请求—响应模型：客户端发出请求报文，服务端返回响应报文。WAF通常部署在两者之间，对报文进行解析、还原、匹配与决策。理解HTTP的报文结构、状态码、头部字段、Cookie与会话机制，是后续编写防护规则、分析误报漏报的基础。
一、请求与响应的报文结构
HTTP报文由起始行、头部字段、空行和消息体四部分组成。请求报文的起始行是“请求行”，格式为：方法 + 请求目标 + 协议版本，例如 GET /search?q=waf HTTP/1.1。响应报文的起始行是“状态行”，格式为：协议版本 + 状态码 + 原因短语，例如 HTTP/1.1 200 OK。头部字段以“字段名: 字段值”成对出现，空行用于分隔头部与消息体，消息体可承载表单、JSON、文件等内容。
请求方法决定了语义：GET用于获取资源，参数通常放在URL查询串中；POST用于提交数据，参数多在消息体；PUT、DELETE用于更新和删除；HEAD只取头部；OPTIONS用于探测。WAF在解析时，需要把URL、查询串、头部、Cookie、消息体分别拆解成可匹配的字段，而不是把整段报文当作一个字符串。
下面这张图展示了WAF视角下HTTP请求—响应的解析链路，以及各字段在防护中的关注点。
二、状态码：响应结果的语义标签
状态码是三位数字，按首位分为五类。1xx表示信息性响应，如100 Continue；2xx表示成功，200 OK最常见，204表示无内容；3xx表示重定向，301永久、302临时、304未修改；4xx表示客户端错误，400请求格式错误、401未认证、403禁止访问、404资源不存在、429请求过多；5xx表示服务端错误，500内部错误、502网关错误、503服务不可用。
对WAF而言，状态码有两层意义。一是防护动作的体现：WAF拦截时通常返回403或自定义拦截页，也可能直接断开连接。二是误报排查的线索：如果某条规则上线后，业务接口大量出现400或500，往往说明规则改写了请求或拦截了正常参数。例如某电商下单接口在启用一条针对 select 关键字的规则后，订单提交成功率从99.2%降到87%，同时出现大量400响应，这就提示规则可能误伤了商品名称中含“select”的正常字段。
三、头部字段：WAF的重要判断依据
头部字段是WAF识别客户端、判断请求合法性的关键。Host用于虚拟主机路由，若Host与后端预期不一致，可能被用于缓存欺骗或SSRF探测。User-Agent可识别扫描器，如sqlmap、nikto、masscan的默认UA。Referer可判断请求来源是否合法，用于防CSRF和防盗链。Content-Type决定消息体的解析方式，若声明为 application/json 却提交表单，可能绕过只检查表单的规则。Content-Length与Transfer-Encoding涉及消息体边界，若两者同时存在且冲突，可能引发请求走私，WAF必须按严格优先级处理。
此外，X-Forwarded-For、X-Real-IP用于获取真实客户端IP，但可被伪造，WAF应结合可信代理链判断。Accept、Accept-Encoding、Connection等字段则影响内容协商与连接管理。实际配置中，WAF常对头部做白名单校验：例如只允许特定Host访问管理后台，或对缺失Referer的敏感操作请求直接拦截。
四、Cookie与会话机制
HTTP本身无状态，服务端通过Cookie与Session维持会话。常见流程是：用户登录成功后，服务端生成Session ID，通过 Set-Cookie: JSESSIONID=abc123; Path=/; HttpOnly; Secure; SameSite=Lax 下发给浏览器；后续请求浏览器自动携带 Cookie: JSESSIONID=abc123，服务端据此识别用户。
Cookie的安全属性直接影响防护效果。HttpOnly可防止JavaScript读取Cookie，降低XSS窃取会话的风险；Secure要求仅HTTPS传输；SameSite可限制跨站携带，缓解CSRF。WAF在解析Cookie时，需要关注：会话ID是否出现在URL中（易泄露）、Cookie值是否包含注入字符、是否存在超长或异常Cookie、是否缺少安全属性。对于会话固定攻击，WAF可结合登录前后Session ID是否变化来辅助判断。
五、WAF解析要点与实操检查
WAF解析HTTP时，核心动作包括：按CRLF拆分报文、区分起始行与头部、按Content-Length或chunked读取消息体、对URL和参数做百分号解码与多次解码、统一大小写与空白字符、识别编码绕过（如%2527、Unicode、Base64）。解析不完整是绕过的主要来源，例如只检查URL不检查Body，或只解码一次导致双重编码绕过。
下面给出一份可直接用于规则上线前自查的检查清单，字段和判断依据均围绕HTTP解析与WAF防护设计。
| 检查项 | 检查内容 | 判断依据 |
|---|---|---|
| 请求行解析 | 方法、URL、版本是否完整拆分 | 异常方法或超长URL应告警 |
| 查询串解码 | 是否支持多次解码与编码识别 | %2527应还原为单引号再匹配 |
| 头部校验 | Host、UA、Content-Type是否检查 | 伪造Host或扫描器UA应拦截 |
| Cookie属性 | HttpOnly、Secure、SameSite是否缺失 | 敏感会话Cookie缺失应告警 |
| 消息体读取 | Content-Length与chunked是否一致 | 冲突时按严格优先级处理 |
| 状态码监控 | 规则上线后4xx/5xx是否突增 | 突增提示可能误报 |
掌握HTTP报文结构、状态码语义、头部字段作用、Cookie与会话机制以及WAF解析要点后，才能进一步理解规则为何这样写、误报为何发生、绕过如何产生。后续的防护策略、规则调优与日志分析，都建立在对这些基础字段的准确解析之上。