网站漏洞防护中的HTTP头注入与CRLF字符过滤

HTTP头注入与CRLF（回车换行）注入，本质上是一类攻击，核心在于攻击者能够向服务器返回的HTTP响应头中注入恶意数据。这通常发生在Web应用将用户输入未经严格过滤就嵌入到响应头字段（如Location、Set-Cookie、Content-Type等）时。攻击者通过插入回车符（CR，%0d或\r）和换行符（LF，%0a或\n），可以提前终结正常的响应头，并开始写入由攻击者控制的响应体或额外的响应头，从而实现HTTP响应拆分、跨站脚本攻击（XSS）、会话固定、缓存投毒等一系列高危攻击。

HTTP协议中，响应头和响应体之间由一个空行分隔，这个空行在协议层面由CRLF（\r\n）序列定义。如果应用程序接收一个用户输入的参数，比如一个重定向URL，并直接将其放入Location头中，而没有过滤掉\r\n字符，攻击者就可以构造一个包含CRLF的恶意URL。例如，一个典型的漏洞代码片段在Java Servlet中可能看起来像这样：

String redirectUrl = request.getParameter("url");
response.setHeader("Location", redirectUrl);

当攻击者提交url=/safe-page%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert('XSS')</script>时，服务器返回的原始HTTP响应将变为：

HTTP/1.1 302 Found
Location: /safe-page
Content-Type: text/html

<script>alert('XSS')</script>

浏览器解析这个响应时，会忽略掉302状态码和原始的Location头，因为注入的空行之后的内容被视为一个新的HTTP响应体，从而导致XSS攻击。这种攻击不限于Location头，任何能够控制响应头值的场景都可能存在此漏洞，包括但不限于Set-Cookie头中的cookie值、自定义HTTP头、甚至文件名下载时的Content-Disposition头。

HTTP响应拆分是CRLF注入最经典的利用方式。攻击者不仅注入一个响应，而是注入两个完整的响应。这在代理服务器或缓存服务器环境中危害极大。攻击者可以构造一个请求，使得后端服务器返回一个被拆分的响应，其中第一个响应是正常的，第二个响应则完全由攻击者控制。如果中间缓存服务器将这两个响应都缓存起来，并将第二个恶意响应对应到某个静态资源（如/js/jquery.js）的URL上，那么所有访问该静态资源的用户都会受到攻击，形成持久的缓存投毒。这种攻击可以悄无声息地劫持大量用户的会话、植入恶意代码或重定向到钓鱼网站。

在用户登录、注销或设置偏好等场景中，应用程序常会设置Cookie。如果Cookie的名称或值部分来自用户输入且未过滤CRLF，攻击者可以注入一个完整的Set-Cookie头，从而进行会话固定攻击。例如，攻击者可以强制设置一个已知的会话ID，然后诱导受害者使用该ID登录，之后攻击者便可利用此会话ID劫持受害者账户。更隐蔽的攻击是注入HttpOnly或Secure属性缺失的Cookie，或者通过注入多个Set-Cookie头来制造Cookie解析歧义，绕过某些安全限制。

CRLF注入的危害并不局限于HTTP协议层面。在日志记录系统中，如果应用程序将用户输入直接写入日志文件，且日志条目以换行符分隔，攻击者可以通过注入CRLF来伪造日志条目。例如，攻击者可以在用户名输入框中输入admin%0d%0a[INFO] User 'system' performed critical action，这会导致日志中出现一条伪造的操作记录，干扰安全审计和事件溯源。这种攻击被称为日志注入，其原理与HTTP头注入完全相同，都是利用了文本协议中特殊控制字符的解析特性。

防御CRLF注入最根本的原则是：永远不要信任用户输入，并在输出到任何解析上下文中时进行适当的编码。具体到HTTP响应头，最有效的防御措施是严格过滤或替换用户输入中的\r和\n字符。一个健壮的白名单验证方案是只允许符合预期的字符集通过，例如在URL重定向场景中，只允许字母、数字、斜杠、问号等安全字符，直接拒绝任何包含控制字符的输入。如果业务上无法完全拒绝特殊字符，则必须进行输出编码，将%0d和%0a替换为空字符串或进行URL编码。在Java中，可以使用java.net.URLEncoder进行编码，但更安全的是使用专门的库如OWASP Java Encoder来对响应头值进行编码。在C#中，可以使用HttpUtility.UrlEncode或直接替换换行符。在PHP中，使用header()函数时，PHP会自动防止多个响应头被注入，因为header()函数会替换掉之前同名的头，但最佳实践仍然是手动过滤掉\r\n。在Python的Django框架中，设置响应头时应使用HttpResponse对象的字典式赋值，Django会自动进行保护，但在使用原始的WSGI或自定义中间件时仍需注意。

现代Web服务器和应用程序框架通常内置了一些针对HTTP头注入的防护机制。例如，Apache Tomcat 7.0.23之后的版本在设置响应头时会自动过滤掉换行符。Nginx在多数配置下也会拒绝包含换行符的响应头值。Node.js的http模块在调用response.setHeader()时，如果检测到值中包含\r或\n，会直接抛出TypeError异常。这些框架层面的保护极大地降低了CRLF漏洞的风险，但开发人员绝不能完全依赖这些底层防护。因为防护可能因版本、配置或自定义扩展而被绕过。例如，如果应用程序直接操作底层的Socket输出流来写入原始HTTP响应，那么所有框架的保护都将失效。此外，在涉及多个代理、负载均衡器和CDN的复杂架构中，任何一个环节的解析差异都可能导致防护被绕过。

即使CRLF注入漏洞存在，通过部署强力的内容安全策略（CSP）也能显著降低XSS攻击的成功率。一个配置严格的CSP头可以禁止执行内联脚本，限制脚本来源，从而使得攻击者即使成功注入了script标签也无法执行恶意代码。同样，为所有敏感Cookie设置HttpOnly属性可以防止JavaScript读取会话ID，设置Secure属性确保Cookie只在HTTPS连接中传输，设置SameSite属性可以防御跨站请求伪造。这些措施虽然不能直接修复CRLF注入漏洞，但构成了纵深防御体系中关键的一环，为漏洞修复争取了时间，并限制了攻击面。

在代码审计和渗透测试中，寻找CRLF注入漏洞需要重点关注所有将用户可控数据写入HTTP响应头的功能点。具体包括：URL重定向和跳转功能、基于用户输入设置Cookie的代码、动态设置Content-Type或Content-Disposition头的文件下载功能、以及任何通过请求参数自定义响应头的API接口。审计时，应追踪数据流，检查在数据到达响应头设置函数之前，是否经过了针对\r和\n的过滤。自动化扫描工具如Burp Suite、ZAP等可以自动检测部分CRLF注入，但手动确认和绕过测试必不可少。例如，可以尝试使用URL编码、双编码（%250d%250a）、Unicode编码（\u000d\u000a）以及各种变体来绕过简单的黑名单过滤。测试时，除了观察HTTP响应是否被拆分，还应关注响应头中是否出现了注入的换行符，以及是否能够控制响应体。

一个通用的、安全的CRLF过滤函数应当彻底移除或无害化所有可能被解析为换行符的字符序列。以下是一个在Java中实现严格过滤的示例：

public static String sanitizeHeaderValue(String input) {
    if (input == null) {
        return null;
    }
    // 移除所有的CR和LF字符
    return input.replaceAll("[\r\n]", "");
}

在PHP中，一个类似的过滤函数可以这样写：

function sanitize_header_value($value) {
    return str_replace(["\r", "\n"], '', $value);
}

对于需要更宽松处理但仍需保证安全的场景，可以考虑将换行符替换为空格或其他安全字符，而不是简单地移除。但无论如何处理，核心思想是在数据进入HTTP响应头这个解析上下文之前，必须确保它不包含能够改变协议语义的控制字符。除了过滤，使用框架提供的安全API是更好的选择。例如，在Spring MVC中，使用RedirectView或redirect:前缀进行重定向，框架会自动处理编码问题。在ASP.NET Core中，使用LocalRedirect或RedirectToPage等辅助方法，避免直接拼接用户输入到URL中。

随着微服务架构和API网关的普及，HTTP头注入的攻击面正在发生变化。API网关通常承担了请求/响应转换、认证鉴权、限流熔断等职责，如果网关自身存在CRLF注入漏洞，其影响范围将波及所有后端服务。因此，在选型和部署网关产品时，必须将其纳入安全评估范围。同时，Service Mesh技术中Sidecar代理（如Envoy）对HTTP协议的处理也需要经过严格的安全审查。在开发端，GraphQL和gRPC等新型API协议虽然不直接使用传统HTTP响应头进行数据传递，但其底层传输层仍然依赖HTTP/2，而HTTP/2对头部的处理机制有所不同，这可能会引入新的攻击向量。安全研究人员和开发人员需要持续关注这些新技术栈中的协议解析安全性。

HTTP头注入与CRLF字符过滤问题，看似是一个简单的输入验证缺失，实则反映了开发过程中对协议边界和解析上下文安全性的忽视。有效的防护不能仅靠事后修补，而应将安全编码规范集成到开发框架和代码模板中，通过静态代码分析工具在提交代码时自动检测危险模式，并在代码评审环节重点审查涉及响应头设置的逻辑。安全团队应定期对开发人员进行协议安全培训，使其理解CRLF、空字节注入、Unicode规范化等基础攻击原理。只有将这种对底层协议安全性的敬畏之心融入到日常开发的每一个细节中，才能构建出真正健壮、难以攻破的Web应用。