CRLF注入与检测

发布时间:2024年01月03日

一、CRLF介绍

CRLF是CR和LF两个字符的拼接,它们 分别代表”回车+换行”(\r\n)。十六进制编码分别为0x0d和0x0a,URL编码为%0D和%0A。CR和LF组合在一起即CRLF命令,它表示键盘上的"Enter"键,许多应用程序和网络协议使用这些命令作为分隔符。
  • CR:回车,移动到当前行的开始
  • LF:换行,光标垂直移动到下一行
??
HTTP报文结构:
从上图可以看到:HTTP报文由三部分组成:状态行、首部、主体。
可以看到状态行和首部行中的每行都是以回车符(\r,%0d,CR)和换行符(\n,%0a,LF)结束。
这是 因为HTTP规范中行应该使用CRLF结束。另外,首部和主体由两个CRLF分隔

二、CRLF原理分析

CRLF是 “ 回车+换行 ”(\r\n)的简称。 在HTTP协议中,HTTP Header与HTTP Body是用两个CRLF分隔的,浏览器根据这两个CRLF来取出HTTP内容并显示出来 。所以,一旦能够控制HTTP消息头中的字符,注入一些恶意的换行,这样我们就能注入一些会话Cookie或者HTML代码。
CRLF漏洞可以造成Cookie会话固定漏洞和反射型XSS(可过waf)的危害。

三、CRLF漏洞挖掘

CRLF注入漏洞的本质和XSS有点相似,攻击者将恶意数据发送给易受攻击的Web应用程序, Web应用程序将恶意数据输出在HTTP响应头中。(XSS一般输出在主体中), 所以CRLF注入漏洞的挖掘和XSS差不多。 通过修改HTTP参数或URL,注入恶意的CRLF,查看构造的恶意数据是否在响应头中输出 漏洞注入点主要在重定向或者跳转的地方。
??
挖掘此类漏洞,观察我们的输入和输出位置,对于CRLF则是观察返回的各种类型的协议头,所以挖掘分三步:
  1. 观察输出是否在返回头中,查看输入,可能是在URL值和参数、cookie头中。在过往的挖掘过程中,最常见的两种情况是使用输入参数Set-Cookie和302跳转location处
  2. 提交 %0d%0a 字符,验证服务器是否响应%0d%0a,若过滤可以通过双重编码绕过。
  3. 漏洞利用,使杀伤最大化,将漏洞转化为HTML注入,XSS,缓存等。
??
CRLF漏洞一般通过如下3个条件可以达成这种攻击(当然要没过滤%0d%0a):
  1. Set-Cookie中的内容用户可以控制
  2. 302跳转的Location地址用户可以控制
  3. 其他自定义Header用户可以控制

四、CRLF实例

4.1、实例1(会话固定漏洞)

一般网站会在HTTP头中用? Location: http://baidu.com? 这种方式来进行302跳转,所以我们能控制的内容就是Location:后面的XX某个网站,对这个地址进行污染。
假设服务端(PHP)的处理方式:
代码意思是说当条件满足时,将请求包中url参数拼接到Loction字符串中,并设置成响应头发送给客户端。
此时服务器端接收到的url参数值是我们修改后的: http://baidu.com/xxx%0a%0dSet-Cookie:test=123
在url参数值拼接到Location字符串中,设置成响应头后,响应头就会看到:Set-Cookie:test=123
一个正常的302跳转包是这样的:
?
但是如果我们输入的是: http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行,此时的返回包就会变成下面这样:
?
这时我们就给访问者设置了一个SESSION,造成一个 “会话固定漏洞 ”。

4.2、实例2(XSS漏洞)

通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS
比如一个网站接收url参数 http://test.sina.com.cn/?url=xxxxxx放在Location后面作为一个跳转。如果我们输入的是
http://test.sina.com.cn/?url=%0d%0a%0d%0a < img src=1 οnerrοr=alert(/xss/)>
我们的返回包就会变成这样:?
?
之前说了 浏览器会根据第一个CRLF把HTTP包分成header和body,然后将body显示出来 。于是我们这里这个标签就会显示出来,造成一个XSS。
? ?
为什么说是无视浏览器filter的,这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略,当url中含有XSS相关特征的时候就会过滤掉不显示在页面中,所以不能触发XSS。
怎么才能关掉Filter?一般来说用户这边是不行的,只有数据包中http头含有 X-XSS-Protection:0 ,浏览器才不会开启Filter。
所以遇到XSS过滤的情况我们就 可以在httpheader中注入X-XSS-Protection:0,可绕过浏览器的过滤规则实现XSS弹窗显示。

4.3、实例3(nginx配置错误之CRLF漏洞)

使用vulhub的环境,进入 vulhub/nginx/insecure-configuration 目录,执行docker-compose up -d启动环境
错误的配置文件示例(原本的目的是为了让http的请求跳转到https上):
1、$uri
2、$document_uri? 前两个变量是表示的是解码以后的请求路径,不带参数
3、$request_uri? ? ?表示的是完整的URI(没有解码)
当使用前两个变量的时候就会自动解码,那么思路就是将payload编码,然后让他自动解码?。
Payload: ` http://your-ip:8080/%0d%0aSet-Cookie:%20a=1 `,可注入Set-Cookie头。?
?
可以看到payload中利用urlcode编码了来实现了换行,然后就成功了。
解决方法也很简单,就不要解码,可以使用第三个变量 $request_uri

五、防御

要避免http响应截断,需要注意以下几点:
  • 对用户的数据进行合法性校验,对特殊的字符进行编码,如<、>、’、"、CR、LF、等,限制用户输入CR和LF,或者对CR和LF正确编码后再输出,以防止注入自定义HTTP头。
  • 创建安全字符白名单,只接收白名单中的字符出现在HTTP响应头文件中。
  • 在将数据传送到http响应头之前,删除所有的换行符。

六、CRLF Payload

探测漏洞:
%0d%0aheader:header
%0aheader:header
%0dheader:header
%23%0dheader:header
%3f%0dheader:header
/%250aheader:header
/%250aheader:header
/%%0a0aheader:header
/%3f%0dheader:header
/%23%0dheader:header
/%25%30aheader:header
/%25%30%61header:header
/%u000aheader:header
开放重定向:
/www.google.com/%2f%2e%2e%0d%0aheader:header
CRLF-XSS:
%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23%0d%0a<svg%20οnlοad=alert(document.domain)>%0d%0a0%0d%0a/%2e%2e
XSS绕过:
%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContent-Length:39%0a%0a%3cscript%3ealert(document.cookie)%3c/
Location:
%0d%0aContent-Type:%20text%2fhtml%0d%0aHTTP%2f1.1%20200%20OK%0d%0aContent-Type:%20text%2fhtml%0d%0a%0d%0a%3Cscript%3Ealert(‘XSS’);%3C%2fscript%3E

七、CRLFuzz工具检测

使用crlfuzz工具检测4.3章节中的nginx配置错误之CRLF漏洞:
前方带??????? 表明这条payload探测到了CRLF漏洞。
文章来源:https://blog.csdn.net/leiwuhen92/article/details/135354660
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。