概述
1. HTTP头注入介绍
HTTP头注入漏洞是指攻击者诱使Web应用在合法HTTP响应中插入额外的头部字段，通常发生在应用根据用户输入动态生成响应头的场景。一旦出现此漏洞，攻击者可以构造携带特殊字符的Header值，引发HTTP响应拆分、会话固定（通过Set-Cookie头）和跨站脚本（XSS）等安全问题。
例如，如果一个应用在 Location 头中没有过滤换行符（CRLF），攻击者就可以在URL后注入 \r\n 并添加额外的 Set-Cookie 或 Location 头，从而欺骗浏览器或中间件执行恶意操作。
2. 漏洞原理
HTTP头注入的根本原因在于应用程序过度信任并直接使用了用户输入构造HTTP响应。常见情形是：开发者将外部数据（如URL参数、表单数据、请求头）拼入 Location、Set-Cookie 或自定义头等响应头中，但未对输入进行严格过滤或校验。
例如，PHP代码 header("Location: " . $url); 如果 $url 直接来自用户输入且不过滤CRLF，就可能出现漏洞。
3. 分类与变种
- CRLF注入 / HTTP响应拆分：通过在头部插入回车换行符（
\r\n），将原本的HTTP响应切分成多个响应。 - Host头注入：攻击者篡改
Host或相关头（如X-Forwarded-Host）的值，误导服务器生成指向恶意域的链接或内容。 - X-Forwarded 系列注入：在微服务或负载均衡环境中，常用
X-Forwarded-Host、X-Forwarded-For等头部传递原始客户端信息。
4. 相关基础知识
- HTTP协议规范：根据HTTP/1.1 RFC 7230，HTTP消息的头部和实体之间用两个连续的CRLF（
\r\n\r\n）分隔。 - Web服务器与负载均衡：许多Web服务器和负载均衡器根据
Host头或TLS的SNI信息决定路由目标。 - 常见框架处理方式：不同框架和语言对头部有不同默认行为。
攻击技术分析【红队视角】
1. 攻击流程阶段
- 侦察与定位：通过拦截代理捕获应用请求，修改不同头部字段的值，观察服务器响应是否可达以及有无异常变化。
- Payload构造与注入：针对发现的注入点构造攻击载荷，例如向头部注入
%0d%0a（CRLF的URL编码）以拆分响应。 - 观察与利用：查看服务器响应或业务行为是否受影响。
- 后续攻击：在确认头注入后，利用其能力执行更高级的攻击。
2. 常用工具与自动化手段
- 拦截代理与扫描器：Burp Suite 和 OWASP ZAP 是最常用的手动测试和自动化扫描工具。
- 命令行工具：
curl、netcat、python-requests等命令行工具可快速构造和发送定制请求。
3. 高级绕过技术
- 双重或多重编码：将关键字符如
%0d%0a进行双重编码（如%250d%250a），可能绕过只检查单层编码的过滤器。 - 大小写和格式变体：CRLF可写作
%0d%0a、%0D%0A等多种组合。 - 替代头部技巧：如果直接篡改
Host头遭阻断，可尝试使用X-Forwarded-Host、X-Host等头部。
4. 特定场景下的应用
- CDN/缓存：在使用CDN或反向代理的架构中，HTTP头注入可引发缓存投毒。
- 负载均衡/微服务：许多微服务架构通过负载均衡或API网关路由请求，它们往往信任
Host或X-Forwarded-Host头。
5. 常见漏洞CVE
- CVE-2022-29933（Craft CMS 密码重置投毒）：Craft CMS默认安装中，后台密码重置功能错误地使用了
X-Forwarded-Host构造邮件链接。 - CVE-2017-8295（WordPress 密码重置依赖Host头）：WordPress 4.7.0–4.7.4版本在生成密码重置邮件时，使用了错误的
Host构建链接。 - CVE-2023-34036（Spring HATEOAS 头注入）：受影响版本的Spring HATEOAS在处理不可信的
(X-)Forwarded头时存在HTTP头注入漏洞。
防御技术分析【蓝队视角】
攻击行为分析
- 流量特征与单包检测：头注入攻击往往在单次请求中出现异常模式，例如某个头部值包含回车换行（
\r\n）或其编码（%0d%0a）。 - 行为模式与关联分析：可疑行为还包括同一来源对同一路径反复发送带不同
Host/X-Forwarded值的请求。 - 攻击阶段识别：根据攻击生命周期，辨识侦察阶段和利用阶段。
防御体系优化
- 输入校验与输出过滤：最有效的防御是"不信任输入"。开发中应采用黑名单/白名单方式过滤头部输入，特别是拒绝回车（
\r）、换行（\n）等控制字符。 - 安全编码与库函数：使用框架或库提供的安全函数来设置头部。
- 网络层防护：在边界安全设备（WAF、负载均衡器）上，可配置校验规则：严格匹配允许的主机名列表，过滤非法头部模式。
应急响应指南
- 启动条件：当监测到与头部注入相关的异常时，应立即评估是否存在头注入攻击迹象。
- 应急流程：
- 取证分析：收集相关HTTP请求和响应日志、邮件日志、系统日志等。
- 隔离与缓解：暂时阻断恶意流量。
- 漏洞修补：对所有动态设置头部的代码添加校验和过滤。
- 后门排查：由于注入漏洞可能已经被利用，需检查系统是否存在异常进程或脚本文件。
典型案例
示例：企业门户密码重置攻击闭环。 某公司内部身份认证系统允许员工通过邮件重置密码。红队测试时发现，该系统在生成重置链接时直接使用了客户端请求中的 Host 头。通过Burp拦截重置请求，红队将 Host 改为 attacker.com，请求依然被接受。
蓝队发现异常：邮件服务器日志中记录了一封发往外部域名的重置邮件，且认证系统日志显示 Host 头值异常。通过日志关联分析，他们确认攻击路径并锁定了受影响接口。
专项挑战与未来展望
- HTTP/2/3新威胁：随着HTTP/2/3协议推广，头部处理发生变化。
- 协同攻击风险：头注入往往可与其他漏洞配合放大危害，例如与HTTP请求走私或缓存投毒技术结合。
参考资料
- RFC 7230: 《Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing》
- OWASP Web 安全测试指南 – “测试 HTTP Host Header 注入”
- PortSwigger Blog & Research – “Making HTTP header injection critical via response queue poisoning”
- Fastly 博客 – “What are HTTP Host header attacks?”