Scrivere applicazioni PHP sicure

L'OWASP (Open Web Application Security Project) da alcune settimane ha pubblicato un interessante articolo in cui vengono indicate le cinque maggiori pecche a livello di sicurezza in PHP. OWASP, di cui ci siamo già occupati in un articolo della sezione sicurezza, è un progetto che punta a creare una serie di strumenti e documenti che facilitino la scrittura di applicazioni web sicure. Per quanto riguarda il linguaggio PHP sono stati analizzati tutti i problemi riportati nella nota mailing list dedicata alla sicurezza Bugtraq ed è stata stilata una classifica dei cinque maggiori problemi di sicurezza. In questo articolo le passeremo in analisi e vedremo come evitare queste falle nelle nostre applicazioni web. Per una visione più completa rimandiamo anche alla Guida sicurezza di PHP pubblicata nella sezione PHP del nostro network.

Preliminari: le direttive e la versione di PHP

L'articolo inizia con una breve introduzione che puntualizza due concetti fondamentali riguardo PHP: l'utilizzo di safe_mode per aumentare la sicurezza di PHP e l'utilizzo di addslashes e magic_quotes. Per quanto riguarda safe_mode (che è una direttiva che può essere impostata dal file php.ini) è bene ricordare che il suo semplice utilizzo senza nessun altro accorgimento non rende minimamente sicuro il nostro sistema. La maggior parte delle restrizioni che vengono impostate abilitando il safe_mode possono essere aggirate utilizzando script sviluppati in modo intelligente; per esempio molti software commerciali o di pubblico utilizzo hanno utilizzato hack appositi per aggirare delle protezioni della direttiva di configurazione safe_mode che avrebbero limitato il funzionamento dell'applicazione. Per quanto riguarda gli hoster dovrebbe essere fatta un po' più di attenzione allo studio del codice caricato sui server piuttosto che sperare che, abilitando safe_mode, tutto sia sicuro e ben funzionante. A parte tutto questo è bene precisare che safe_mode non è del tutto inutile: se ben strutturato ed integrato con l'applicazione può aumentare il grado di sicurezza del sistema.

Il secondo punto è legato all'utilizzo delle funzioni addslashes e le funzioni/direttive magic_quotes_*. Purtroppo, nonché sia consigliato ovunque l'utilizzo della funzione addslashes, questa non previene da una delle cause maggiori degli attacchi alle applicazioni PHP: l'SQL Injection. Per prevenirle è essenziale non utilizzare addslashes, disabilitare la direttiva magic_quotes_gpc in tutte le installazioni ed appoggiarsi a qualche libreria nativa o esterna che abbia il supporto per accessi più sicuri al database. Viene fatto riferimento alla libreria PDO, che viene fornita di default da PHP 5.1 in avanti, ma è da specificare che attualmente non è per nulla stabile; in PHP 5.2 dovrebbero risolvere tutti questi problemi.

Molto importante è il riferimento che viene fatto alla versione di PHP da installare: per prevenire la maggior parte dei problemi e dei rischi di sicurezza (in seguito spiegheremo in modo più dettagliato questa affermazione) è necessario installare PHP 5.1 o superiori. Sfortunatamente gli hoster che supportano questa versione si contano sulla punta delle dita dato che molti preferiscono rimanere attaccati alla versione 4 per problemi di incompatibilità che in realtà si trasformano in problemi di sicurezza: se un software non è compatibile con PHP 5.1 allora vuol dire che ha grossi problemi di sicurezza che comunque andrebbero corretti.

PHP 4 non è sicuro, sia per via delle impostazioni standard del file php.ini sia per il fatto che non supporta PDO ed altre interfacce di accesso alle risorse molto sicure. Oltretutto il problema dell'incompatibilità si riduce del tutto quando ci si rende conto che tutte le applicazioni commerciali o molto importanti funzionano senza alcun problema su PHP 5, ed alcune di queste (come MediaWIKI) richiedono PHP 5 per poter funzionare. Ormai sono anni che viene utilizzato. Sarebbe ora di aggiornarsi.

Passiamo ora ad analizzare i cinque maggiori rischi di sicurezza.

P1 - Esecuzione remota del codice

L'esecuzione remota di codice è il problema di sicurezza più discusso ed affrontato dalla nascita di applicazioni che sfruttano l'inclusione ed esecuzione dinamica di moduli. I problemi legati all'esecuzione remota del codice sono normalmente causati da una insufficiente validazione dell'input dell'utente require include fopen

La direttiva allow_url_fopen è abilitata di default ma, oltre a non essere utilizzata dalla maggior parte delle applicazioni, rischia di creare gravi problemi di sicurezza. Da non sottovalutare sono i permessi assegnati dagli hoster ai file ed alle cartelle di lavoro: troppo spesso capita di vedere situazioni in cui si hanno privilegi eccessivi che permettono di accedere ad una gamma troppo ampia di risorse rispetto alle esigenze. Tutte queste situazioni insieme rendono le applicazioni PHP sviluppate senza accortezza molto insicure.

Per capire se il nostro sistema è vulnerabile

Le funzioni fopen mkdir unlink system popen backtick eval imagecreateform

Per proteggersi da questo problema allow_url_fopen safe_mode open_basedir

P2 - Cross Site Scripting

Il Cross Site Scripting (conosciuto anche come HTML Injection), è quell'attacco che permette l'esecuzione di codice JavaScript  (o altro codice interpretabile dal client) non verificato e non previsto dall'applicazione oppure l'inserimento di contenuto non previsto all'interno delle proprie pagine HTML. Questo codice viene solitamente fatto eseguire aggiungendo dei tag HTML in posizioni in cui questi non erano previsti.

In PHP è possibile eseguire attacchi XSS in tre modi

Per capire se un'applicazione può essere a rischio XSS è necessario per prima cosa verificare che la direttiva register_globals sia disabilitata. In caso contrario l'applicazione avrebbe un grossissimo rischio di vulnerabilità, e sarà molto difficile operare affinché si sia sicuri che tutto funzioni a dovere. In secondo luogo bisognerebbe cercare tutte le zone in cui si visualizza direttamente l'input inserito dall'utente htmlentities

Per proteggersi da questo tipo di attacchi è dunque necessario fare affidamento a sistemi che validino e filtrino l'input, disabilitare register_globals, recuperare l'input dell'utente dalla locazione corretta anziché appoggiarsi sulla variabile $_REQUEST urlencode

Nella prima parte dell'articolo abbiamo affrontato due dei principali problemi di sicurezza legati a PHP, l'esecuzione remota di codice ed il Cross Site Scripting. In questa seconda parte analizzeremo gli ultimi tre problemi evidenziati dall'OWASP: SQL Injection, la configurazione di PHP, e gli attacchi al filesystem.

P3 - SQL Injection

L'SQL Injection è uno degli attacchi più vecchi e forse più conosciuti nell'ambito delle applicazioni web. Fortunatamente, essendo molto conosciuto e ben studiato, ci sono svariate tecniche che permettono di proteggersi e svariate librerie che svolgono da sole gran parte del lavoro di immunizzazione dal problema.

Come per tutti gli attacchi simili, è necessario validare l'input dell'utente mysql_real_escape_string

Purtroppo l'utilizzo di addslashes è insufficiente e dovrebbe essere deprecato in favore delle soluzioni esposte precedentemente; allo stesso modo magic_quotes dovrebbe essere disabilitato in modo che il codice sviluppato sia in grado di funzionare senza problemi anche su quei sistemi che hanno la direttiva disabilitata di default.

Per capire se le proprie applicazioni sono vulnerabili a questo tipo di attacchi è necessario trovare tutte quelle situazioni in cui le query SQL vengono composte partendo o utilizzando dati in input e assicurarsi che la query eseguita sia sempre sicura. Gli sviluppatori dovrebbero migrare interamente il loro codice a PHP 5.1 per poter sfruttare le librerie built-in che forniscono supporto contro le SQL Injection; se questo non è possibile ci si dovrebbe appoggiare a soluzioni esterne

I dati in input che vengono utilizzati all'interno delle query dovrebbero comunque essere validati mysql_real_escape_string

Gli hoster, dal canto loro, non possono prevenire le SQL Injection in nessun modo ma possono ridurre i problemi utilizzando PHP 5.1 e fornendo PDO ai loro clienti.

P4 - Configurazione di PHP

Anche se non è possibile considerarla come un attacco vero e proprio, la configurazione scorretta di PHP

Purtroppo però non c'è nessun tipo di configurazione

• register_globals : l'indicazione che debba assolutamente essere impostato ad off
• allow_url_fopen : come indicato nello scorso articolo, questa direttiva è attiva di default ma dovrebbe essere disabilitata per prevenire attacchi di esecuzione remota di codice;
• magic_quotes_gpc : dovrebbe essere disabilitata dato che le applicazioni dovrebbero essere progettate e sviluppate affinché si proteggano dalle SQL Injection senza l'ausilio del quoting automatico dell'input;
• magic_quotes_runtime : fortunatamente questa direttiva è impostata ad off
• safe_mode : come specificato nell'introduzione allo scorso articolo, safe_mode
• open_basedir : vale lo stesso discorso di safe_mode

Una configurazione sicura e corretta è fondamentale, e dovrebbe essere scelta anche se questo dovesse portare ad incompatibilità nel software (che andrebbe ovviamente correttamente aggiornato). Dal punto di vista degli sviluppatori quindi si dovrebbe operare in modo che le applicazioni siano portate a PHP 5 (ove necessario) e funzionino con la configurazione sicura proposta precedentemente; sarebbe anche opportuno fornire script di installazione che controllino le impostazioni del file php.ini e notifichino eventuali configurazioni errate all'utente. L'hoster dovrebbe dal canto suo aggiornare la versione di PHP alla 5.1 e configurare correttamente il file php.ini. Se possibile si dovrebbe anche lasciare la possibilità di configurare alcune opzioni di PHP attraverso file .htaccess così da lasciare ai singolo sviluppatori delle piccole libertà su quelle impostazioni che non sono considerate universalmente corrette.

P5 - Attacchi al filesystem

L'ultimo degli attacchi analizzati dal progetto OWASP è relativo agli strumenti di accesso al filesystem

Per comprendere se la nostra applicazione può essere soggetta ad attacchi di questo tipo è necessario individuare tutte le parti in cui l'input dell'utente è utilizzato come parte di nomi di file register_globals on

Per proteggersi da questo tipo di attacchi open_basedir

Conclusioni

L'articolo hoster