Nginx，PHP和fastcgi_split_path_info上的安全问题

您指的是攻击者可以将任意代码上传到nginx Web服务器，然后欺骗服务器以PHP身份执行的问题 。 （这个问题没有CVE存在，因为它在技术上是错误configuration而不是漏洞。）

您列出的任何方法均可用于修复问题 。

解决这个问题的另一个更简单的方法是将以下内容添加到您的PHP location ：

 try_files $uri =404; 

虽然这只有在nginx和PHP运行在同一台服务器上时才有效，这几乎总是正确的。

当然，这个build议是你清楚地logging你在做什么，为什么。

在最近的PHP版本中，这不再是一个问题：

从文件/etc/php-fpm.d/www.conf：

 ; Limits the extensions of the main script FPM will allow to parse. This can ; prevent configuration mistakes on the web server side. You should only limit ; FPM to .php extensions to prevent malicious users to use other extensions to ; exectute php code. ; Note: set an empty value to allow all extensions. ; Default Value: .php ;security.limit_extensions = .php .php3 .php4 .php5 

在Ubuntu 16.04 LTS Server上，使用软件包pipe理器安装nginx后， /etc/nginx/sites-available/default的示例PHP location包含snippets/fastcgi-php.conf 。 这是该文件的内容：

 # regex to split $uri to $fastcgi_script_name and $fastcgi_path fastcgi_split_path_info ^(.+\.php)(/.+)$; # Check that the PHP script exists before passing it try_files $fastcgi_script_name =404; # Bypass the fact that try_files resets $fastcgi_path_info # see: http://trac.nginx.org/nginx/ticket/321 set $path_info $fastcgi_path_info; fastcgi_param PATH_INFO $path_info; fastcgi_index index.php; include fastcgi.conf; 

看来，通过使用fastcgi_split_path_info来获取$fastcgi_script_name和$fastcgi_path_info可以缓解这个问题。 然后使用try_files来查找$fastcgi_script_name 。 如果PHP文件不存在，则返回404 Not Found 。

我很想知道这个解决scheme是否由其他发行版本实现。