HTTP响应拆分漏洞（HTTP Response Splitting）的核心问题在于攻击者通过注入换行符（CRLF，即\r\n）来操控服务器的HTTP响应结构，而最直接有效的防护手段就是对用户输入中的换行符进行严格过滤和转义。具体来说，当Web应用将用户可控的数据直接拼接到HTTP响应头（如Location、Set-Cookie等）中时，如果没有对其中的\r（0x0D）和\n（0x0A）字符做处理，攻击者就能注入额外的HTTP响应头甚至响应体，从而实现缓存投毒、XSS、会话劫持等攻击。解决这个问题的关键就是：在任何将用户输入写入响应头的场景下，先过滤掉或编码掉CRLF字符。

HTTP响应拆分漏洞到底是怎么回事

HTTP协议中，响应头和响应体之间用一个空白行（即\r\n\r\n）分隔。如果攻击者能在响应头中注入\r\n，就相当于在服务器"不知情"的情况下，提前结束了响应头，开始写入攻击者控制的内容。举个例子，正常响应是：

HTTP/1.1 302 Found
Location: /home
\r\n
<html>...</html>

攻击者如果在Location参数中注入\r\nContent-Length: 0\r\n\r\n<html><script>alert(1)</script>，响应就变成了：

HTTP/1.1 302 Found
Location: /home
Content-Length: 0

<html><script>alert(1)</script>

服务器以为响应已经结束，但实际上攻击者的恶意HTML已经被浏览器执行了。这就是HTTP响应拆分的本质。

换行符过滤的核心原则

防护HTTP响应拆分，最底层的逻辑就是"不让\r和\n出现在任何会被写入响应头的用户输入中"。具体操作上有两种主流策略：

第一种是黑名单过滤，直接拒绝或删除包含\r和\n的输入。第二种是白名单编码，将\r和\n转换为URL编码（%0D和%0A）或其他安全表示形式。在实际工程中，推荐两种策略结合使用，先做白名单校验，再做编码处理，形成纵深防御。

具体的过滤实现方式

在不同的编程语言和框架中，换行符过滤的实现方式有所不同，但核心思路一致。以下是几种常见语言的实现示例：

Java环境下，可以使用如下方法对用户输入进行过滤：

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

更严格的做法是同时处理URL编码形式的换行符：

public static String sanitizeHeaderValue(String input) {
    if (input == null) return null;
    String sanitized = input.replace("\r", "").replace("\n", "");
    sanitized = sanitized.replace("%0d", "").replace("%0D", "");
    sanitized = sanitized.replace("%0a", "").replace("%0A", "");
    return sanitized;
}

Python环境下，可以这样实现：

def sanitize_header_value(value):
    if value is None:
        return None
    value = value.replace('\r', '').replace('\n', '')
    value = value.replace('%0d', '').replace('%0D', '')
    value = value.replace('%0a', '').replace('%0A', '')
    return value

PHP环境下：

function sanitize_header_value($input) {
    if ($input === null) return null;
    $input = str_replace(array("\r", "\n"), '', $input);
    $input = str_replace(array('%0d', '%0D', '%0a', '%0A'), '', $input);
    return $input;
}

为什么只过滤换行符还不够

很多开发者以为把\r和\n过滤掉就万事大吉了，但实际攻击场景远比这复杂。攻击者可能利用以下绕过方式：

1. 双重URL编码：比如%250d%250a，经过两次解码后变成\r\n。所以过滤时需要递归处理，或者在解码后再做一次过滤。

2. Unicode编码：某些字符集下，Unicode字符U+2028（行分隔符）或U+2029（段落分隔符）在某些解析器中可能被当作换行符处理。虽然这种情况较少见，但在高安全要求的系统中需要考虑。

3. 空格+换行组合：某些老旧的HTTP解析器对\r\n的识别不严格，可能把\n单独当作换行。所以\r和\n必须同时过滤，不能只过滤其中一个。

从架构层面杜绝响应拆分

单纯靠过滤换行符是一种"治标"手段，更根本的解决方案是从架构设计上避免将用户输入直接拼接到响应头中。具体措施包括：

1. 使用框架提供的安全API来设置响应头。比如Java的HttpServletResponse.setHeader()方法，Spring框架的ResponseEntity等，这些方法内部通常会自动做字符校验。

2. 对重定向URL使用白名单校验。如果业务中必须根据用户输入做跳转，应该维护一个允许跳转的域名/路径白名单，只有在白名单内的才允许跳转。

3. 使用成熟的Web应用防火墙（WAF）在流量入口层拦截含有CRLF注入特征的请求。WAF规则可以检测请求参数中的\r\n及其编码变体。

4. 启用HTTP Only和Secure标志的Cookie。即使响应拆分被利用来篡改Cookie，如果Cookie设置了HttpOnly，JavaScript也无法读取，降低了会话劫持的风险。

过滤策略的最佳实践总结

在实际项目中，建议按照以下优先级来实施防护：

第一优先级：不要把用户输入直接拼接到响应头。这是最根本的原则，能避免90%的响应拆分风险。

第二优先级：如果必须使用用户输入构建响应头，先做严格的白名单校验，只允许预期的字符集（如字母、数字、斜杠、点号等）。

第三优先级：在白名单校验通过后，再做一次CRLF过滤，包括原始字符和各种编码形式。

第四优先级：在部署层面启用WAF，配置针对CRLF注入的检测规则，作为最后一道防线。

第五优先级：定期进行安全扫描和渗透测试，验证过滤逻辑是否存在绕过可能。特别是在框架升级或引入新依赖时，要重新评估过滤策略的有效性。

常见误区和注意事项

很多团队在做换行符过滤时容易犯以下错误：

误区一：只在输入端过滤一次。实际上，数据在系统内部可能经过多次转码、解码、传递，每次传递都可能引入新的换行符。正确做法是在最终写入响应头的那一刻再做一次过滤。

误区二：只过滤\n不过滤\r。Windows系统使用\r\n，但某些场景下单独的\r也可能被解析为换行。必须两个都过滤。

误区三：认为框架自动处理了就不用管。虽然现代框架大多有内置防护，但如果你在框架之外直接操作HTTP响应（比如用原生Socket、自定义中间件），就需要自己实现过滤逻辑。

误区四：过滤后直接丢弃请求。更好的做法是记录日志并返回友好的错误提示，同时不暴露具体的过滤细节，避免给攻击者提供调试信息。

总结

HTTP响应拆分漏洞虽然不像SQL注入那样常见，但一旦被利用，后果可能非常严重，包括缓存投毒导致大量用户被攻击、会话劫持导致账户被盗、配合XSS实现更复杂的攻击链。防护的核心就是对换行符（CRLF）进行严格过滤和转义，但这只是基础手段。真正安全的系统应该从架构层面避免用户输入进入响应头，配合白名单校验、WAF防护、安全Cookie策略等多层防御，才能构建起可靠的网站漏洞防护体系。记住一句话：过滤换行符是必要的，但不要只依赖过滤，纵深防御才是王道。