HTTP响应拆分攻击是一种利用Web应用未对用户输入进行严格过滤的漏洞，攻击者通过注入恶意换行符（如CRLF）来篡改HTTP响应头部，从而实现会话劫持、跨站脚本（XSS）或缓存投毒等危害。要防护这种攻击，关键在于对HTTP头部进行严格的输入验证和输出编码，确保用户输入的数据不会被解释为控制字符。例如，在Java中，可以使用replaceAll("\r", "").replaceAll("\n", "")来过滤换行符；在PHP中，则可用str_replace(array("\r", "\n"), '', $input)。下面我将详细解析攻击原理、具体防护方法以及行业最佳实践。
HTTP响应拆分攻击的工作原理
HTTP响应拆分攻击依赖于HTTP协议中头部和正文以CRLF（Carriage Return Line Feed，即\r\n）分隔的机制。当Web应用将用户输入（如URL参数或表单数据）直接嵌入到HTTP响应头部（如Location、Set-Cookie）时，如果未过滤换行符，攻击者可注入CRLF序列来提前结束当前头部，并插入恶意头部或正文。例如，一个脆弱的重定向代码可能将用户输入的page参数放入Location头部：Location: http://example.com?page=user_input。若攻击者输入"example.com\r\nContent-Length: 0\r\n\r\n<script>恶意代码</script>"，服务器可能生成两个响应，导致XSS攻击。这种漏洞常见于动态生成头部的场景，如重定向、Cookie设置或自定义头部处理。
攻击危害与真实案例分析
HTTP响应拆分攻击可导致严重后果：首先，会话劫持——攻击者通过注入Set-Cookie头部来覆盖用户会话ID，从而控制账户；其次，跨站脚本（XSS）——通过注入恶意JavaScript代码到响应正文，窃取用户数据；最后，缓存投毒——攻击者污染代理服务器或CDN缓存，使其他用户加载恶意内容。例如，2010年某知名电商平台曾因未过滤URL中的换行符，导致攻击者可篡改密码重置链接的Location头部，引发大规模用户重定向到钓鱼网站。这种漏洞通常与输入验证不严、编码缺失相关，尤其在旧版Web框架中较为普遍。
头部过滤的核心防护方法
防护HTTP响应拆分攻击需从输入验证、输出编码和框架安全三方面入手。首先，所有用户输入（包括URL、头部、表单数据）应进行严格过滤，移除或编码换行符。在代码层面，可使用正则表达式或内置函数：例如在Python中，使用re.sub(r'[\r\n]', '', input)；在Node.js中，用input.replace(/\r?\n/g, '')。其次，输出到HTTP头部时，应对数据进行URL编码或HTML编码，防止控制字符被解释。例如，设置Location头部前，用encodeURIComponent()处理参数。此外，应避免直接拼接字符串生成头部，优先使用安全的API，如Java的response.setHeader()会自动处理特殊字符。
代码示例：实现安全的头部过滤
以下是一个Java Servlet的防护示例，展示如何过滤用户输入并安全设置头部。假设从请求参数获取redirectUrl，需将其放入Location头部：
String redirectUrl = request.getParameter("url");
if (redirectUrl != null) {
// 过滤换行符和危险字符
String filteredUrl = redirectUrl.replaceAll("[\r\n]", "");
// 进一步验证URL格式，防止协议劫持
if (filteredUrl.startsWith("http://") || filteredUrl.startsWith("https://")) {
response.setHeader("Location", filteredUrl);
} else {
response.sendError(400, "Invalid URL");
}
}在PHP中，可结合filter_var函数增强安全性：
$input = $_GET['header'];
$filtered = str_replace(array("\r", "\n"), '', $input);
$filtered = filter_var($filtered, FILTER_SANITIZE_URL);
header("Custom-Header: " . $filtered);这些代码不仅移除CRLF，还验证URL协议，避免诸如"javascript:"等危险方案。对于复杂场景，建议使用OWASP ESAPI等安全库，其提供encodeForHTML()和encodeForURL()方法，自动化处理编码。
行业最佳实践与进阶防护策略
除了基础过滤，现代Web开发应遵循多层防护原则。第一，使用最新Web框架（如Spring Security、Django），它们默认提供头部安全机制，如Spring的HeaderHttpSessionStrategy会自动过滤换行符。第二，实施内容安全策略（CSP），通过HTTP头部限制资源加载，降低XSS风险。例如，设置"Content-Security-Policy: default-src 'self'"可阻止外部脚本注入。第三，定期安全审计，利用工具如Burp Suite扫描CRLF漏洞，并检查日志中的异常头部数据。第四，教育开发团队避免直接拼接HTTP响应，强调安全编码规范。在微服务架构中，还可在API网关层统一过滤头部，减少单点漏洞。
常见误区与未来趋势
许多开发者误认为仅过滤\r\n即可，但攻击者可能使用Unicode编码或多重编码绕过过滤，因此需深度解码后验证。例如，%0d%0a是CRLF的URL编码形式，必须解码后再过滤。此外，随着HTTP/2和HTTP/3普及，头部压缩机制可能改变攻击面，但CRLF注入在文本头部中仍具威胁。未来趋势包括自动化安全测试集成到CI/CD流程，以及基于AI的异常检测，实时监控响应头部异常。总之，HTTP响应拆分防护是一个持续过程，需结合安全开发、框架更新和主动监控，才能有效抵御不断演进的攻击手法。
