La sicurezza nella Conservazione Sostitutiva in Outsourcing – Quarta Parte

Per quanto concerne invece la sicurezza dei web server, è chiaro che sarebbe inutile elencare le numerose falle riguardanti web server quali ad esempio Apache, Tomcat ed altri. L’unica considerazione sulle possibili contromisure è quella ovvia di mantenere aggiornato il web server applicando le patch rilasciate mano mano dal produttore, oppure informarsi presso le comunità e i forum che studiano questi applicativi.
Voglio concentrarmi, invece, sui problemi di sicurezza derivanti dalla vulnerabilità della applicazioni web nel momento che vengono utilizzate tramite internet. Tratteremo di Cross-Site Scripting, SQL Injection e Cross Site Request Forgery.
Il Cross Site Scripting, XSS, è dovuto ad un errata validazione dell’input e dell’output dell’applicazione web e permette all hacker di inserire codice maligno. Questo attacco ha un elevato grado di rischio, poiché l’hacker può catturare dati sensibili degli utenti che accedono alla piattaforma. Basta una sola vulnerabilità per colpire tutti gli utenti che si collegano a quella pagina web. Chiaro comunque che a monte, un attento programmatore, dovrebbe assicurarsi che l’applicazione web non accetti caratteri che possono contenere input eseguibile, come <>, (), #, &. La stessa considerazione può essere fatta per l’output dell’applicazione, in modo tale che qualora vengono immessi caratteri speciali, essi diventano innocui per i successivi utenti che si collegano all’ applicazione. Ma il XSS, attacca anche i cookie utilizzati dai web browser. Per proteggersi, basta impostare nell’header dei cookie gestiti dall’applicazione web, l’opzione HttpOnly, evitando così che essi siano disponibili per eventuali script dannosi.

L’ Sql Injection, invece, sfrutta la vulnerabilità delle interfacce tra l’applicazione web e il database utilizzato. Queste interfacce, gestiscono le esecuzioni di un’azione presente su di un’applicazione web e per mezzo di query, interrogano il database sottostante e/o ne modificano o memorizzano i dati.
Se l’applicazione non controlla attentamente come si creano queste query, un hacker può modificarle a sua piacimento, così da poter catturare dati sensibili o distruggere un intero dabatase, anche se questo risieda dietro un firewall. Ancora una volta si può notare come il firewall, non possa proteggere l’applicazione da questo attacco.
Per documentarsi sul Sql Injection o per prendere visione di alcuni esempi, basta consultare i numerosi siti di interesse sull’argomento, cercando il termine ad esempio su Google.
Come sempre, la prima grande ed importante contromisura è quella di validare correttamente l’input dell’applicazione e verificare, tramite anche controlli automatici, la sicurezza delle query create. All’indirizzo http://www.regxlib.com, possono essere consultati ottimi esempi di corretta validazione dell’input e delle query.
Inoltre, conviene sempre utilizzare chiamate al database con procedure stored, oggetti ADO, bloccare la messaggistica verso i client ed ultimo ma non meno importante, implementare dei trigger a livello di RDBMS.
Il Cross Site Request Forgery, CSRF, invece sfrutta un concetto molto comune alle applicazioni web. Quest’ultime infatti assegnano ai propri utenti delle sessioni autenticate in modo che non debbano riautenticarsi. L’hacker può utilizzare queste sessioni per avere accesso all’applicazione con le stesse credenziali dell’utente.
Non esistono delle contromisure nette, per questi tipi di attacchi, poiché molte soluzioni dipendono esclusivamente dal framework utilizzato nella programmazione del software. Ad esempio Ruby on Rails dalla versione 2, offre protezione in modo automatico. Qualora il vostro framework non utilizzi tecnologie per proteggersi da questo attacco, allora conviene assolutamente implementare nelle applicazioni web la riautenticazione dell’utente ogni volta che quest’ultimo compia delle azioni importanti.
Voglio concludere questa terza parte, parlando di un argomento molto sentito dai professionisti IT. Ovvero il rischio del DNS. Nel 2008 un ricercatore di nome Dan Kaminsky scoprì una vulnerabilità gravissima per tutti i server DNS. Anche quelli autoritativi. Spiego meglio questo bug :
noi sappiamo che i server DNS funzionano un po’ come se fossero degli elenchi telefonici, nel quale trovare l’indirizzo di destinazione dei nostri pacchetti IP. Per ogni richiesta pervenuta, i server DNS memorizzano l’instradamento nelle cosiddette cache, dove sono memorizzati tutti gli indirizzi IP corrispondenti ai nomi di dominio che si cercano e a cui si vuole accedere.
Gli hacker, ovviamente, hanno sempre cercato di avvelenare queste cache, così da prendere il controllo di un determinato nome a dominio e instradare le richieste verso i loro siti di attacco.
Questi exploit venivano effettuati con successo, per tutti i server DNS nei quali era attiva la ricorsione, ovvero quelli non autoritativi. La minaccia riconosciuta invece da Kaminsky permette anche di attaccare i server autoritativi. Ovvero in appena pochi secondi, l’hacker instrada una richiesta per un sito fittizio al server DNS. Questo server DNS soggetto dell’attacco, cerca di trovare l’indirizzo IP contenente la richiesta. Poiché non trova risposta, chiede ad un server autoritativo la risposta corretta. Ed è qui che l’hacker, grazie ad un flusso di pacchetti falsificati, riesce a far ottenere ad un suo sito maligno ad esempio www.123falso.com, la qualifica di DNS Autority. In questo modo il server DNS bersagliato, instrada le richieste a www.123falso.com e poiché questo sito è controllato dall’ hacker, egli sarà in grado di fare : pishing, oltrepassare i moduli username/password delle applicazioni web, violare sistemi che usano certificati SSL, provocare la fuoriuscita di pacchetti TCP e UDP anche da sistemi protetti da firewall, ed altro ancora.
Insomma questo scenario è sicuramente spaventoso, poiché non si trovano delle contromisure facili da implementare, né tanto meno protezioni hardware capaci di bloccare questo attacco.