漏洞分析参考
https://i-beta.cnblogs.com/posts/edit
什么是CRLF?
CRLF 指的是回车符(CR，ASCII 13， ，%0d) 和换行符(LF，ASCII 10， ，%0a)。
CRLF的概念源自打字机，表明行的结束，计算机出现后沿用了这个概念。
回车符：光标移到行首，
换行符：光标垂直移到下行。
键盘上的回车键(Enter)就可以执行该操作。但是不同的操作系统，行的结束符是不一样的。
Windows：使用CRLF表示行的结束
Linux/Unix：使用LF表示行的结束
MacOS：早期使用CR表示，现在好像也用LF表示行的结束
所以同一文件在不同操作系统中打开，内容格式可能会出现差异，这是行结束符不一致导致的。
漏洞描述
在《HTTP | HTTP报文》一文中，我们介绍了HTTP报文的结构：
状态行和首部中的每行以CRLF结束，首部与主体之间由一空行分隔。或者理解为首部最后一个字段有两个CRLF，首部和主体由两个CRLF分隔。
漏洞原因
CRLF注入漏洞，是因为Web应用没有对用户输入做严格验证，导致攻击者可以输入一些恶意字符。攻击者一旦向请求行或首部中的字段注入恶意的CRLF，就能注入一些首部字段或报文主体，并在响应中输出，所以又称为HTTP响应拆分漏洞
代码最简单的大概是这样写的
漏洞修复
过滤 、 之类的行结束符，避免输入的数据污染其他 HTTP 首部字段
漏洞检测
CRLF注入漏洞的本质和XSS有点相似，攻击者将恶意数据发送给易受攻击的Web应用程序，Web应用程序将恶意数据输出在HTTP响应头中。（XSS一般输出在主体中）
所以CRLF注入漏洞的检测也和XSS漏洞的检测差不多。通过修改HTTP参数或URL，注入恶意的CRLF，查看构造的恶意数据是否在响应头中输出。
环境搭建
https://github.com/vulhub/vulhub/tree/master/nginx/insecure-configuration
复现参考理解
https://blog.csdn.net/yumengzth/article/details/98474827
举个例子，一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
一个正常的302跳转包如下图：
抓包发送repeater模式下修改包的内容（注入一个换行，在http头里注入了cookie，如下图）与url直接（上面）访问抓包，他们的返回包都是一样的。
http://192.168.189.139:8080/%0aSet-cookie:JSPSESSID%3Ddrops
此时的返回包如下图：
查看恶意数据是否在响应头中输出
将修改后的请求包提交给服务器端，查看服务器端的响应。发现响应首部中多了个Set-Cookie字段。这就证实了该系统存在CRLF注入漏洞，因为我们输入的恶意数据，作为响应首部字段返回给了客户端。
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。 当然，CRLF并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。 比如一个网站接受url参数http://192.168.189.137:8080/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
http://192.168.189.137:8080/url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>/
我们的返回包就会变成这样：
这样就造成了反射型xss