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:后面的内容!
![dd34ab3f689f5be8d19bb728eb5280d6.png](https://i-blog.csdnimg.cn/blog_migrate/5d40f241775a00e01450fc6ec0fadcc7.jpeg)
抓包,在请求行的url参数中加入特殊构造的CRLF字符,如下图标记所示。
如设置session,进行会话固定
%0d%0aSet-Cookie:crlf=true
![79cfcdd924c5f807d325fd3f668c6f6d.png](https://i-blog.csdnimg.cn/blog_migrate/cd7dbf0ec88d9cdade25d53378b2d866.png)
查看恶意数据是否在响应头中输出:将修改后的请求包提交给服务器端,查看服务器端的响应。发现响应首部中多了个Set-Cookie字段。这就证实了该系统存在CRLF注入漏洞,因为我们输入的恶意数据,作为响应首部字段返回给了客户端。
![e3c06da685de187589ca23fbb5e80a34.png](https://i-blog.csdnimg.cn/blog_migrate/1832bf4bc9de25864ba341f4f61a5709.png)
这是其中一段代码,用PHP写的,需要大家有一定的语言基础。看不懂也没关系,我后期会写PHP系列文章。这段代码的意思是:当条件满足时,将请求包中的url参数值拼接到Location字符串中,并设置成响应头发送给客户端。
此时服务器端接收到的url参数值是我们修改后的:
http://itsecgames.blogspot.com%0d%0aSet-Cookie:crlf=true
在url参数值拼接到Location字符串中,设置成响应头后,响应包此时应该是下图这样的:
![251b549073b77967218c9332b1668f4e.png](https://i-blog.csdnimg.cn/blog_migrate/ab7ddf6074bbf7b3e701ee6e88f8b7ef.png)
重新请求,抓包,发现Cookie中多了crlf=true。
测试的用例大家可能会觉得这漏洞没什么危害性,但试想一下:利用漏洞,注入一个CRLF控制用户的Cookie,或者注入两个CRLF,控制返回给客户端的主体,该漏洞的危害不亚于XSS。
不仅仅可以进行会话固定,也可以进行XSS攻击。
%0a%0a%0d%0d<img src=1 οnerrοr=alert(1)>
04 漏洞修复
过滤 r 、n 之类的行结束符,避免输入的数据污染其他 HTTP 首部字段。