PHP FPM, localização aninhada vs não aninhada para evitar execução de código

Question

Existe alguma vantagem usando:

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

Em comparação com

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

Eu gostaria de evitar a execução de código arbitrário que é mostrada aqui: link

No meu teste de navegador simples domain/somedir/file.jpg/1.php , ele retorna 403 nos dois sentidos, mas ainda não tenho certeza se isso é tudo que eu preciso de segurança. Além disso, se houver alguma diferença no "desempenho".

    

Answer 1

Eu pessoalmente não sou fã da abordagem que você descreveu, pois você pode acabar com falsos positivos se houver um ponto na URL real de um arquivo .php.

Geralmente, existem três abordagens para evitar instruir o nginx a executar arquivos arbitrários. Eu os listei na minha ordem preferida.

# 1 é configurar o PHP com cgi.fix_pathinfo definido como 0. Isso fará com que, mesmo que alguém passe uma URL de /uploads/avatar32.jpg/index.php , o PHP procurará esse arquivo em vez de tentar "corrigir" o caminho e execute /uploads/avatar32.jpg . Se o caminho de arquivo completo não for encontrado, ele retornará o erro "nenhum arquivo de entrada especificado" ou "script primário desconhecido" dependendo da sua versão do PHP.

# 2 é testar nginx para a existência de um arquivo real e, se não for encontrado, retornar 404. No entanto, isso não funcionará se você estiver usando o nginx como um proxy reverso / balanceador de carga para seus servidores PHP. Sua localização no PHP acabaria parecendo:

location ~* \.php$ {
    try_files $uri =404;
    fastcgi_pass backend;
}

# 3 é a abordagem da lista negra que aproveita o fato de que essa vulnerabilidade só funciona se o invasor puder fazer o upload de arquivos para o servidor. Por exemplo, se os envios dos usuários forem enviados / uploads /, você terá um local específico para isso.

location /uploads {
    location ~ \.php$ {return 403;}
}