nginx配置错误三例漏洞-
路径：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的变量：
-
$uri -
$document_uri -
$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端口访问报错，出现此页面不能正确地重定向，导致无法进行复现，但我们要掌握原理，了解该漏洞的问题之处以及防御。