No describiría este cambio como "crítico" per se, pero aún tiene implicaciones de seguridad. No estoy al tanto de nada que haya cambiado fundamentalmente desde que ese consejo se volvió relevante:el comportamiento de PHP tiende fuertemente hacia la compatibilidad con versiones anteriores, incluso cuando eso tiene implicaciones de seguridad. Imagina que tienes un servidor que permite a las personas subir archivos al servidor, digamos en un directorio llamado upload . Ahora, su secuencia de comandos de carga tiene cuidado de permitir solo archivos con ciertas extensiones (digamos solo .png ) para asegurarse de que nadie cargue un archivo PHP malicioso.
Ahora, como atacante, intentaré escribir un shell de PHP en un archivo, nombrar el archivo evil.png y cárguelo. Cuando se cargue, visitaré http://example.com/upload/evil.png , pero descubriré que esto solo me descarga el archivo:nginx nunca envió la solicitud a php-fcgi para que se procesara como php, porque el nombre del archivo termina en .png .
Si soy un atacante que conoce PATH_INFO , a continuación intentaré http://example.com/upload/evil.png/index.php . Si su servidor está así configurado, esto resultará en la ejecución de PHP (porque nginx ve el index.php al final) y PHP recorrerá el camino hasta que encuentre un componente que sea un archivo, no un directorio (evil.png ) e intente ejecutarlo. Entonces mi caparazón se ejecuta y yo gano.
Dicho esto, hay mejores maneras de lidiar con esto haciendo que la configuración de NGINX divida la ruta por adelantado, para que PHP no esté recorriendo el sistema de archivos.
De la excelente entrada de blog de Neal Poole sobre el tema:
# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
# Zero-day exploit defense.
# http://forum.nginx.org/read.php?2,88845,page=3
# Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine. And then cross your fingers that you won't get hacked.
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php;
}
Incluso ahora parece ser peligroso debido a que PHP todavía está procesando el script desde la primera aparición del archivo encontrado. Entonces, ¿por qué mantuvieron el valor predeterminado como ;cgi.fix_pathinfo=1? entonces?
Porque CGI es independiente de PHP y tiene su propio estándar. CGI (Common Gateway Interface) es una interfaz que instruye al servidor sobre cómo comunicar datos con aplicaciones, cómo se pasa la información y el cuerpo de la solicitud, desde la entrada hasta la salida. Se pueden configurar servidores de Web para ejecutar un programa como CGI , lo que significa que reenviarán los datos de la solicitud a un programa específico. Y así es como NGinx pasa la solicitud a PHP.
Hablando de Estándar CGI , PHP-FPM los desarrolladores deben cumplir con el estándar CGI como se indica en el PHP-FPM archivo ini ej:/etc/php/7.2/fpm/php.ini :
; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok
; what PATH_INFO is. For more information on PATH_INFO, see the cgi specs. Setting
; this to 1 will cause PHP CGI to fix its paths to conform to the spec. A setting
; of zero causes PHP to behave as before. Default is 1. You should fix your scripts
; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.
; http://php.net/cgi.fix-pathinfo
;cgi.fix_pathinfo=1
Así que supongo que el texto Setting this to 1 will cause PHP CGI to fix its paths to conform to the spec. A setting of zero causes PHP to behave as before. explica la elección. Aquí está el PATH_INFO Especificaciones CGI