HTTP响应拆分漏洞深度解析：原理、攻击场景与防御策略

一、漏洞本质与协议基础

HTTP响应拆分漏洞源于Web应用对用户输入的CRLF（回车换行，即\r\n或%0d%0a）序列未进行严格过滤，导致攻击者可篡改HTTP响应头结构。HTTP协议规定，响应报文由状态行、首部字段和主体三部分组成，各部分通过CRLF分隔。例如：

HTTP/1.1 200 OK\r\n
Content-Type: text/html\r\n\r\n
<html>...</html>

当攻击者在用户输入中注入CRLF时，可插入伪造的首部字段（如Set-Cookie）或提前终止首部区域，进而控制响应主体内容。此漏洞在通用缺陷枚举（CWE）中被编号为CWE-113，属于输入验证类安全问题的典型代表。

二、攻击路径与典型场景

1. 基础攻击原理

攻击者通过构造包含CRLF的恶意输入，触发以下两种攻击模式：

首部注入：在现有首部后插入伪造字段，例如篡改Set-Cookie实现会话固定。
响应分割：通过注入额外CRLF创建新的响应报文，导致浏览器解析混乱。

2. 常见攻击载体

重定向场景：在Location首部中注入CRLF，例如：
```
GET /redirect?url=http://example.com%0d%0aSet-Cookie:%20sessionid=attacker HTTP/1.1
```
服务器可能将伪造的Set-Cookie字段写入响应，导致用户会话被劫持。
Host字段篡改：通过修改HTTP请求的Host首部，结合CRLF注入实现缓存污染或SSRF攻击。
URL参数污染：在URL参数中嵌入CRLF，例如：
```
GET /search?q=test%0d%0aX-XSS-Protection:%200 HTTP/1.1
```
可能导致安全策略被禁用，为后续XSS攻击铺路。

3. 真实案例分析

某主流云服务商的代理模块曾曝出漏洞（CVE-2022-37436），攻击者通过恶意后端返回包含CRLF的响应，导致代理服务器提前终止首部解析，进而注入伪造内容。此类漏洞在反向代理、CDN等中间件场景中尤为危险。

三、技术实现与代码示例

1. 漏洞触发条件

满足以下两点即可能存在风险：

用户输入未经净化直接拼接到HTTP响应头中。
输入数据包含CRLF字符且未被转义。

2. 攻击代码模拟

以Python为例，攻击者可利用urllib构造恶意请求：

import urllib.request
malicious_url = "http://target.com/redirect?url=http://evil.com%0d%0aSet-Cookie:%20sessionid=hijacked"
req = urllib.request.Request(malicious_url)
response = urllib.request.urlopen(req)
print(response.info())  # 可能输出包含伪造Cookie的响应头

3. 协议层面解析

通过Wireshark抓包分析正常与恶意响应的差异：

正常响应：

HTTP/1.1 302 Found\r\n
Location: http://example.com\r\n\r\n

恶意响应：
```
HTTP/1.1 302 Found\r\n
Location: http://example.com\r\n
Set-Cookie: sessionid=hijacked\r\n\r\n
```
攻击者通过CRLF插入额外首部，浏览器会执行伪造的Cookie设置。

四、防御策略与最佳实践

1. 输入验证与过滤

严格白名单：仅允许字母、数字及必要符号，拒绝CRLF等控制字符。
正则表达式过滤：使用re.sub(r'[\r\n]', '', user_input)剔除危险字符。

2. 编码处理

URL编码转义：将\r、\n转换为%0d、%0a，但需注意部分场景（如Location首部）可能仍需额外处理。
首部字段规范化：统一使用\n代替\r\n，减少解析歧义。

3. 框架级防护

Web框架配置：如某开源框架可通过中间件自动过滤响应头中的CRLF：

from flask import Flask
app = Flask(__name__)
@app.after_request
def sanitize_headers(response):
    for key, value in response.headers.items():
        response.headers[key] = value.replace('\r', '').replace('\n', '')
    return response

4. 安全开发规范

最小权限原则：限制响应头修改权限，避免将用户输入直接传递至首部。
安全测试：通过Burp Suite等工具扫描CRLF注入点，结合OWASP ZAP进行自动化检测。

五、行业影响与演进趋势

随着HTTP/2和HTTP/3的普及，CRLF注入的攻击面有所缩小（因二进制分帧机制减少了首部拼接风险），但历史遗留系统及兼容HTTP/1.1的场景仍需警惕。此外，云原生环境下，容器间通信、API网关等组件若未严格验证输入，仍可能暴露此类漏洞。

六、总结与行动建议

HTTP响应拆分漏洞的本质是输入信任边界缺失，开发者应：

对所有动态拼接至HTTP响应头的数据进行严格过滤。
定期更新依赖库，修复已知中间件漏洞（如Apache mod_proxy历史版本问题）。
参考OWASP Top 10等标准，将CRLF检测纳入安全编码规范。

通过协议理解、代码审计和自动化测试的三重防护，可有效降低此类风险对业务的影响。