CRLF注入漏洞 -配置错误

漏洞分析参考

https://i-beta.cnblogs.com/posts/edit

什么是CRLF?

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

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

回车符：光标移到行首，

换行符：光标垂直移到下行。

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

Windows：使用CRLF表示行的结束

Linux/Unix：使用LF表示行的结束

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

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

漏洞描述

在《HTTP | HTTP报文》一文中，我们介绍了HTTP报文的结构：

状态行和首部中的每行以CRLF结束，首部与主体之间由一空行分隔。或者理解为首部最后一个字段有两个CRLF，首部和主体由两个CRLF分隔。

漏洞原因

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

代码最简单的大概是这样写的

漏洞修复

过滤 \r 、\n 之类的行结束符，避免输入的数据污染其他 HTTP 首部字段

漏洞检测

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

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

环境搭建

https://github.com/vulhub/vulhub/tree/master/nginx/insecure-configuration

复现参考理解

https://blog.csdn.net/yumengzth/article/details/98474827

举个例子，一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。

一个正常的302跳转包如下图：

抓包发送repeater模式下修改包的内容（注入一个换行，在http头里注入了cookie，如下图）与url直接（上面）访问抓包，他们的返回包都是一样的。

http://192.168.189.139:8080/%0aSet-cookie:JSPSESSID%3Ddrops

此时的返回包如下图：

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

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

这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。 当然，CRLF并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。 比如一个网站接受url参数http://192.168.189.137:8080/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：

http://192.168.189.137:8080/url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>/

我们的返回包就会变成这样：

这样就造成了反射型xss