Attivato cgi.fix_pathinfo è ancora "pericoloso" in Nginx?

3

In questo articolo in digitalocean.com Justin Ellingwood consiglia di disattivare cgi.fix_pathinfo :

Inside, we need to find a section that configures the cgi.fix_pathinfo behavior. It will be commented out and set to "1" by default. We need to uncomment this and set it to "0". This will prevent PHP from trying to execute parts of the path if the file that was passed in to process is not found. This could be used by malicious users to execute arbitrary code

Anche se IMHO Justin Ellingwood è molto bravo a scrivere documentazione, devo dire che questo intero passaggio non mi è stato chiaro.

Per occuparmene, come mi ha consigliato Justin, ho eseguito:

sed -i "s/;cgi.fix_pathinfo=1/cgi.fix_pathinfo=0/g" /etc/php/*/fpm/php.ini

L'articolo è stato scritto in aprile 2016 e potrebbe essere basato su dati un po '"vecchi". Non sono sicuro che questa raccomandazione sia ancora critica a gennaio 2018 e le configurazioni Nginx possono essere piuttosto dinamiche.

Fino ad oggi, è davvero fondamentale fare la modifica raccomandata lì?

    
posta Arcticooling 11.01.2018 - 15:46
fonte

2 risposte

2

Non descriverei questo cambiamento come "critico" di per sé, ma ha comunque implicazioni sulla sicurezza. Non sono a conoscenza di tutto ciò che è cambiato radicalmente da quando quel consiglio è diventato rilevante - il comportamento di PHP tende strongmente alla compatibilità con le versioni precedenti, anche quando questo ha implicazioni sulla sicurezza. Immagina di avere un server che consente alle persone di caricare file sul server, ad esempio in una directory chiamata upload . Ora, lo script di caricamento fa attenzione a consentire solo file con determinate estensioni (ad esempio, solo .png ) per garantire che nessuno carichi un file PHP dannoso.

Ora, come attaccante, cercherò di scrivere una shell PHP in un file, dare un nome al file evil.png e caricarlo. Quando caricherà, visiterò http://example.com/upload/evil.png , ma scoprirò che questo mi scarica solo il file - nginx non ha mai inviato la richiesta a php-fcgi per essere elaborata come php, perché il nome del file termina in .png .

Se sono un utente malintenzionato a conoscenza di PATH_INFO , successivamente proverò http://example.com/upload/evil.png/index.php . Se il tuo server è configurato in questo modo, verrà eseguito PHP (perché nginx vede il index.php alla fine) e PHP percorrerà il percorso fino a trovare un componente che è un file, non una directory ( evil.png ) e tenta di eseguirlo. Poi il mio guscio viene eseguito e io vinco.

Detto questo, ci sono modi migliori per affrontare questo problema avendo la configurazione NGINX dividere il percorso in anticipo, quindi PHP non sta camminando sul filesystem.

Dall'eccellente post di blog sul problema :

# 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;
}
    
risposta data 11.01.2018 - 17:58
fonte
2

Anche ora sembra portare pericolo a causa del modo in cui PHP sta ancora elaborando lo script dalla prima occorrenza del file trovato. Quindi, perché hanno mantenuto il valore predefinito come ;cgi.fix_pathinfo=1 quindi?

Perché CGI è indipendente da PHP e ha un proprio standard. CGI (Common Gateway Interface) è un'interfaccia che indica al server come comunicare i dati con le applicazioni, come vengono trasmesse le informazioni sulla richiesta e il corpo, dall'input all'output. I server del Web possono essere configurati per eseguire un programma come CGI , il che significa che inoltreranno i dati della richiesta a un programma specifico. Ed è così che NGinx passa la richiesta a PHP.

Parlando di Standard CGI , gli sviluppatori di PHP-FPM devono rispettare lo standard CGI come indicato nel file PHP-FPM ini ex: /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

Quindi suppongo che il testo 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. spieghi la scelta. Ecco la % CGI Spec <% della CGI .

    
risposta data 28.11.2018 - 19:39
fonte

Leggi altre domande sui tag