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<img src=1 onerror=alert(/xss/)>
我们的返回包就会变成这样：
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:
<img src=1 onerror=alert(/xss/)>
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
解决方案：
1、不要把用户的输入直接输出。
2、过滤用户输入的\r\n。
参考博客：
https://www.cnblogs.com/studyskill/p/6972576.html
