CRLF注入漏洞

CRLF是“回车 + 换行”(\r\n)的简称。在HTTP协议中,HTTP Header与HTTP Body是用两个CRLF分隔的,浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以,一旦我们能够控制HTTP 消息头中的字符,注入一些恶意的换行,这样我们就能注入一些会话Cookie或者HTML代码,所以CRLF Injection又叫HTTP Response Splitting,简称HRS。

HRS是比XSS危害更大的安全问题,具体是为什么,我们往下看。

对于HRS最简单的利用方式是注入两个\r\n,之后在写入XSS代码,来构造一个xss。

0x01 实例
举个例子,一般网站会在HTTP头中用Location: http://baidu.com 这种方式来进行302跳转,所以我们能控制的内容就是Location:后面的XXX某个网址。

所以一个正常的302跳转包是这样:

HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
但如果我们输入的是

http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行,此时的返回包就会变成这样:

HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION,造成一个“会话固定漏洞”。

当然,HRS并不仅限于会话固定,通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。

比如一个网站接受url参数 http://test.sina.com.cn/?url=xxx,xxx 放在Location后面作为一个跳转。如果我们输入的是
http://test.sina.com.cn/?url=%0d%0a%0d%0a%3Cimg%20src=1%20οnerrοr=alert(/xs/)%3E

我们的返回包就会变成这样:

HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:

之前说了浏览器会根据第一个CRLF把HTTP包分成头和体,然后将体显示出来。于是我们这里这个标签就会显示出来,造成一个XSS。

为什么说是无视浏览器filter的,这里涉及到另一个问题。

浏览器的Filter是浏览器应对一些反射型XSS做的保护策略,当url中含有XSS相关特征的时候就会过滤掉不显示在页面中,所以不能触发XSS。

怎样才能关掉filter?一般来说,用户这边是不行的,只有数据包中http头含有X-XSS-Protection并且值为0的时候,浏览器才不会开启filter。

说到这里应该就很清楚了,HRS不正是注入HTTP头的一个漏洞吗,我们可以将X-XSS-Protection:0注入到数据包中,再用两个CRLF来注入XSS代码,这样就成功地绕过了浏览器filter,并且执行我们的反射型XSS。

所以说HRS的危害大于XSS,因为它能绕过一般XSS所绕不过的filter,并能产生会话固定漏洞。

我们来一个真实案例吧。新浪某分站含有一个url跳转漏洞,危害并不大,于是我就想到了CRLF Injection,当我测试

http://xxx.sina.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E
的时候,发现图片已经输出在页面中了,说明CRLF注入成功了:

2014062816583715642.jpg

那么我们试试XSS看看:

2014062816585822978.jpg

看控制台,果然被XSS Filter拦截了。

那么我们就注入一个

X-XSS-Protection:0
到数据包中,看看什么效果:

2014062816593849016.jpg

@mramydnei 还想到了一个利用字符编码来绕过XSS Filter的方法,当编码是is-2022-kr时浏览器会忽略%0f,这样我们在onerror后面加个%0f就能绕过filter,前提是注入一个

2014062817010832293.jpg

当然,在Location:这里注入只有webkit内核浏览器才能够利用,其他浏览器可能会跳转、出错。不过对于chrome的使用量来说,危害已经足够了。

0x02 修复
如何修复HRS漏洞,当然是过滤\r 、\n之类的换行符,避免输入的数据污染到其他HTTP头。

0x03自动化
可用crlfuzz工具自动化扫描

参考:
https://blog.csdn.net/weixin_41924764/article/details/113292922
https://wooyun.js.org/drops/CRLF%20Injection%E6%BC%8F%E6%B4%9E%E7%9A%84%E5%88%A9%E7%94%A8%E4%B8%8E%E5%AE%9E%E4%BE%8B%E5%88%86%E6%9E%90.html

  • 11
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
CRLF注入漏洞是一种常见的网络安全漏洞,它在代码中未对输入进行正确的过滤和验证,导致攻击者可以利用换行符(CRLF:Carriage Return Line Feed)来执行恶意代码或实施其他攻击。 要复现CRLF注入漏洞,首先需要找到存在漏洞的应用程序。这些应用程序通常会接收用户的输入,并在服务器上生成响应,而在生成响应时未能很好地处理输入的换行符。 我们可以通过使用一个简单的示例来演示CRLF注入漏洞的复现。假设我们有一个简单的表单,允许用户提交评论,并在页面上显示评论内容,我们可以通过评论框中的输入来复现漏洞。 首先,我们在评论框中输入以下内容: ``` 本次评论测试漏洞%0D%0AContent-Length: 0%0D%0A%0D%0AHTTP/1.1 200 OK%0D%0AContent-Type: text/html%0D%0A%0D%0A<html><body>Hacked!</body></html> ``` 在上述输入中,`%0D%0A`表示换行符。我们在注入的内容中使用了换行符,然后添加了一些伪造的HTTP响应头,包括`Content-Length: 0`和`HTTP/1.1 200 OK`。最后,我们添加了一个简单的HTML页面。 当我们提交评论后,应用程序未能正确处理换行符,导致我们的注入成功。服务器在生成响应时,将我们注入的内容也作为响应头部分显示出来。 这样,我们就成功利用CRLF注入漏洞,并在生成的页面上显示了我们的内容。 为了防止CRLF注入漏洞,开发者应该对用户的输入进行正确的过滤和验证。在处理用户的输入时,应该移除或转义包含换行符的内容,以防止攻击者注入恶意内容并执行攻击。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值