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 冒名顶替