Problema de segurança no Nginx, PHP & fastcgi_split_path_info

Question

De acordo com esta postagem , foi dito que se eu estou usando PHP / Nginx, para melhor segurança, eu deveria

cgi.fix_pathinfo = 0

ou

if ( $fastcgi_script_name ~ \..*\/.*php ) {
  return 403;
}

Em outro tutorial , é recomendado o estilo

fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;

Eles são contraditórios entre si? Alguma recomendação de segurança?

Obrigado.

    

Answer 1

Você está se referindo a um problema em que um invasor pode fazer upload de código arbitrário para um servidor da Web nginx e então engane o servidor para executá-lo como PHP . (Nenhum CVE existe para este problema, pois é tecnicamente uma configuração incorreta, em vez de uma vulnerabilidade.)

Qualquer um dos métodos listados pode ser usado para remediar o problema .

Outra maneira mais simples de corrigir esse problema é adicionar o seguinte em seu PHP location :

try_files $uri =404;

Embora isso funcione apenas se o nginx e o PHP estiverem sendo executados no mesmo servidor, o que é quase sempre verdadeiro.

A recomendação, é claro, é que você documente claramente o que está fazendo e por quê.

    

Answer 2

Em versões recentes do php, isso não é mais um problema:

Do arquivo /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

    

Answer 3

No Ubuntu 16.04 LTS Server, depois de instalar nginx usando o gerenciador de pacotes, o exemplo PHP location in /etc/nginx/sites-available/default inclui snippets/fastcgi-php.conf . Este é o conteúdo desse arquivo:

# 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;

Parece que o problema é mitigado usando fastcgi_split_path_info para obter $fastcgi_script_name e $fastcgi_path_info . Então try_files é usado para procurar por $fastcgi_script_name . Se o arquivo PHP não existir, será retornado um 404 Not Found .

Eu ficaria curioso em saber se essa solução é implementada por outras distribuições.