CRLF注入

       CRLF一开始知道这个东西，是因为在部署本地Install的微服务时显示失败。定位发现是因为在window下打开的文件会自动把回车+换行读成“CRLF”，而微服务中应该是Linux下打开的“LF”。CRLF的十六进制编码分别为0x0d和0x0a，进一步研究这个东西发现，居然还有安全问题。

相关的博客都提到了一个例子：

在HTTP协议中，HTTP header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP内容并显示出来。

所以，一旦我们能够控制HTTP消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码。CRLF漏洞常出现在Location与Set-cookie消息头中

1.通过CRLF注入构造会话固定漏洞

正常来讲，http包应该长下面这样：

HTTP/1.1 200 OK

Location:http://www.sina.com

但是如果改成：http://www.sina.com%0aSet-cookie:sessionid%3Dtest

服务器返回：

HTTP/1.1 200 OK

Location:http://www.sina.com

Set-cookie:sessionid=test

我们就给访问者设定了一个固定的session

2.通过CRLF注入消息头引发XSS漏洞

比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。

如果我们输入的是：http://test.sina.com.cn/?url=%0d%0a%0d%0a

我们的返回包就会变成这样：

HTTP/1.1 302 Moved Temporarily

Date: Fri, 27 Jun 2014 17:52:17 GMT

Content-Type: text/html

Content-Length: 154

Connection: close

Location:

之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里这个标签就会显示出来，造成一个XSS。

解决方案：

1、不要把用户的输入直接输出。

2、过滤用户输入的\r\n。

参考博客：

https://www.cnblogs.com/studyskill/p/6972576.html

https://zhuanlan.zhihu.com/p/22953209

https://www.jianshu.com/p/9d8ee1be48c8