nginx $uri导致的CRLF注入漏洞

 路径：nginx/insecure-configuration

运行成功后，Nginx将会监听8080/8081/8082三个端口，分别对应三种漏洞。

8080：CRLF注入漏洞

8081： 目录穿越漏洞

8082： add_header被覆盖

$uri导致的CRLF注入漏洞

Nginx会将$uri进行解码，导致传入%0d%0a即可引入换行符，造成CRLF注入漏洞。

错误的配置文件示例（原本的目的是为了让http的请求跳转到https上）：

下面两种情景十分常见：

1.用户访问http://example.com/aabbcc，自动跳转到https://example.com/aabbcc

将会301跳转到https；随着现在https的普及，很多站点都强制使用https访问，这样的跳转非常常见。

2.用户访问http://example.com/aabbcc，自动跳转到http://www.example.com/aabbcc

该场景主要是为了统一用户访问的域名，更加有益于SEO优化。

在跳转的过程中，我们需要保证用户访问的页面不变，所以需要从Nginx获取用户请求的文件路径。查看Nginx文档，可以发现有三个表示uri的变量：

1. $uri

2. $document_uri

3. $request_uri

解释一下，1和2表示的是解码以后的请求路径，不带参数；3表示的是完整的URI（没有解码）。那么，如果运维配置了下列的代码：

location / {
    return 302 https://$host$uri;
}

因为$uri是解码以后的请求路径，所以可能就会包含换行符，也就造成了一个CRLF注入漏洞。

这个CRLF注入漏洞可以导致会话固定漏洞、设置Cookie引发的CSRF漏洞或者XSS漏洞。其中，我们通过注入两个\r\n即可控制HTTP体进行XSS，但因为浏览器认为这是一个300跳转，所以并不会显示我们注入的内容。

这个情况下，我们可以利用一些技巧：比如使用CSP头来iframe的地址，这样浏览器就不会跳转，进而执行我们插入的HTML：

如何修复这个CRLF漏洞？正确的做法应该是如下：

location / {
    return 302 https://$host$request_uri;
}

另外，由$uri导致的CRLF注入漏洞不仅可能出现在上述两个场景中，理论上，只要是可以设置HTTP头的场景都会出现这个问题。

由于我的8080端口访问报错，出现此页面不能正确地重定向，导致无法进行复现，但我们要掌握原理，了解该漏洞的问题之处以及防御。