精华内容
下载资源
问答
  • CRLF注入漏洞

    千次阅读 2020-07-20 18:48:31
    CRLF注入漏洞,是因为Web应用没有对用户输入做严格验证,导致攻击者可以输入一些恶意字符。攻击者一旦向请求行或首部中的字段注入恶意的CRLF,就能注入一些首部字段或报文主体,并在响应中输出,所以又称为HTTP响应...

    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 首部字段。

    展开全文
  • CRLF注入漏洞原理

    2021-01-29 06:49:51
      CRLF注入漏洞又称HTTP响应拆分漏洞(HTTP Response Splitting),攻击方式是将回车符、换行符注入到HTTP的响应包中。   HTTP响应包通常以两个换行符,去划分响应头与响应正文两个部分。当用户的操作足以控制...


    漏洞原理

      CRLF注入漏洞又称HTTP响应拆分漏洞(HTTP Response Splitting),攻击方式是将回车符、换行符注入到HTTP的响应包中。
      HTTP响应包通常以两个换行符,去划分响应头与响应正文两个部分。当用户的操作足以控制响应头的内容时,将会出现CRLF漏洞。

    换行符、回车符

    • 回车符(CR,ASCII 13,\r,%0d)
    • 换行符(LF,ASCII 10,\n,%0a)

    漏洞环境搭建

    利用docker搭建vulhub靶场,进入/vulhub/nginx/insecure-configuration目录

    启动镜像:

    docker-compose up -d
    

    8080端口是crlf漏洞靶场
    在这里插入图片描述
    Nginx会将$uri进行解码,导致传入%0a%0d即可引入换行符,造成CRLF注入漏洞。

    错误的配置文件示例(原本的目的是为了让http的请求跳转到https上):

    location / {
    	return 302 https://$host$uri;
    }
    

    漏洞利用讲解

    修改会话值

    Payload:http://your-ip:8080/%0a%0dSet-Cookie:%20a=1,可注入Set-Cookie头。
    在这里插入图片描述

    其他漏洞

    由于这个靶场只能修改Location url后的值,不能进行其他漏洞的演示。这里只能简单讲解其他漏洞的利用。

    漏洞源码:

    <?php
    
    $test = $_POST['setcookie'];
    if(isset($test)){
    	setcookie($test);
    }
    
    ?>
    

    反射形xss

    当我们输入两次%0d时,响应头和响应正文会进行分离,就可以构成反射行xss

    payload:

    http://you-ip/?setcookie=%0dX-XSS-Protection:%200%0a%0d%0a%0d%0a<script>alert('xss')</script>
    

    响应包:

    HTTP/1.1 200 OK
    Content-Type: text/html 
    Connection: close 
    set-cookie: 
    X-XSS-Protection: 0
    
    
    <script>alert('xss')</script>
    

    漏洞加固

    过滤 \r 、\n 之类的换行符,避免输入的数据污染到其他 HTTP 消息头。

    参考链接

    CRLF Injection漏洞的利用与实例分析

    展开全文
  • CRLF注入漏洞学习记录

    2021-05-01 21:46:52
    之前居然没听过CRLF注入漏洞,半夜看群友水群,学习了一波。 0x00 CRLF注入漏洞 从owasp.org上找到对应的解释,CRLF即为CR(\r)回车和LF(\n)换行,在不同的操作系统上有不同的作用,比如windows中\r\n才代表换行,...

    放假抽空把学习的知识记录一下!之前居然没听过CRLF注入漏洞,半夜看群友水群,学习了一波。


    0x00 CRLF注入漏洞

    在这里插入图片描述
    owasp.org上找到对应的解释,CRLF即为CR(\r)回车LF(\n)换行,在不同的操作系统上有不同的作用,比如windows\r\n才代表换行,但是在Linux中只有LF(\n)才代表换行,早期的macos系统也有使用CR(\r)代表换行的。
    在这里插入图片描述
    一段有意思的故事

    据野史记载,在很久以前的机械打字机时代,CR和LF分别具有不同的作用:
    LF会将打印纸张上移一行位置,但是保持当前打字的水平位置不变;
    CR则会将“Carriage”(打字机上的滚动托架)滚回到打印纸张的最左侧,但是保持当前打字的垂直位置不变,即还是在同一行。
    当CR和LF组合使用时,则会将打印纸张上移一行,且下一个打字位置将回到该行的最左侧,也就是我们今天所理解的换行操作。
    

    HTTP协议中,使用CR-LF来进行换行,使用连续两个CR-LF来隔断响应头部和正文,根据这个原理,如果我们可以控制传入的参数来改变HTTP协议的响应头部,那就可以注入一些危险代码到头部或者正文,从而形成CRLF Injection。另外HTTP Response Splitting简称HPS漏洞,就是通过CRLF Injection漏洞来进行实现。

    不过经过自身的复现和学习,发现这个漏洞现在能利用的场景不多,比较鸡肋。


    0x01 复现失败到成功

    由于需要控制传入的参数,并且服务器会有回显,一般可能会出现在:

    • 重定向
    • 可以控制set-cookie或者其他自定义header的时候

    这里就自己写了php的跳转进行测试。

    <?php
    if(@$_GET["url"]) {
        $url = @$_GET['url'];
        header("Location: $url");
    }
    ?>
    

    功能正常显示
    在这里插入图片描述这里在crlf.php后面加上%0d%0a也就是\r\n的编码。首先使用使用payload来进行Cross-User_Defacement攻击来进行替换回应的页面。

    访问的链接应该为crlf.php?url=crlf.php%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>test</html>

    按推断回应的结果应该是会有两个响应,因为当正常传入crlf.php的时候,响应头部中会有字段Location: crlf.php,现在我输入了一堆参数后,就会变成Location: crlf.php%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>test</html>,将符号处理后即变成下面的样子。
    在这里插入图片描述
    继续处理%0d%a,就会得到最终结果。
    在这里插入图片描述
    会发现能得到两个响应消息,第二个消息此时就可以替换掉原有的用户页面,从而实现攻击。

    理想很丰满,现实很骨感,得到的结果却是。。。
    在这里插入图片描述
    对,报错了,复现失败,提示头部不能包含超过一个以上的头部,检测到空行,也就是说服务器已经默认防御了这种攻击。在更换了多种复现环境和更换浏览器(有说要使用chrome才行)均失败后,查找资料发现漏洞是和PHP版本相关的,但是由于PHP版本太老,最高也不能超过5.1.2,我也就放弃更换版本复现了。

    PHP - 4.2.1 - CVE-2002-1783
    
    TOMCAT - Before 6.0.37 / 7.0.30 - CVE-2012-3544
    

    这里在网上查到可以使用nginx进行错误配置进行模拟复现,nginx错误配置如下图
    在这里插入图片描述
    再次进行漏洞利用,复现成功。
    在这里插入图片描述
    到这里基本就能理解漏洞含义了,但是这样的复现没有利用价值,于是找了一个相关的CVE来进行复现。


    0x02 CVE-2019-9740

    Python urllib CRLF 注入漏洞,此漏洞虽然也是crlf漏洞,但是利用场景和之前的演示还是挺不一样的,之前讲的是增加头部信息来修改响应包,而Python的crlf实际是上用来修改请求头。

    影响版本

    • Python 2.x版本至2.7.16版本中的urllib2
    • Python 3.x版本至3.7.2版本中的urllib

    这里我测试了有点久,有点小坑,先用的windows环境下的2.7.12,不太行,后来换成了linux下的3.6.6版本也不行。报的都是相同错误,并没有被修复。
    在这里插入图片描述
    修复过的是这样的
    在这里插入图片描述
    最后测试后,使用环境是python3.7.0版本,正常复现,另外使用了Phpstudy搭建了一个临时的redis服务进行复现。

    python2代码如下,复现失败,记录

    import urllib2
    proxy_info = { 'host' : '127.0.0.1',
                   'port' : 8080
                 } 
    
    proxy_support = urllib2.ProxyHandler({"http" : "http://%(host)s:%(port)d" % proxy_info})
    opener = urllib2.build_opener(proxy_support)
    urllib2.install_opener(opener)
     
    host = "127.0.0.1?\r\nSET test success\r\n"
    url = "http://" + host + ":8080/test/?test=a"
    
    htmlpage = urllib2.urlopen(url.strip()).read()
    print htmlpage
    

    python3代码如下,复现成功

    import urllib
    import urllib.error
    import urllib.request
    
    #proxy_support = urllib.request.ProxyHandler({'http': '127.0.0.1:8080'})
    #opener = urllib.request.build_opener(proxy_support)
    #urllib.request.install_opener(opener)
    
    host = "192.168.181.208:6379?\r\nSET test success1\r\n"
    url = "http://" + host + ":8080/test/?test=a"
    try:
        info = urllib.request.urlopen(url).info()
        print(info)
    except urllib.error.URLError as e:
        print(e)
    

    客户端测试机为win7地址为192.168.181.207,redis站点为win2008地址为192.168.181.208

    python运行后,在redis服务上查看已经缓存成功
    在这里插入图片描述
    通过wireshark可以看到交互的信息,这里通过burpsuite获取不到信息。
    在这里插入图片描述

    展开全文
  • Nginx会将$uri进行解码,导致传入%0a%0d即可引入换行符,造成CRLF注入漏洞。 错误的配置文件示例(原本的目的是为了让http的请求跳转到https上): location / { return 302 https://hosthosthosturi; } Payload: ...

    一、漏洞描述

    CRLF是”回车+换行”(\r\n)的简称,其十六进制编码分别为0x0d和0x0a。在HTTP协议中,HTTP header与HTTP Body是用两个CRLF分隔的,浏览器就是根据这两个CRLF来取出HTTP内容并显示出来。所以,一旦我们能够控制HTTP消息头中的字符,注入一些恶意的换行,这样我们就能注入一些会话Cookie或者HTML代码。CRLF漏洞常出现在Location与Set-cookie消息头中。

    二、漏洞原理

    1、 修改nginx.conf,在如下图位置添加如下配置,此配置实现了强制跳转的功能,当用户访问nginx服务器时由于此配置的存在会被强制跳转到以https协议访问之前访问的链接。
    在这里插入图片描述
    2、上面的配置的关键利用点由两个:
    一是配置中的url,url是我们可以控制的,这样我们就可以在url处填入CRLF,然后对服务器进行访问实现头部注入。二是服务器会返回一个302跳转给用户,所以我们注入的头部参数又会返回到客户这边。

    三、环境搭建

    在这里插入图片描述
    运行成功后,Nginx将会监听8080/8081/8082三个端口,分别对应三种漏洞。

    四、漏洞复现

    浏览器访问http://192.168.36.147/,然后抓包,修改数据包,如下图所示,成功实现了CRLF头部注入

    Payload: http://your-ip:8080/%0a%0dSet-Cookie:%20a=1,可注入Set-Cookie头。
    在这里插入图片描述
    可以用来XSS弹窗
    在这里插入图片描述

    五、漏洞防御

    1、删除配置不当的配置

    更多web安全工具与存在漏洞的网站搭建源码,收集整理在知识星球。
    在这里插入图片描述

    展开全文
  • CRLF注入漏洞,是由于Web应用没有对用户输入做严格验证,导致攻击者可以输入一些恶意字符。攻击者一旦向请求行或首部中的字段注入恶意的CRLF,就能注入一些首部字段或报文主体,并在响应中输出,所以又称为HTTP响应...
  • 003_crlf注入漏洞

    2018-05-23 19:53:00
    线上收到一个crlf 注入漏洞. 同时启用80和443才会暴露,配置如下: server { listen 80; listen 443 ssl; server_name www.jyall.cn; access_log /data/log/nginx/www.jyall.cn.access.log ng...
  • NGINX-CRLF注入漏洞

    2019-11-02 19:58:58
    对于CRLF漏洞的介绍先看这篇文章: https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html http://192.168.61.143:8080/%0A%0DSet-Cookie:%20a=1%0A%0DSet-cookie:JSPSESSID%3Dwooyun ...
  • 三、/r/n除了伪造日志,可造成的其他问题------》CRLF注入漏洞 CRLF注入漏洞源于应用程序未对用户提交的数据进行过滤。 危害:可以通过CRLF注入会话cookie、html代码。会造成cookie注入和xss。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,386
精华内容 554
关键字:

crlf注入漏洞