CRLF注入

描述

CRLF是“回车(CR,Carriage Return) + 换行(LF, Line Feed)”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。

所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS

前置知识

  • CRLF指的是回车符(CR，ASCII 13，\r，%0d) 和换行符(LF，ASCII 10，\n，%0a),CRLF的概念源自打字机，表明行的结束，计算机出现后沿用了这个概念

  • 浏览器会根据CRLF将http包分为header和body，然后将body中的内容执行

  • 根据 HTTP/1.1 规范（RFC 7230），HTTP头字段是通过 CRLF（即 \r\n，对应 %0d%0a）来分隔的,因此，当一个 HTTP 头部结束时，它应该总是以一个 CRLF 结尾后跟另一个 CRLF 来表示 HTTP 头部的结束和 HTTP 正文的开始。换句话说，标准的 HTTP 头部结束应当是 CRLF CRLF，即 **\r\n\r\n **或 %0d%0a%0d%0a。

稍作区别
  • 回车符：光标移到行首
  • 换行符：光标垂直移到下行

平常键盘的回车（Enter）就能执行该操作，但对于不同操作系统，行的结束也是不一样的

  • Windows:使用CRLF表示行的结束
  • Linux/Unix:使用LF表示行的结束
  • MacOs:早期使用CR，现在使用LF（应该是）

漏洞利用

通常是利用该漏洞在http报文头部插入header来进行一些利用

会话固定攻击（session fixation attack）

举个例子，一般网站会在HTTP头中用Location： http://www.yuyoung.fun 这种方式来进行302跳转，如果我们能控制Location，假设一个例子：

http://xxx.com/?url=http://www.yuyoung.fun

这里的url参数会被添加到报文的Location，而该参数是我们可控的

正常的302跳转包是这样：

HTTP/1.1 302 Moved Temporarily 
Date: Sun, 18 Feb 2024 17:52:17 GMT 
Content-Type: text/html 
Content-Length: 114514
Connection: close 
Location: http://www.yuyoung.fun

但如果我们传参的url是：

http://www.yuyoung.fun%0a%0dSet-cookie:JSPSESSID%3Dhacker

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

HTTP/1.1 302 Moved Temporarily 
Date: Sun, 18 Feb 2024 17:52:17 GMT
Content-Type: text/html 
Content-Length: 114514
Connection: close 
Location: http://www.yuyoung.fun
Set-cookie: JSPSESSID=hacker

这个时候这样我们就给访问者设置了一个SESSION，造成一个会话固定漏洞，即可实现令牌提权

反射型XSS

通过注入两个CRLF就能造成一个反射型XSS

比如一个网站接受url参数 http://xxx.com/?url=xxx,xxx 放在Location后面作为一个跳转。

如果我们输入的是

http://xxx.com/?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包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。

无视浏览器filter进行XSS

浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。

怎样才能关掉filter？一般来说，用户这边是不行的，只有数据包中httphead含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter

X-XSS-Protection 是一个 HTTP 头部，这个头部的目的是控制大多数现代浏览器内置的反射型跨站脚本（XSS）过滤器的行为。这个头部在早期被引入，用于给网站提供一种方式来决定是否启用或配置这种防护。

说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以先用一个CRLF将X-XSS-Protection：0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器过滤器，并且执行我们的反射型XSS。

所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞

值得注意的是，X-XSS-Protection头部现已被视为已过时，并且在最新版本的主流浏览器（如 Chrome、Firefox、Safari 和 Edge）中不再受支持。实际上，Google Chrome 自 78 版本起已彻底移除了X-XSS-Protection。这一变化是因为内置的XSS过滤器已证明可能会被绕过，另外，严格的内容安全策略（Content Security Policy，CSP）被认为是一种更强有力的跨站脚本防御机制。

不过，对于依旧支持该头部的较旧的浏览器版本，该头部的参数如下：

  • X-XSS-Protection: 0：将会关闭浏览器的 XSS 过滤器。
  • X-XSS-Protection: 1：将会开启浏览器的 XSS 过滤器，通常是在检测到潜在的攻击时，浏览器将尝试过滤掉页面中的恶意脚本。
  • X-XSS-Protection: 1; mode=block：不仅开启过滤器，浏览器还将阻止整个页面加载，而不是尝试清除掉潜在的恶意脚本。

CRLFuzz工具

从 Release v1.4.1 · dwisiswant0/crlfuzz (github.com)下载工具