请求走私是一种隐蔽却危害极大的Web攻击手法，它建立在CDN、负载均衡器等中间代理与后端应用服务器对HTTP请求边界理解不一致的基础上。当攻击者在同一个TCP连接中塞入前后端解析方式不同的请求时，后端可能把前一个请求的尾部当成下一个请求的开头，从而绕过WAF规则或越权访问内部接口。在CDN边缘做请求行与头部的规范化，相当于在流量最前端强制统一HTTP语义，让所有抵达源站的请求都只有一种合法解释。
为什么前端与后端解析差异会导致请求走私
HTTP协议在RFC 7230中定义了请求行与头部的格式，但现实中的实现各有妥协。例如对于Content-Length与Transfer-Encoding同时出现的请求，规范明确要求忽略Content-Length，但部分老版本服务器仍会读取它。当CDN以Transfer-Encoding: chunked转发、后端却按Content-Length截断时，剩余字节便成为走私内容。这种差异在反向代理场景中尤为普遍，因为边缘节点往往只做转发而不重写body边界。
另一种常见问题是头部中的_obs-fold_（折叠头部）与重复头部。有些代理会把多行以空格开头的头部合并，有些则视为独立头部；当Host头出现两次，前端取第一个，后端取最后一个，攻击者便能借助顺序差异注入路由信息。请求行本身也容易被利用：超出标准长度的URL、包含控制字符的请求行，在不同解析器中可能触发不同的截断逻辑。只有理解这些分歧点，才能在边缘设计有效的归一化规则。
从架构角度看，CDN处于用户与源站之间，具备全量流量可见性，且通常支持Lua或类似脚本扩展。把防护放在边缘，意味着不必改造后端多种语言框架，也避免了源站性能损耗。同时边缘节点可以针对每个域名下发统一策略，防止某个老旧业务泄露走私缺口。因此，规范化请求行与头部应当作为CDN基础安全能力，而非可选插件。
请求行与头部的规范化策略设计
规范请求行首先要限制其长度与字符集。绝大多数业务路径不会超过2KB，可强制截断或拒绝超长请求行，并拒绝包含未经编码的控制字符（如r、n、 ）的报文。对于方法名，仅允许GET、POST等标准大写动词，小写或畸形方法直接返回400。请求行中的HTTP版本号也应校验，避免出现HTTP/1.1之外的非法标记被后端误解析。
头部处理上，第一步是展开折叠头部：若某行以空格或制表符开头，应将其附加到上一头部字段值，并用单个空格连接。随后需合并同名头部，例如多个Content-Length应转为逗号分隔的单值，若值不一致则拒绝请求。对于Transfer-Encoding，只允许单一chunked标记，出现嵌套或配合Content-Length时直接拦截。以下Lua片段展示了在OpenResty中做基础头部合并的逻辑：
local function normalize_headers(headers)
local normalized = {}
local last_key = nil
for i, v in ipairs(headers) do
local key, val = v[1], v[2]
-- 折叠头部处理：以空格或tab开头的行归属上一头
if (val:sub(1,1) == " " or val:sub(1,1) == "t") and last_key then
normalized[last_key] = normalized[last_key] .. " " .. val:match("^%s*(.-)%s*$")
else
key = key:lower()
if normalized[key] then
-- 同名头部合并为逗号分隔
normalized[key] = normalized[key] .. "," .. val
else
normalized[key] = val
last_key = key
end
end
end
-- 检测CL与TE共存
if normalized["content-length"] and normalized["transfer-encoding"] then
return nil, "conflict CL and TE"
end
return normalized
end
除了合并与拦截，还应做头部名合法性校验。HTTP头部名只允许字母、数字与连字符，出现下划线或特殊符号的字段可能是走私探针，建议一律丢弃或报错。对于Host头，必须保证唯一且符合域名规范，防止通过重复Host绕过基于域名的路由策略。这些规则组合后，能将绝大多数走私向量消除在边缘。
在CDN边缘落地的工程实践与验证
实际部署时，建议先在观察模式运行规范化脚本，将命中异常规则的请求记录到日志，但不阻断，以评估误伤率。例如某些遗留客户端会发送带下划线的头部（如X_Forwarded_For），若直接拒绝会影响业务，可改为重命名而非丢弃。待规则稳定后，再切换为拦截模式，并对返回400的请求提供统一错误页，避免泄露过多内部细节。
验证防护有效性可借助 smuggler类工具或自写差分测试：向CDN发送精心构造的TE.CL请求，观察源站是否收到预期数量的独立请求。若后端仅看到一次完整请求且边界与前端一致，说明规范化生效。下表对比了未防护与边缘规范化后的差异：
| 场景 | 未防护后端视图 | CDN规范化后 |
|---|---|---|
| 重复Host头 | 取末个Host，可能越权 | 仅保留一个合法Host |
| CL与TE共存 | 按自身逻辑择一，易分歧 | 直接拒绝或去重 |
| 折叠头部 | 部分服务忽略，部分合并 | 统一展开合并 |
最后需注意，规范化并非万能。若源站自身存在body解析漏洞，边缘仍应配合WAF与定期渗透测试。但将请求行与头部在CDN边缘收紧为单一解释，已能消除绝大部分走私入口，且性能开销极低。随着业务微服务化，边缘规范化的边际价值还会持续提升，应作为默认开启的基础防护项写入交付流程。