HTTP头注入漏洞深度解析

概述 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 头进行校验,攻击者可以通过注入恶意内容操纵生成的超媒体链接。 ...

August 20, 2026 · 3 min · Aurora

我的第一篇技术文章

测试内容 如果看到这段文字,说明博客已经渲染成功!

August 20, 2026 · 1 min · Aurora

知识库写作指导手册——红蓝青队三维视角

手册概述 本手册旨在指导如何编写一个包含红队视角、蓝队视角、青队视角的知识库文章。该知识库将涵盖各种类型的漏洞,为每种漏洞提供详细的技术分析、检测方法和修复建议。 文章规划时间节点 6月6日初稿 6月13日完毕 进展跟踪 使用多维表进行进展跟踪(每人一篇),包含以下字段:人员、区域、漏洞、目标、培训形式、考核形式、计划完成时间。 MSS运营知识库 文章发布地址:投稿 - GreatAgain平台中心-战略支援部 漏洞分类 注入类漏洞(代码逻辑缺陷) 服务端 命令执行 代码执行 反序列化漏洞 XML注入 (XXE) JNDI注入 模板注入 (SSTI) 数据端 SQL注入 LDAP注入 前端 XPath注入 HTTP头注入 CRLF注入 SSI注入 跨站攻击类漏洞(客户端安全) 脚本攻击 跨站脚本 (XSS) JSONP劫持 CORS配置不当 请求伪造 跨站请求伪造 (CSRF) 服务器端请求伪造 (SSRF) 客户端请求伪造(点击劫持) 文件与资源操作类漏洞 文件操作类 文件上传 文件包含(本地/远程) 任意文件下载/读取/删除/创建 资源操作类 备份文件发现 路径泄漏【遍历】 目录穿越 权限管理类漏洞 访问控制 越权访问 未授权访问 登录绕过 认证缺陷 弱口令 默认口令 信息泄露类漏洞 敏感数据暴露 信息泄漏 代码泄漏 配置错误 HTTP参数污染 HTTP请求拆分 DNS域传送 内存管理类漏洞 缓冲区溢出 释放后重用 格式化字符串 越界读写 注意事项 每篇文章应注明版本号(V0.?)、撰写人、审核人、更新时间 使用markdown格式编写文章,图片放在本地文件夹中 漏洞代码以文字形式呈现,至少需要包含:代码解释、漏洞点、了解漏洞在代码中怎么产生 需要包含具体内容、经验、介绍,不能写"丢给AI处理",输入可以参考AI,不能完全AI化 研判需要包含具体的细节,包含经验性建议、研判思路,侧重漏洞本身的研判,可以讲解匹配一些特征 可以在概述中书写自己对该漏洞的学习思路,学习重心、学习建议 文章模板 概述 1. 【漏洞名称】介绍 基本概念、漏洞历史、发展、意义、危害、学习建议,需要具备一定的纵深。 ...

August 20, 2026 · 1 min · Aurora