(二)CRLF注入

01 漏洞描述

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

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

02 漏洞知识拓展

CRLF 指的是回车符(CR,ASCII 13,\r,%0d) 和换行符(LF,ASCII 10,\n,%0a)。

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

回车符:光标移到行首,

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

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

Windows:使用CRLF表示行的结束

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

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

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

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

03 漏洞检测

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

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

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

正常请求

 

 

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

 

查看恶意数据是否在响应头中输出

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

 

 

很多人看到这里可能就想不明白,我请求包写入的恶意数据,怎么就被当成响应首部字段输出了?下面我们来看看服务器端源代码。

 

 

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

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

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

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

 

 

%0d和%0a分别是CR和LF的URL编码。前面我们讲到,HTTP规范中,行以CRLF结束。所以当检测到%0d%0a后,就认为Location首部字段这行结束了,Set-Cookie就会被认为是下一行,如下图所示。

 

 

而我们构造的Set-Cookie字符在HTTP中是一个设置Cookie的首部字段,这个时候就会将crlf=true设置成Cookie。

 

 

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

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

04 漏洞修复

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



作者:安全小白团
链接:https://www.jianshu.com/p/2f2e311e797b
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

 

posted on 2019-05-17 11:20  uestc2007  阅读(4264)  评论(0编辑  收藏

导航