在本文中，我们将探讨何谓HTTP响应拆分以及攻击行为是怎样进行的。一旦彻底理解了其发生原理(该原理往往被人所误解)，我们就可以探究如何利用响应拆分执行跨站点脚本(简称XSS)。接下来自然就是讨论如果目标网站存在响应拆分漏洞，我们要如何利用这一机会组织CSRF(即跨站点伪造请求)攻击。最后，我们一起来看看哪些预防措施能够抵御这些攻击行为。如果大家对这个话题感兴趣，不妨继续读下去。

什么是HTTP响应拆分?

首先让我们设想一下某个具备多种语言选项的页面。该页面的默认语言为英语，但其中同时具备一个下拉菜单，允许我们在选定其中对应的其它语种后，整个页面的语言也同时发生切换。比方说根据初始页面的配置，302重新指向的结果为https://www.abc.com /index.php?lang=en。但对于来自德国的用户而言，当然希望页面内容以德语呈现，这时他们就可以从下拉菜单的备用语言中进行选择。这使得 302重新指向将被发往服务器上的德语页面——https://www.abc.com/index.php?lang=german。用户的浏览器会遵循重新指向的引导，并将德语页面正常呈现出来。

现在让我们思考一下HTTP 302重新指向响应的主体内容。内容大体如下：

或者是：

HTTP/1.1 302 Moved Temporarily Location: https://www.abc.com/index.php?lang=german

大家可能已经发现了，惟一产生变化的只有lang参数的值。也就是说，这个值是由用户所控制，我们可以将该值设置为任何想要的内容。正是这种特性导致了HTTP响应拆分攻击的发生。

此时我们不再把参数值设定为"german"，而是按照下列内容进行设定：

a) The value 'german' b) CR/LF - %0d%0a c) A response with Content Length 0 [这里之所以设长度为0，是因为这一段其实无关紧要] d) CR/LF - %0d%0a e) A response which contains malicious content [举例来说，可以设定JavaScript会在页面被访问时自动下载恶意软件]

先来看看c)的内容--这也是首个响应。HTTP协议的工作方式是一个请求对应一个响应，因此针对该请求——即 https://www.abc.com/index.php?lang=german的响应是经过精心设计的。其实我们并不关心这个响应本身及其内容，我们想要的只是将Content-Length: 0设为其响应头。

CR/LF(即回车换行符)是响应之间的分界符。所以只要我们如d)中所示加入CR/LF内容，那么第二轮响应即会启动，且根据HTTP协议的规定这是完全正常的。在新一轮响应中我们可以添加大量信息。举例来说，如果我们打算显示一条"Hello, you have been phished"(意为'你好，你已然中招了')的消息，此时面前已经完全没有任何阻碍了。只需输入如下所示的内容，即可轻松实现：

HTTP/1.1 200 OKContent-Type: text/htmlContent-Length: 41Hello, you have been phished

还是觉得有点迷糊?让我们再总结一次。攻击者控制参数并发送一个将产生两次响应的请求;这两次响应都由攻击者组织，并以服务器为目标。首个响应旨在回应将页面转化为德语的请求，而第二个响应(到目前为止)还未经解释，它只是暂时挂起--因为该响应还没有能够映射的对应请求。请记住，HTTP需要响应(无论内容代码是什么)，但它需要的是一个能对应所有请求的响应。因此挂起中的HTTP响应是无法工作的。

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

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

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

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

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

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

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

https://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.1Host: www.abc.com

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

希望经过上面的详细介绍，大家会对HTTP响应拆分有一个明确的概念。这里是文章的重中之重，所以不妨多读几遍。关键在于，攻击者发出的第二条请求会迫使代理服务器遵从第二条请求对应第二次响应的映射模式。一旦理解了这一点，整个概念应该就比较清晰了。