HTTP响应拆分
翻译文章，原文：HTTP Response Splitting
描述
HTTP相应拆分发生在：
- 数据通过一个不信任的来源（地址）进入一个web应用，最常见的是HTTP请求
- （攻击）数据在一个没有被验证恶意字符串的发送给web用户的HTTP相应头中
HTTP相应拆分是一个达到目的的手段，而它本身不是一个目的。它直截了当的根本：一个攻击者发送恶意数据给受害应用，然后这个应用将这些恶意数据包含在HTTP相应头中（发回来）。
在大多数成功利用中，应用必须允许在它的头中输入包含CR（回车，也就是rul编码%0d或\r）和LF（换行符，也就是url编码%0a或\n）字符串，然后底层平台必须易受这些字符的注入。这些字符不仅仅给予攻击者控制web应用打算发送的返回包中的剩下的头部和body，也允许他们完整地去创造额外的回复。
下面的例子使用java描述，但这个问题实际上已经在所有的现在的java EE应用服务器上修复了。如果你想关注这个漏洞，你应该在目标平台测试是否允许将CRLF插入到HTTP头中。我们怀疑，不出意外的话，这个漏洞已经在大部分的目前的应用服务器上修复了，无论什么语言编写的。
例子
下面的代码段读取从HTTP请求中的博客文章，作者的名字，然后用HTTP相应包给他set一个cookie。
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);假设一个由标准的alpha-numeric字符组成的字符串，如“Jane Smith”，这个提交请求的HTTP相应就会包含相应的cookie，这个样子的：
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...然而，因为cookie的值是一个没被检验的用户输入，如果提交给授权程序的这个请求不包含任何的CRLF字符，那么相应还会保持这个形式返回。但如果攻击者提交一个恶意字符串如：“Wiley Hacker\r\nContent-Length:45\r\n\r\n… ”，之后HTTP返回包就会被拆分成一个冒名顶替的返回包：
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
Content-Length: 999
<html>malicious content...</html> (to 999th character in this example)
Original content starting with character 1000, which is now ignored by the web browser...攻击者可以利用上面这个HTTP相应去使下面的攻击生效，包括：交叉用户污染 缓存中毒 跨站脚本 和网页劫持
validated 验证的
straightforward 直截了当的
carriage return 回车
remaining 剩下的
segment 段
weblog entry 博客文章
Assuming 假设
maintain 保持
imposter 冒名顶替