使用有什么好处：
location ~ \.PHP {
location ~ \..*/.*\.PHP${
return 403;
}
fastcgi_pass unix:/var/run/PHP5-fpm.sock;
fastcgi_split_path_info ^(.+\.PHP)(/.*)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
fastcgi_intercept_errors on;
}
相比
location ~ \..*/.*\.PHP${
return 403;
}
location ~ \.PHP {
fastcgi_pass unix:/var/run/PHP5-fpm.sock;
fastcgi_split_path_info ^(.+\.PHP)(/.*)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
fastcgi_intercept_errors on;
}
我想避免这里显示的任意代码执行：https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#passing-uncontrolled-requests-to-php
在我的简单浏览器测试域/ somedir / file.jpg / 1.PHP中,它以两种方式返回403,但我仍然不确定这是否是我需要的所有安全性.此外,如果“表现”有任何差异.
最佳答案
我个人并不喜欢你概述的方法,因为如果.PHP文件的实际URL中有一个点,你可能会误报误报.
通常有三种方法可以避免指示Nginx执行任意文件.我已经按照我的首选顺序列出了它们.
#1是配置PHP并将cgi.fix_pathinfo设置为0.这将确保即使有人传递了/uploads/avatar32.jpg/index.PHP的URL,PHP也会查找该文件,而不是试图帮助“修复“路径并执行/uploads/avatar32.jpg.如果未找到完整文件路径,则将返回错误“未指定输入文件”或“主脚本未知”,具体取决于您的PHP版本.
#2是对实际文件的存在进行Nginx测试,如果没有找到则返回404.但是,如果你使用Nginx作为PHP服务器的反向代理/负载均衡器,这将不起作用.您的PHP位置最终会如下所示：
location ~* \.PHP${
try_files $uri =404;
fastcgi_pass backend;
}
#3是黑名单方法,它利用了此漏洞仅在攻击者可以将文件上载到您的服务器时才有效的事实.因此,例如,如果您的用户上传进入/上传/然后您将拥有专门针对该位置的位置.
location /uploads {
location ~ \.PHP${return 403;}
}
