PHP installato come CGI

Possibili attacchi

Usare il PHP come un CGI binario è un opzione per gli ambienti che per qualche motivo non vogliono integrare il PHP come un modulo nel software del server oppure vogliono usare il PHP con differenti specie di contenitori CGI per creare delle chroot sicure ed un ambiente controllato per gli script.

Questo tipo di configurazione comporta l'installazione di un binario eseguibile PHP nella directory cgi-bin del server web. Gli organismi preposti raccomandano di non porre nessun interprete nella directory cgi-bin.

Anche se il binario PHP può essere usato come un interprete stand-alone, PHP è progettato per prevenire gli attacchi che questa configurazione rende possibili:

• Accedere al system files: http://my.host/cgi-bin/php?/etc/passwd

La query nell' url dopo il punto interrogativo (?) è passata come l'argomento di un comando di shell per essere interpretato dalla interfaccia CGI.

Di solito gli interpreti aprono ed eseguono il file specificato come il primo argomento del comando di shell.

Quando il PHP è eseguito come un binario CGI si rifiuta di interpretare gli argomenti per i comandi di shell.

• Accedere a qualsiasi documento web sul server :http://my.host/cgi-bin/php/secret/doc.html

la parte informativa del path dopo il nome del binario php, /secret/doc.html convenzionalmente è usata per specificare il nome del file che deve essere aperto ed interpretato dal programma CGI. Di solito le direttive di configurazione di alcuni web server (Apache:Action) ridirigono le richieste di un documento come http://my.host/secret/script.php all'interprete PHP.

Con questa configurazione, il server web, prima controlla http://my.host/cgi-bin/php/secret/script.php i permessi di accesso alla directory /secret, dopo crea il redirect http://my.host/cgi-bin/php/secret/script.php.

Sfortunatamente, se la richiesta originale è data in questa forma, non viene effettuato nessun controllo di accesso da parte del web server sul file /secret/script.php, ma solo per il file/cgi-bin/php. In questo modo ogni utente che può accedere /cgi-bin/php accede anche ad ogni documento protetto sul sever web.

Per prevenire questo tipo di attacco occorre predisporre in fase di compilazione le direttive di configurazione --enable-force-cgi-redirect e nella configurazione runtime vanno usate le direttive doc_root e user_dir, se l'albero delle directory del server ha delle directory con restrizioni di accesso.

Vediamo ora un po' di esempi:

Caso 1 solo file pubblici

Se il vostro server non ha alcun contenuto il cui accesso sia controllato tramite password o verifica dell'indirizzo IP, non c'è necessità di questa opzione di configurazione.

Se il vostro server non consente il redirect, o il server non ha un modo di comunicare al binario PHP che la richiesta è una richiesta sicura ridiretta, voi potete specificare l'opzione --enable-force-cgi-redirect allo script di configurazione della compilazione del PHP.

Dovete però essere sicuri che i vostri script PHP non utilizzino ne l'uno ne l'altro modo di chiamare gli script, ne direttamente http://my.host/cgi-bin/php/dir/script.php ne per mezzo della redirezione http://my.host/dir/script.php.

La redirezione può essere configurata in Apache usando la direttiva AddHandler e Action

Caso 2 usare --enable-force-cgi-redirect

Questa opzione di compilazione previene che qualcuno possa chiamare il PHP direttamente con una url del tipo http://my.host/cgi-bin/php/secretdir/script.php

Invece il PHP interpreterà la url solo se è stato chiamato attraverso un redirect del server.

La configurazione in Apache per attivare la redirezione e realizzata attraverso le seguenti direttive:

Action php-script /cgi-bin/php

AddHandler php-script .php

Questa opzione è stata testata solo con il server web Apache, e conta su Apache per settare la variabile di ambiente non-standard CGI REDIRECT_STATUS sulla richiesta rediretta.

Se il vostro server non supporta nessun modo per dichiarare se una richiesta è diretta o rediretta, voi nonn potete usare questa opzione e dovete usare un altro modo per eseguire i CGI.

Caso 3 : impostare doc_root o user_dir

Includere contenuti attivi, come script ed eseguibili, nelle directory dei documenti di un web server, è considerata una pratica poco sicura.

Questo perchè, per qualche errore di configurazione, gli script possono non essere eseguiti e quindi mostrati come delle semplici pagine HTML mostrando informazioni riservate o password di accesso.

Perciò molti amministratori di sistema preferiscono prevedere un altra struttura di directory per gli script, accedibile solo attraverso PHP CGI e che verrà interpretata e non mostrata in ogni caso.

E' necessario predisporre una doc_root per gli script diversa da quella per le pagine html anche se non è possibile utilizzare il metodo redirect, come mostrato in precedenza, per gli script.

E' possibile settare la document_root per gli script PHP impostandola nel file di configurazione del PHP (php.ini) oppure impostando la variabile d'ambiente $PHP_DOCUMENT_ROOT. Se è impostata, la versione CGI del PHP costruirà sempre il nome del file della richiesta aprendo questa doc_root e le informazioni del percorso dato, così potete essere sicuri che il vostro script non sarà mai eseguito al di fuori di questa directory (con l'eccezione della user_dir che vedremo in seguito).

Un'altra opzione che è possibile usare è user_dir. Quando la user_dir non è impostata l'unico controllo sulla apertura degli script è quello della doc_root.

Aprire un url like http://my.host/~user/doc.php non apre un file nella directory home dello user, ma apre un file chiamato ~user/doc.php nella doc_root (si ha un nome di directory che inizia con la tilde [~]).

Se la user_dir è impostata per esempio a public_php, una richiesta come http://my.host/~user/doc.php aprirà un file chiamato doc.php nella directory chiamata public_php sotto la home directory dello user. Se la home dello user è /home/user, il file eseguito è /home/user/public_php/doc.php.

L'utilizzo di user_dir sembra non tener conto della impostazione di doc_root, quindi è meglio tenere il controllo sull'accesso a doc_root e user_dir separati.

Caso 4: l'interprete PHP fuori dalle directory web

Una opzione molto sicura è mettere l'interprete binario PHP da qualche parte, fuori dalle directory viste dal server web. Per esempio in /usr/local/bin. la sola controindicazione a questa opzione è che nei vostri script dovrete mettere in testa una linea di codice simile a questa

#!/usr/local/bin/php

inoltre dovrete render il file eseguibile. Insomma dovrete trattarlo come un qualsiasi altro script CGI scritto in PERL o in comandi della shell od in qualsiasi linguaggio che utilizza il meccanismo di escape della shell #! per essere lanciato.

Con questa configurazione, per far gestire correttamente al PHP le informazioni contenute in PATH_INFO ed in PATH_TRANSLATED, il PHP deve essere compilato con l'opzione –enable-discard-path.