路径: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:
location / { return 302 https://$host$request_uri; }
另外,由$uri
导致的CRLF注入漏洞不仅可能出现在上述两个场景中,理论上,只要是可以设置HTTP头的场景都会出现这个问题。
由于我的8080端口访问报错,出现此页面不能正确地重定向,导致无法进行复现,但我们要掌握原理,了解该漏洞的问题之处以及防御。