1.CRLF注入
1.1环境配置
apt install nginx
vi /etc/nginx/sites-available/default
location / {
return 302 https://$host$uri;
}
service nginx restart
1.2原理
$uri为接收浏览器中的url的变量,并且会进行解码(比如传入url编码过的参数)
return 302 https://$host$uri;
为返回对应的https页面。
如果返回$uri,当传入%0D%0A就会解码成换行和回车.
当访问
http://1.1.1.1/%0D%0Aset-cookie:JSPSESSID=123
时,会跳转到
https://1.1.1.1/%0D%0Aset-cookie:JSPSESSID=123
,返回的302跳转包头应该为
HTTP/1.1 302 Moved Temporarily
.........
.........
Location: https://1.1.1.1/%0D%0Aset-cookie:JSPSESSID=123
但是因为配置文件利用的是$uri会对%0A%0D解码,所以实际的返回的跳转的包头
HTTP/1.1 302 Moved Temporarily
.........
.........
Location: https://1.1.1.1/
set-cookie:JSPSESSID=123
所以cookie就可以修改了,如果给别人发送这样一个链接,就可以控制他的cookie了。
结合xss:
两个CRLF区分头部和内容部分,所以<script>alert(222)</script>
就变成了返回的内容
这里是个302跳转,我也不知道这个xss会不会执行,在浏览器上是不会弹窗的。
我还看了师傅讲的 新浪某站CRLF注入,猜测:
并不是nginx的配置问题,而是一个http header函数的注入,php4.4开始header就限制只能处理一个头部,所以高版本是没有办法复现的。
1.3修复
location / {
return 302 https://$host$request_uri;
}
或者过滤\r \n
$request_uri不会对参数进行编码
2.目录穿越漏洞
2.1配置
想让用户直接获取主机上的文件,可以修改nginx的配置文件
vi /etc/nginx/sites-available/default
location /files {
alias /home/;
autoindex on; //可以显示目录列表
}
2.2原理
当访问http://1.1.1.1/files的时候,就可以访问/home下的文件了。
因为配置/files的别名是/home/,所以访问/files../相当于访问/home/../这样自然就到了上一级目录。
2.3 修复
根据原理,/files与他的别名相对应就可以了。
/files---/home
/files/---/home/
3.Http Header被覆盖的问题
3.1环境配置
vi /etc/nginx/sites-available/default
server {
...
add_header Content-Security-Policy "default-src 'self'";
add_header X-Frame-Options DENY;
location = /test1 {
rewrite ^(.*)$ /xss.html break;
}
location = /test2 {
add_header X-Content-Type-Options nosniff;
rewrite ^(.*)$ /xss.html break;
}
}
在web目录下边新建xss.html,内容为
<script>alert(1)</script>
3.2原理
/test2子块中的策略会直接覆盖父块中的策略使其失效
3.3 复现
访问/test1,发现不弹窗,查看源码
发现CSP起了作用,访问/test2,发现直接弹窗