概述

1. HTTP头注入介绍

HTTP头注入漏洞是指攻击者诱使Web应用在合法HTTP响应中插入额外的头部字段，通常发生在应用根据用户输入动态生成响应头的场景。一旦出现此漏洞，攻击者可以构造携带特殊字符的Header值，引发HTTP响应拆分、会话固定（通过Set-Cookie头）和跨站脚本（XSS）等安全问题。例如，如果一个应用在 Location 头中没有过滤换行符（CRLF），攻击者就可以在URL后注入 \r\n 并添加额外的 Set-Cookie 或 Location 头，从而欺骗浏览器或中间件执行恶意操作。

注入类漏洞长期以来一直是信息安全中的高风险类别，历年均名列OWASP Top 10榜单前列。然而，与SQL注入、XSS等常见注入漏洞相比，HTTP头注入往往被忽视且误判为中等风险。实际上，HTTP头注入一旦配合其他漏洞或目标得当，可以造成严重后果。例如，2016年研究人员在WordPress+PHPMailer中利用Host头注入实现了远程代码执行。近期研究也指出HTTP头注入潜在的破坏力，例如通过"响应队列投毒"可以将其从中等级别攻击升级为高危漏洞。总之，HTTP头注入本质上是一个严重的输入验证缺陷，需要得到足够重视。

2. 漏洞原理（总体）

HTTP头注入的根本原因在于应用程序过度信任并直接使用了用户输入构造HTTP响应。常见情形是：开发者将外部数据（如URL参数、表单数据、请求头）拼入 Location、Set-Cookie 或自定义头等响应头中，但未对输入进行严格过滤或校验。例如，PHP代码 header("Location: " . $url); 如果 $url 直接来自用户输入且不过滤CRLF，就可能出现漏洞。同样，在Java中调用 response.addHeader("Location", userInput)，或在Python Web框架中使用 response.headers["X-Redirect"] = userInput 而不做校验，都可能导致类似问题。只要用户输入可以控制任意HTTP头的内容，且没有被有效清理，就可能发生头注入。

攻击者通常对受影响应用进行如下流程：首先识别可注入点，如通过Burp/ZAP拦截流量并修改头部字段；然后构造payload，例如向头部注入 %0d%0a（CRLF的URL编码）以拆分响应；接着观察应用响应中是否出现额外头部或被分割的内容；最后利用成功注入的头部发起后续攻击。例如，如果服务器使用 $_SERVER['HTTP_HOST'] 构建链接，攻击者可以修改 Host 头，将用户引导到恶意域。如上所述，这种未过滤换行符或域名的做法可能导致会话固定（如强制设置用户的Cookie）、反射型XSS或重定向到恶意站点。攻击目标常见于需要动态生成URL或头部信息的场景，如密码重置链接、重定向跳转和日志记录等。

3. 分类与变种

按照攻击形式，HTTP头注入及其变种主要包括：

  • CRLF注入 / HTTP响应拆分：通过在头部插入回车换行符（\r\n），将原本的HTTP响应切分成多个响应。攻击者可以利用此技术向响应头或正文中注入任意内容。典型场景是向 Location、Set-Cookie 等头部注入 payload。例如，如果Web应用执行 header("Location: " . $targetUrl); 而未过滤输入，攻击者可发送 ?url=http://example.com%0d%0aSet-Cookie:evil=1，导致响应头里出现 Set-Cookie: evil=1，实现会话固定或伪造Cookie。常见危害包括：会话固定、反射型XSS（注入恶意脚本）、重定向劫持和页面钓鱼等。

  • Host头注入：攻击者篡改 Host 或相关头（如 X-Forwarded-Host）的值，误导服务器生成指向恶意域的链接或内容。典型利用是密码重置链接劫持：Web应用将 Host 值用于构造邮件中的重置链接，攻击者将 Host 改为自己控制的域名，使重置邮件中的链接指向攻击者服务器。这种方式可导致受害者将令牌发送到攻击者，从而绕过正常认证，最终被攻击者拿到账户控制权。其他变种还包括Web缓存投毒（篡改Host后使CDN缓存恶意内容）和SSRF绕过（利用不安全的Host头引发后端请求到任意内部地址）。

  • X-Forwarded 系列注入：在微服务或负载均衡环境中，常用 X-Forwarded-Host、X-Forwarded-For 等头部传递原始客户端信息。如果应用错误信任这些头部的值，攻击者可利用相同的注入技术篡改它们。例如，CVE-2022-29933 漏洞中，攻击者添加 X-Forwarded-Host: attacker.com 以污染Craft CMS的密码重置链接；类似地，CVE-2023-34036 影响了Spring HATEOAS，如果不对 (X-)Forwarded 头进行校验，攻击者可以通过注入恶意内容操纵生成的超媒体链接。

  • 其他头部注入：包括向 Access-Control-Allow-* 等安全相关响应头注入恶意值（造成CORS配置错误），向 X-Frame-Options 注入不安全值（绕过点击劫持保护），以及日志头注入（在请求日志或错误日志中插入CRLF造成混淆）等。这些变种的原理与CRLF注入类似，只针对不同HTTP头字段进行滥用。

各类HTTP头注入的POC通常表现为恶意HTTP请求示例和响应示例。例如，针对重定向污染，攻击者可发送请求：

G H E o T s t / : r e v d u i l r n e e c r t a ? b u l r e l . = c h o t m t p : / / e x a m p l e . c o m % 0 d % 0 a C o n t e n t - T y p e : a p p l i c a t i o n / j s o n H T T P / 1 . 1

如果未过滤换行，上述请求可能使服务器返回：

H L C T o o T c n P a t / t e 1 i n . o t 1 n - : T 3 y 0 h p 2 t e t : F p o : a u / p n / p d e l x i a c m a p t l i e o . n c j m s o n

进而让攻击者插入新的 Content-Type 头。类似地，在邮件生成、缓存更新、重定向逻辑等需要拼接头部内容的地方都可能出现此类漏洞。

4. 相关基础知识

  • HTTP协议规范：根据HTTP/1.1 RFC 7230，HTTP消息的头部和实体之间用两个连续的CRLF（\r\n\r\n）分隔。浏览器和服务器根据此分隔符边界来解析请求和响应。当攻击者在头部值中插入额外的CRLF时，就能干扰这一解析过程，实现响应拆分或注入新头。在HTTP/2/3中，头部使用二进制分帧和压缩，不再使用明文CRLF分隔，但实现细节漏洞依然可能导致类似攻击。例如，PortSwigger研究发现HTTP/2引入了新的专属攻击方式（如流拆分等）。

  • Web服务器与负载均衡：许多Web服务器和负载均衡器根据 Host 头或TLS的SNI信息决定路由目标。如果 Host 值不匹配已配置域名，服务器通常拒绝请求或使用默认虚拟主机。有些服务器会在收到无法识别的域名时报错（如出现 “Invalid Host header”），这可以防止注入。但如果目标网站配置了默认回退选项，攻击者依然可以利用注入。例如，在CDN环境中改变 Host 头可能导致请求路由到攻击者设置的缓存节点。实战中，Fastly等厂商文档提醒，当中间件（如负载均衡）直接使用 Host 头进行内部请求时，攻击者可以借此发起SSRF测试。

  • 常见框架处理方式：不同框架和语言对头部有不同默认行为。比如，Java Servlet API 中的 sendRedirect 方法会自动对URL进行合法性检查，而直接使用 addHeader("Location", value) 则需要开发者自行防护。Spring Security 等现代框架通常会验证 Host 头是否在允许列表内。另一方面，Spring HATEOAS 组件在早期版本对 (X-)Forwarded 头缺乏保护（导致 CVE-2023-34036）。总的来说，了解使用的框架如何解析和验证头部，有助于识别潜在注入点并采取相应的安全配置。

攻击技术分析【红队视角】

1. 攻击流程阶段

红队实施HTTP头注入攻击时，通常经历以下关键阶段：

  1. 侦察与定位：通过拦截代理（如Burp/ZAP）捕获应用请求，修改不同头部字段（如 Host、X-Forwarded-Host 等）的值，观察服务器响应是否可达以及有无异常变化。例如，可以尝试在 Host 头中填入一个不在预期列表中的域名，查看应用是否仍接受请求。如果请求仍然命中了目标应用，说明服务器没有对该头进行严格验证，此时就找到了潜在的注入点。

  2. Payload构造与注入：针对发现的注入点构造攻击载荷。例如，在需要动态生成的头字段中注入 \r\n（URL编码为 %0d%0a）以触发响应拆分，或篡改 Host 头的值为攻击者控制域。在实际操作中，红队往往使用Burp Intruder/Repeater等工具批量测试不同payload，监测服务器返回内容。常见payload包括编码变种（如双重编码 %250d%250a）、替换域名、添加XFF头部等。

  3. 观察与利用：查看服务器响应或业务行为是否受影响。如果注入成功，服务器可能返回额外的头部字段、重定向到攻击者控制的域，或者输出了注入的内容等。红队据此进一步实施攻击。例如，如果成功在响应中插入了新的 Set-Cookie 头，就可以固定用户会话；如果重置链接指向恶意域，就可窃取重置令牌。这些利用手段都是基于注入已获取的执行上下文进行的。

  4. 后续攻击：在确认头注入后，红队会利用其能力执行更高级的攻击。例如，结合密码重置功能实施账户接管，或者利用注入的跨站脚本盗用会话。如果注入用于日志记录，红队也可能借机擦除审计痕迹或植入后门。攻击链的最终目标通常是获取敏感数据、权限提升或在系统中建立持久控制。

2. 常用工具与自动化手段

  • 拦截代理与扫描器：Burp Suite 和 OWASP ZAP 是最常用的手动测试和自动化扫描工具。Burp Proxy可用于捕获请求，Burp Repeater/Intruder用于编辑和自动发送恶意请求，对头部字段进行注入测试。可使用Burp内置的Host头测试扩展（例如"Host Header Inchecktion"）来自动化检测各种注入情形。OWASP ZAP 则提供类似的Fuzzer功能用于头部模糊测试。

  • 命令行工具：curl、netcat、python-requests 等命令行工具可快速构造和发送定制请求。示例：

    curl -H "Host: attacker.com" http://victim.example/reset?user=alice

    该命令将 Host 头设为 attacker.com，用于测试主机头注入。亦可使用 -H "Header: value" 方式篡改其他任意头部。

  • 脚本与漏洞扫描器：可以编写自定义脚本（如Python、Go等）自动化探测头注入。商业漏洞扫描工具（如Acunetix/Invicti、Nessus）也包含头注入检测模块。对于大规模资产，可结合Nmap NSE脚本批量测试头注入漏洞。

  • Burp 命令示例：在Burp Repeater中选中请求后，右键 → Host Header Inchecktion → 选择测试类型，即可在多个Payload下批量检测头注入情况。

3. 高级绕过技术

针对存在简单过滤或WAF防护的环境，攻击者可能采用以下绕过方法：

  • 双重或多重编码：将关键字符如 %0d%0a 进行双重编码（如 %250d%250a），可能绕过只检查单层编码的过滤器。如果应用对URL解码不彻底，双编码可以"传递"原始字符到后端解析阶段。

  • 大小写和格式变体：CRLF可写作 %0d%0a、%0D%0A 等多种组合。某些检测可能只针对特定形式，尝试不同大小写或部分编码（例如仅编码 \r 而不编码 \n）有时能绕过规则。

  • 使用大量空行或填充：PortSwigger研究指出，在存在"响应队列过读"（stacked-response）防护机制时，可通过在注入中插入大量无意义的换行符来绕过检测。这些额外换行会被服务器消耗但不触发请求/响应处理，从而使真正的payload得以传递和执行。

  • 替代头部技巧：如果直接篡改 Host 头遭阻断，可尝试使用 X-Forwarded-Host、X-Host 等头部，因为一些应用会优先使用这些头部来构建链接。比如 Craft CMS 的密码重置漏洞就是利用了 X-Forwarded-Host。

  • 伪造子域名或点符：通过注册看似合法的子域或使用点符技巧（如在 X-Forwarded-Host 中添加 @、# 等可允许的符号），可能绕过弱校验逻辑。一些案例表明，将符号附加到尾部可以欺骗检测规则。

  • 工具链协同：利用Burp的插件或自制协作平台（如Burp Collaborator、Interactsh）来捕获后台请求。例如，在Host头注入测试中插入Collabo域名，观察内部系统是否发起请求以确认SSRF风险。

这些高级方法表明，当标准注入手段被拦截时，可以从编码混淆、协议弱点或额外头部使用等层面寻找突破口。

4. 特定场景下的应用

  • CDN/缓存：在使用CDN或反向代理的架构中，HTTP头注入可引发缓存投毒。攻击者如果能控制URL或Host，可能使CDN缓存包含恶意内容。Fastly文档指出，恶意的Host头攻击可以用于Web缓存投毒，将带有注入内容的响应缓存，后续访问者会获取污染内容。

  • 负载均衡/微服务：许多微服务架构通过负载均衡或API网关路由请求，它们往往信任 Host 或 X-Forwarded-Host 头。前文提到，如果负载均衡器对 Host 头校验不严，攻击者可利用此进行SSRF测试。Spring Cloud、Kubernetes Ingress等平台对传入头部的处理可能不同步，注入可能导致流量绕行或内部资源被滥用。

  • 行业系统特点：金融、电商等行业系统通常对安全要求高。HTTP头注入在这些场景下可结合业务逻辑造成更严重影响，如客户邮件钓鱼、交易重定向等。另外，如果系统中存在不当的Access-Control-Allow-Origin:*配置，攻击者注入头部后可能扩大跨站脚本攻击面。

  • 新兴攻击趋势：随着协议和工具的演进，头注入也出现新挑战。例如HTTP/2/3的实现缺陷可能引发新的拆分攻击。未来研究可能发现头注入与HTTP走私、缓存投毒等并行攻击的新组合，使得头注入在更广泛的环境下发挥作用。

5. 常见漏洞CVE

以下列举若干典型的头注入相关CVE案例，以说明真实影响和修复建议：

  • CVE-2022-29933（Craft CMS 密码重置投毒）：Craft CMS默认安装中，后台密码重置功能错误地使用了 X-Forwarded-Host 构造邮件链接。攻击者向请求中添加 X-Forwarded-Host: attacker.com，应用生成的重置链接便指向恶意域。受害者点击该链接后，攻击者即可获取重置令牌并接管账户。该漏洞影响3.7.36及之前版本，厂商未发布直接修复版本，仅提供了加固配置的建议。修复方法是更新到已修复的版本或应用官方建议的解决方案。

  • CVE-2017-8295（WordPress 密码重置依赖Host头）：WordPress 4.7.0–4.7.4版本在生成密码重置邮件时，使用了错误的 Host（实际通过 $_SERVER['SERVER_NAME']）构建链接，攻击者如果能阻止目标邮箱接收正常邮件（例如通过退信），可使重置邮件发往攻击者邮箱，从而接管账户。该漏洞利用条件较苛刻（需邮件被转发或回复），但正是由于对 Host 的不当依赖而产生。WordPress 4.7.5及以上版本已修复此问题，不再使用不可信的变量构造链接。

  • CVE-2022-34165（IBM WebSphere HTTP头注入）：IBM安全公告指出，WebSphere Application Server 7.0–9.0及相关版本存在头部注入漏洞，原因是不正确验证头字段。这可能允许攻击者实施缓存投毒和跨站脚本等攻击。IBM已经发布补丁和更新解决了该问题，例如通过升级固件或应用Fix Pack来修复该漏洞。

  • CVE-2023-34036（Spring HATEOAS 头注入）：受影响版本的Spring HATEOAS在处理不可信的 (X-)Forwarded 头时存在HTTP头注入漏洞。攻击者可以通过在这些头中插入恶意内容，操纵自动生成的超媒体链接，进而误导客户端或获取敏感信息。该漏洞仅在使用Spring WebFlux构建超媒体链接且未对Forwarded头进行防护时才可被触发。官方建议将受影响组件升级到最新安全版本（例如升级到 spring-hateoas 1.5.5、2.0.5 等）以修复问题。

防御技术分析【蓝队视角】

攻击行为分析

  • 流量特征与单包检测：头注入攻击往往在单次请求中出现异常模式，例如某个头部值包含回车换行（\r\n）或其编码（%0d%0a）。蓝队可在网络入侵检测系统中添加规则，检测HTTP请求头值中出现这些非法字符序列。请求头中的非ASCII字符、嵌套的 % 编码或不合理的端口号字符也可被视为可疑。此外，如果请求同时包含多个 Content-Length 或意外的空行，也应触发警报。

  • 行为模式与关联分析：可疑行为还包括同一来源对同一路径反复发送带不同 Host/X-Forwarded 值的请求（表明可能在探测头信任逻辑），或在登录、密码重置等功能处出现大量失败的参数请求。蓝队可以利用SIEM系统关联日志：例如，当检测到多次重置请求中 Host 头指向未知域名时，将其标记为高危事件。还可关注 Set-Cookie 头的变化：CRLF注入可导致 Set-Cookie 插入，会话固定攻击特点是用户持久使用同一Cookie，若发现Cookie异常持久或篡改，也应警惕。

  • 攻击阶段识别：根据攻击生命周期，蓝队需辨识侦察阶段和利用阶段。在侦察阶段，异常请求可能较多但未见明确利用痕迹，此时可使用蜜罐或延迟响应来诱捕攻击；在利用阶段，通常会伴随成功的命令注入或信息泄露的后果，应立即启动应急响应。综合Web访问日志、邮件日志和系统日志进行分析：例如Craft CMS案例中邮件中出现了异常域，蓝队可以通过邮件服务器日志发现重置链接被发送到了非公司域名。

防御体系优化

  • 输入校验与输出过滤：最有效的防御是"不信任输入"。开发中应采用黑名单/白名单方式过滤头部输入，特别是拒绝回车（\r）、换行（\n）等控制字符。任何用于构造HTTP头的用户可控数据都应进行严格校验和长度限制（如限制为合法域名或路径字符），以避免输入数据污染到其他头。尽量避免直接使用Host、Referer等值构造重定向URL，而是采用预定义的安全域名或经验证的来源。

  • 安全编码与库函数：使用框架或库提供的安全函数来设置头部。例如在Java中，可使用 response.encodeRedirectURL(...) 等方法，它会自动进行必要的转义和验证。对自定义头部，可采用专门的编码函数或正则匹配，确保插入的值不包含非法字符。对于关键功能（如密码重置），可以添加二次验证：例如在邮件中同时显示目标域名或提供验证码，减少单纯依赖URL的风险。

  • 网络层防护：在边界安全设备（WAF、负载均衡器）上，可配置校验规则：严格匹配允许的主机名列表，过滤非法头部模式。对发现的攻击特征立即阻断，例如发现请求头中存在 %0d%0a 直接拒绝连接。需要注意的是，这类规则易带来误报：应对正常业务中的多域场景（如SNI多站点）和 X-Forwarded-For 含内网IP 等情况进行白名单配置，避免误杀正常流量。

  • 日志审计与监控：确保Web服务器和应用日志详尽记录所有请求头信息。安全团队应定期审查日志，关注不寻常的条目，如日志记录中出现了意外的空行或用户输入中断日志边界。启用入侵检测系统监控头部异常，如可设置规则监测 \r\n 字符串或非本地的域访问。一旦检测到可疑事件，即时触发响应流程。

应急响应指南【青队视角】

  • 启动条件：当监测到与头部注入相关的异常（如请求日志中出现 %0d%0a、用户报告收到可疑链接邮件或系统发现密码重置请求异常）时，应立即评估是否存在头注入攻击迹象。一旦确认攻击行为或有较大可能性，应启动应急响应。

  • 应急流程：

    1. 取证分析：收集相关HTTP请求和响应日志、邮件日志、系统日志等，确认攻击路径。定位受影响代码和头部字段，确定攻击者注入的具体payload。
    2. 隔离与缓解：暂时阻断恶意流量。可通过网络策略或WAF阻止可疑 Host/X-Forwarded 值，或在应用层快速增加过滤规则。对已泄露的令牌或凭证进行废弃，通知可能受影响的用户重置密码。
    3. 漏洞修补：在开发环境中修复根本原因：对所有动态设置头部的代码添加校验和过滤；对于使用第三方组件的漏洞（如上述CVE），立即升级到安全版本。确保部署补丁后进行全面测试。
    4. 后门排查：由于注入漏洞可能已经被利用，需检查系统是否存在异常进程或脚本文件。搜索日志和文件系统中注入的恶意内容或后门。如怀疑应用被篡改，应回退到已知安全的版本并重新部署。
    5. 恢复与总结：修复后持续监控一段时间，确认无进一步异常。编写事件报告，总结教训，更新安全策略和开发规范（如强制代码审查头部处理逻辑）。

典型案例【平台业务结合】

示例：企业门户密码重置攻击闭环。 某公司内部身份认证系统允许员工通过邮件重置密码。红队测试时发现，该系统在生成重置链接时直接使用了客户端请求中的 Host 头。通过Burp拦截重置请求，红队将 Host 改为 attacker.com，请求依然被接受。系统向受害者发送了有效的重置链接，但链接指向 attacker.com。当受害者 Alice 点击此链接时，攻击者从中获取了重置令牌并成功重置了 Alice 的密码（红队行动完成）。

蓝队发现异常：邮件服务器日志中记录了一封发往外部域名的重置邮件，且认证系统日志显示 Host 头值异常。通过日志关联分析，他们确认攻击路径并锁定了受影响接口。防护团队迅速在WAF层拒绝了非公司域名的 Host 头请求，并在应用代码中添加验证逻辑，禁止从用户输入设置重置链接域名。最后，开发人员修复代码，将重置链接的基础域名改为固定配置（而不再使用用户可控的 Host 值），彻底堵住了漏洞（蓝队行动完成）。

该案例展示了红队攻击、蓝队检测与修复的闭环过程：红队利用Host头注入实施攻击；蓝队通过日志分析和WAF策略迅速响应，并最终在应用层修补漏洞，完成端到端防护。

专项挑战与未来展望

  • HTTP/2/3新威胁：随着HTTP/2/3协议推广，头部处理发生变化。HTTP/2使用二进制帧传输头部，虽然没有明文CRLF，但研究表明其HPACK压缩和流管理可能引入新的拆分攻击（如HTTP/2专属的流超限攻击）。HTTP/3（基于QUIC）的多路复用特性也可能带来未知风险。安全界需关注这些新协议中的头部注入变种及配合请求走私的可能性。

  • 协同攻击风险：头注入往往可与其他漏洞配合放大危害。例如，结合HTTP请求走私或缓存投毒技术，可在前端服务器和后端应用之间建立更复杂的攻击链条；与SSRF漏洞结合，则可通过篡改头部获取内部资源访问权；与CSRF等漏洞同用时，也可能导致敏感操作被转移到攻击者控制的域上执行。未来应对这些复合攻击的研究和防御机制至关重要。

参考资料

  • RFC 7230: 《Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing》 (HTTP/1.1 协议规范，定义了请求/响应头的格式和分隔规则)。
  • OWASP Web 安全测试指南 – “测试 HTTP Host Header 注入” (说明如何定位和利用Host头注入)。
  • OWASP 注入预防 Cheat Sheet (提供通用注入防御策略)。
  • PortSwigger Blog & Research – “Making HTTP header injection critical via response queue poisoning” 等文章，介绍了HTTP头注入的危害和高级利用技巧。
  • Acunetix Web 安全博客 – “What is HTTP Header Injection” (头注入定义、危害和示例)。
  • Imperva 安全白皮书 – “CRLF Injection” (详述CRLF注入可导致的XSS、Cookie注入、缓存投毒等后果)。
  • SEC Consult 报告 – “Password Reset Poisoning Attack in Craft CMS” (CVE-2022-29933 漏洞分析)。
  • NVD/CVE – CVE-2017-8295、CVE-2022-34165 等官方说明。
  • Fastly 博客 – “What are HTTP Host header attacks?” (介绍Host头攻击类型、密码重置投毒及SSRF示例)。
  • Snyk 安全信息 – CVE-2023-34036 漏洞（Spring HATEOAS HTTP头注入）概述。
  • VulWiki、安全博客 – 相关技术文章（如"被遗忘的HTTP头注入"、“HTTP请求头注入漏洞"等）。