http请求中必备的字符段_HTTP响应拆分（CRLF注入）

CRLF注入

01 漏洞描述

在《HTTP | HTTP报文》一文中，我们介绍了HTTP报文的结构：状态行和首部中的每行以CRLF结束，首部与主体之间由一空行分隔。或者理解为首部最后一个字段有两个CRLF，首部和主体由两个CRLF分隔。

CRLF注入漏洞，是因为Web应用没有对用户输入做严格验证，导致攻击者可以输入一些恶意字符。攻击者一旦向请求行或首部中的字段注入恶意的CRLF，就能注入一些首部字段或报文主体，并在响应中输出，所以又称为HTTP响应拆分漏洞（HTTP Response Splitting）。

02 漏洞知识拓展

HTTP响应拆分漏洞，也叫CRLF注入攻击。CR、LF分别对应回车（%0d）、换行（%0a）字符。HTTP头由很多被CRLF组合分离的行构成，每行的结构都是“键：值”。如果用户输入的值部分注入了CRLF字符，它有可能改变的HTTP报头结构。

攻击者可能注入自定义HTTP头。例如，攻击者可以注入会话cookie或HTML代码。这可能会进行类似的XSS（跨站点脚本）或会话固定漏洞。

CRLF的概念源自打字机，表明行的结束，计算机出现后沿用了这个概念。

回车符：光标移到行首，

换行符：光标垂直移到下行。

键盘上的回车键(Enter)就可以执行该操作。但是不同的操作系统，行的结束符是不一样的。

Windows：使用CRLF表示行的结束

Linux/Unix：使用LF表示行的结束

MacOS：早期使用CR表示，现在好像也用LF表示行的结束

所以同一文件在不同操作系统中打开，内容格式可能会出现差异，这是行结束符不一致导致的。

在HTTP规范中，行应该使用CRLF来结束。首部与主体由两个CRLF分隔，浏览器根据这两个CRLF来获取HTTP内容并显示。

HTTP相应拆分发生在：

数据通过一个不信任的来源（地址）进入一个web应用，最常见的是HTTP请求

（攻击）数据在一个没有被验证恶意字符串的发送给web用户的HTTP相应头中

HTTP相应拆分是一个达到目的的手段，而它本身不是一个目的。它直截了当的根本：一个攻击者发送恶意数据给受害应用，然后这个应用将这些恶意数据包含在HTTP相应头中（发回来）。

在大多数成功利用中，应用必须允许在它的头中输入包含CR（回车，也就是rul编码%0d或r）和LF（换行符，也就是url编码%0a或n）字符串，然后底层平台必须易受这些字符的注入。这些字符不仅仅给予攻击者控制web应用打算发送的返回包中的剩下的头部和body，也允许他们完整地去创造额外的回复。

03 漏洞检测

CRLF注入漏洞的本质和XSS有点相似，攻击者将恶意数据发送给易受攻击的Web应用程序，Web应用程序将恶意数据输出在HTTP响应头中。（XSS一般输出在主体中）

所以CRLF注入漏洞的检测也和XSS漏洞的检测差不多。通过修改HTTP参数或URL，注入恶意的CRLF，查看构造的恶意数据是否在响应头中输出。

找到输入点，构造恶意的CRLF字符

正常一般网站会在HTTP头中用Location: ip这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的内容！

抓包，在请求行的url参数中加入特殊构造的CRLF字符，如下图标记所示。

如设置session，进行会话固定

%0d%0aSet-Cookie:crlf=true

查看恶意数据是否在响应头中输出：将修改后的请求包提交给服务器端，查看服务器端的响应。发现响应首部中多了个Set-Cookie字段。这就证实了该系统存在CRLF注入漏洞，因为我们输入的恶意数据，作为响应首部字段返回给了客户端。

这是其中一段代码，用PHP写的，需要大家有一定的语言基础。看不懂也没关系，我后期会写PHP系列文章。这段代码的意思是：当条件满足时，将请求包中的url参数值拼接到Location字符串中，并设置成响应头发送给客户端。

此时服务器端接收到的url参数值是我们修改后的：

http://itsecgames.blogspot.com%0d%0aSet-Cookie:crlf=true

在url参数值拼接到Location字符串中，设置成响应头后，响应包此时应该是下图这样的：

重新请求，抓包，发现Cookie中多了crlf=true。

测试的用例大家可能会觉得这漏洞没什么危害性，但试想一下：利用漏洞，注入一个CRLF控制用户的Cookie，或者注入两个CRLF，控制返回给客户端的主体，该漏洞的危害不亚于XSS。

不仅仅可以进行会话固定，也可以进行XSS攻击。

%0a%0a%0d%0d<img src=1 οnerrοr=alert(1)>

04 漏洞修复

过滤 r 、n 之类的行结束符，避免输入的数据污染其他 HTTP 首部字段。