Intervista a Stefan Esser

Stefan Esser oggi, è un consulente di sicurezza informatica. àˆ diventato famoso per aver abbandonato il PHP Security Response Team a dicembre e per aver voluto il Month of PHP Bug, nel quale ogni giorno ha pubblicato un bug di PHP.

Secondo te qual è il problema principale della sicurezza in PHP?

A questa domanda è difficile rispondere. Personalmente vedo tanti problemi nel linguaggio PHP, nell'interprete PHP e nel processo di sviluppo di PHP. Tuttavia, la cosa più fastidiosa è che gli sviluppatori PHP incolpano sempre i programmatori per il loro pessimo codice ma non accettano mai il fatto che loro stessi hanno creato le funzionalità  sulle quali inciampano. Un altro grosso fastidio penso sia che, al momento, tanti programmatori PHP credono di effettuare le verifiche di sicurezza solo perché conoscono l'input filtering e l'output escaping. Almeno questo è il messaggio che php.net e altri gruppi danno. Sfortunatamente la sicurezza non è così facile.

Il Team di PHP sta spingendo verso la versione 5 e stanno abbandonando la versione 4, a livello di sicurezza cosa cambia?

Bene, da una parte è bene per la sicurezza, perché al contrario di quanto dichiarato, PHP 4 non ottiene regolari aggiornamenti di sicurezza. Per esempio, ancora non hanno riparato i riferimenti riportati durante il MOPB (Month of PHP Bugs). Qualche distribuzione come OpenSuSE ha sviluppato le proprie patch per questa vulnerabilità . Così lo switch a PHP 5 è positivo perché PHP 4 comunque non è supportato completamente. Dall'altra parte, per gli amministratori dei server il problema è che PHP 5 arriva con nuove caratteristiche che forse non sono del tutto documentate e cià può creare dei problemi. Per esempio ora è possibile ascoltare su un socket e connettersi alle porte dall'interno del core PHP. Questa è una cosa che procura qualche grattacapo.

Ora c'è un discreto numero di classi costruite che gli amministratori potrebbero non conoscere, e forse non sanno che qualche funzionalità , che al momento magari proibiscono, può essere raggiunta proprio attraverso quelle classi. Inoltre non si può usare il codice di PHP 4 in PHP 5 senza una verifica di sicurezza. Qualche funzionalità , come la deprecata magic_quotes_gpc è cambiata da PHP 4 a PHP 5 così questo codice perfettamente sicuro in PHP 4 potrebbe essere esposto ad attacchi in PHP 5. Tuttavia la cosa positiva è che qualche nuova funzionalità  (se usata), come prepared statements, renderà  più difficile scrivere codice vulnerabile al SQL injection e l'opzione allow_url_include potrebbe rendere difficile l'exploit include statements.

Qual è, parlando in termini di sicurezza, il CMS migliore tra Drupal, Joomla e WordPress?

Devo dire che non conosco il codice di Joomla. Tuttavia considero Drupal più sicuro di WordPress.

Conosci qualche altro CMS più sicuro rispetto a questi?

Al momento Hardened-PHP usa Papaya CMS pesantemente modificata. Tuttavia la ragione principale è che conosco personalmente l'autore. Ma io non sono la persona adatta per rispondere a questa domanda, perchè le mie richieste sono solitamente differenti da quelle delle persone che normalmente installano il software. Quando è possibile prendo il software che è piccolo e che fa solo le cose che richiedo così posso verificare facilmente la base del codice prima di utilizzarlo.

Esistono dei BUG in PHP che non hai mai detto al pubblico?

In PHP abbiamo ancora un numero di vulnerabilità  che non abbiamo pubblicato o neppure segnalate ancora. Sono anche parecchie vulnerabilità  che sono state riportate ma non ancora corrette.

Quali, se è possibile saperlo?

Una volta che gli sviluppatori avranno corretto cià che abbamo riportato, ci sarà  un riepilogo delle vulnerabilità . Al momento, mi spiace, ma non posso dare maggiori informazioni.