PayPal introduce le policy per le segnalazioni di vulnerabilità

Tramite Jeremiah Grossman leggo che PayPal ha pubblicato una pagina contene la “vulnerability disclosure policy“. Essa permette ai (Web application) security researchers di segnalare vulnerabilità trovate in PayPal senza rischiare azioni legali.

Ovviamente l’immunità è garantita solamente a chi rispetta la policy:

Guidelines for responsible disclosure

  • Share the security issue with us before making it public on message boards, mailing lists, and other forums.
  • Allow us reasonable time to respond to the issue before disclosing it publicly.
  • Provide full details of the security issue.

Non è tollerato, come è normale aspettarsi, l’uso della vulnerabilità per accedere a dati di cui normalmente non si possiede l’autorizzazione, pretendere una somma di denaro in cambio delle informazioni dettagliate della vulnerabilità o causare un D0S all’intero sistema PayPal.

La policy porta a porsi qualche domanda come evidenziato da Chris Shiflett, ma sicuramente le buone intenzioni ci sono e per migliorare siamo sempre in tempo. Credo che sia la prima volta che una grossa azienda mette nero su bianco un comportamento del genere per incoraggiare chiunque a segnalare preventivamente le vulnerabilità al team di competenza.
Google, Microsoft e Yahoo hanno delle policy simili, ma ancora, al contrario di PayPal, non si fa menzione di possibili rivolti legali per le vulnerabilità segnalate.

Questa notizia non dovrebbe interessare solamente agli addetti ai lavori ma anche ai semplici clienti/utenti, una grossa azienda che gestisce i nostri dati personali (o ancor peggio i nostri risparmi) non deve nascondere eventuali attacchi o vulnerabilità di sicurezza. Solitamente infatti, non solo non esiste una policy ben precisa sul comportamento che l’azienda terrà nei confronti di chi segnala una vulnerabilità ma addirittura non è ben chiaro a chi segnalare i dettagli di essa.

 

Sicurezza per chi fa sicurezza

Chi era presente all’ESC durante la presentazione di “GoogleTistic e WordPressTistic: le statistiche che nessuno avrebbe mai voluto mostrarvi” sicuramente si ricorderà come le installazioni di WordPress nella blogosfera italiana non siano sicure e ancor meno aggiornate a versioni recenti.
Ovvio che il problema non è solo sulla blogosfera italiana, ma su quella mondiale.

Può capitare, anche se non dovrebbe, che utenti non troppo esperti non aggiornino la propria piattaforma per paura che un plug-in o l’intero blog smetta di funzionare. Nessuna scusante è data però agli addetti ai lavori.
Anche se esiste il detto “Il calzolaio ha le scarpe rotte” chi si occupa di Web a tempo pieno o ancor peggio di sicurezza non si può permettere la compromissione della propria piattaforma.

Vedere blog di sicurezza informatica con versioni di WordPress di un anno fa non è una bella sensazione, figuriamoci a vederli compromessi: la scorsa settimana LightBlueTouchpaper, noto blog del Security Group dell’Università di Cambridge, ha ammesso senza troppi problemi che:

Regular readers may have noticed that Light Blue Touchpaper was down most of today. This was due to the blog being compromised through several WordPress vulnerabilities.

Ieri è successa una cosa simile, annunciata da tempo da LHM (si vedano i commenti nel suo tool per antiblogging): il blog di SecuriTeam è stato compromesso.
SecuriTeam Blog compromised

Sono stati inseriti link che portano ad un blog (WordPress 2.0.2), ospitato su un sottodominio dell’Università del Michigan, il quale a sua volta è stato compromesso ed usato per ospitare pagine che effettuano redirect verso domini di casinò on-line. Per eludere li spider che passeranno da quelle pagine è stato inserito un testo con alcune keywords e il redirect viene fatto con del codice JS offuscato.

E’ troppo facile gestire un blog pensando solo a scrivere e tralasciando la sua sicurezza in quanto, presunta, roba da ragazzini (in tutti questi casi si tratta di vulnerabilità conosciute e risolte).
Dal punto di vista degli sviluppatori non sarebbe il caso di pensare a rilasci meno frettolosi e a maggiore testing di WordPress visto il bacino di utenza che ha?
Ad ognuno le proprie conclusioni.