http://www.Sina.com/http://www.Sina.com /
《HTTP | HTTP报文》的文章介绍了HTTP消息的结构。 状态行和标题中的每一行都以CRLF结束，标题和主体之间用空行分隔。 可选地，第一个最后字段有两个CRLF，可以理解第一个和主体被两个CRLF隔开。
CRLF注入漏洞是因为web APP应用没有严格验证用户输入，使得攻击者能够输入恶意字符。 当攻击者在请求行或前部字段中注入恶意CRLF时，可以注入几个报头字段或消息主体，将其输出到响应，因此也称为HTTP响应分割漏洞(HTTP Response Splitting )。
http://www.Sina.com/http://www.Sina.com /
CRLF是指http://www.Sina.com/(Cr，ASCII 13，r，)和http://www.Sina.com/) lf、ASCII 10，n，
请参阅。
CRLF的概念来源于打字机，标志着行的结尾，计算机问世后继承了这个概念。
换行符：光标移动到行首。
换行符：光标垂直向下移动。
可以通过键盘上的回车键执行。 但是，行的结束符因操作系统而异。
windows :使用crlf表示行的结束
Linux/Unix :以LF表示行的结尾
MacOS :初期用CR表示，但现在似乎也有用LF表示行的结束的情况
因此，如果在不同的操作系统上打开同一文件，则内容格式可能会因行尾符号不匹配而不同。
在HTTP规范中，行必须使用CRLF结束。 标头和主体由两个CRLF分隔，浏览器根据这两个CRLF检索和显示HTTP内容。
http://www.Sina.com/http://www.Sina.com /
CRLF注入漏洞的本质与XSS有点相似。 攻击者将恶意数据发送到易受攻击的web APP应用程序，web APP应用程序则发送恶意数据01。 (XSS一般输出到主机)
所以CRLF注入漏洞的检测也和XSS漏洞的检测一样。 修改HTTP参数或URL以注入恶意CRLF，并验证生成的恶意数据是否输出到响应标头。
漏洞描述
正常请求
在请求行的url参数中添加特殊结构的CRLF字符，如下图所示。
02
将更改后的请求数据包发送到服务器端，并确认服务器端的响应。 在响应标头中添加了Set-Cookie字段。 这表明，由于我们输入的恶意数据作为响应标头字段返回到客户端，该系统存在CRLF注入漏洞。
很多人看了这里可能不明白，但是我请求了写在数据包里的恶意数据，为什么作为响应报头的字段输出了呢？ 让我们看看服务器端的源代码。
这是用PHP写的代码之一，需要大家都有一定的语言基础。 不知道也没关系。 我在后期写PHP系列的文章。 此代码意味着在满足条件时，将请求包中的url参数值连接到Location字符串，并将其设置为响应头发发送到客户端。
此时在服务器端收到的url参数值是我们更改的。
http://itsecgames.blogspot.com
Set-Cookie:crlf=true
如果将url参数值连接到Location字符串并设置为响应标头，则响应包应如下图所示。
和
分别是CR和LF的URL代码。 如前所述，在HTTP规范中，行以CRLF结尾。 所以当检测到的时候
然后，假设Location中第一个字段的行结束，Set-Cookie假设为下一行，如下图所示。
我们创建的Set-Cookie字符是在HTTP中设置Cookie的第一个字段，此时将crlf=true设置为Cookie。
再次请求，抓住包，发现Cookie中增加了crlf=true。
的测试案例可能会认为这个漏洞没什么危害，但请考虑一下。 利用漏洞，注入一个CRLF来控制用户的cookie，或注入两个CRLF来控制返回给客户端的主体。 这个漏洞的危害不亚于XSS。
http://www.Sina.com/http://www.Sina.com /
过滤行尾符号，例如r和n，以防止输入的数据污染其他HTTP标头字段。