Produttività a portata di smartphone e di tablet hanno reso il mercato delle app molto appetibile per l’universo mondo della cybercriminalità.
Gli attacchi alle applicazioni web sono in aumento. Secondo il Data Breach Investigations Report di Verizon, hanno raddoppiato la propria frequenza tra il 2012 e il 2013, passando da meno del 20% al 40% degli incidenti registrati.
Per i professionisti della sicurezza (e in modo crescente anche dell’operatività) esistono delle best practice che contribuiscono a mantenere i rischi fuori dalla porta.
“È un problema che deve essere affrontato – spiega di Paolo Arcagni, Systems Engineer Manager Italy&Malta di F5 Networks –, perché viviamo nel mondo delle applicazioni e questo significa che aumenterà sempre più anche la frequenza con cui le nuove app web (e le API) sono esposte ai rischi.
Tra parentesi, ma non meno importante, se non si trattano le API con la stessa attenzione delle applicazioni web in termini di sicurezza si può andare incontro a situazioni decisamente spiacevoli.
Per i professionisti della sicurezza (e in modo crescente anche dell’operatività) esistono tre C rispetto alle applicazioni web che possono essere una buona base per mantenere l’idra fuori portata per le app, la rete e, naturalmente, i dati. Bisogna semplicemente ricordare tre parole: Client, Contesto e Contenuto”.
Vediamo in dettaglio le best practice delle 3C
1) Client, ovvero: la connessione
Internet of Things, BYOD e cloud sono il triangolo d’oro della proliferazione applicativa via Web. Per questo motivo, il client deve essere controllato a partire da quando avviene la connessione. Nel momento in cui un client effettua per la prima volta una connessione con l’applicazione alcuni elementi di base dell’informazione devono essere verificati. Tra questi potremmo includere il tipo di dispositivo o l’indirizzo IP e la versione dell’app stessa.
Si potrebbe anche scavare più a fondo e verificare se il client sta eseguendo il software A/V o il collegamento attraverso il percorso applicativo appropriato. La rete, la tipologia di dispositivo, l’utente e altri parametri di funzionamento se possibile devono essere verificati in questa fase. Questo approccio include sempre più l’utilizzo di feed sulle minacce alla sicurezza. I client e in modo simile gli indirizzi IP possono essere controllati rispetto a fonti conosciute di bot, malware o altri data point discutibili, per aiutare a determinare se la connessione debba continuare o meno.
I servizi antifrode, ad esempio, sono in grado di stabilire in tempo reale se un client è compromesso, permettendo ai servizi di sicurezza di determinare la linea d’azione appropriata. Se combinati con web application firewall (WAF) o con un punto di controllo strategico nel percorso di interazione critica, queste informazioni forniscono indicazioni tattiche importanti per consentire o meno la continuazione di una connessione.
2) Contest, vale a dire: la richiesta
Quando un client invia la sua prima richiesta, è il momento di iniziare a esaminare le richieste rispetto ad una vasta gamma di comportamenti potenzialmente nocivi. Questo approccio comprende la validazione dei campi di convalida degli input, URI, e header HTTP – soprattutto i cookie. È necessario controllare non solo il valore degli header HTTP previsti ma cercarne anche di nuovi che non sembrano essere utilizzati dall’applicazione.
L’utilizzo degli header trasmessi attraverso il protocollo HTTP – sia quelli standard sia quelli personalizzati – come mezzi di attacco è aumentato negli ultimi anni. Questo perché pochi intermediari e pochissime applicazioni utilizzano tutti gli header possibili, e perciò molti di essi contengono ancora vulnerabilità che sono state scoperte a causa della mancanza di utilizzo.
Lo sfruttamento di una vulnerabilità associata con un header HTTP può devastare le applicazioni perché si ripercuote sulla piattaforma dell’applicazione – il web o il server dell’app stessa. Questo comporterà attività di patching e deployment e ritardi, nell’attesa che il vendor o il proprietario della piattaforma affrontino il problema. Utilizzando un intermediario come un WAF o un proxy programmabile sarà possibile potenzialmente eliminare applicazioni con header HTTP pericolose (e non necessarie) e rendere le API utilizzabili durante questa fase.
3) Contenuto, che significa: la risposta
Un altro momento importante per mantenere alto lo stus di sicurezza è quello in cui si confronta la durata prevista e la tipologia di dati rispetto a ciò che realmente torna indietro dopo la call dell’applicazione o dell’API. In sintesi, bisogna valutare i dati sensibili rispetto al carico utile per capire se possono essere indicativi di problematiche o malfunzionamenti nel flusso in entrata, assicurandosi che la risposta attesa corrisponda alla richiesta. Ad esempio: se la richiesta riguardava informazioni sui prodotti, ha senso che la risposta contenga un mucchio di dati sui clienti? Allo stesso modo, se la richiesta riguarda i dati di un singolo cliente, la risposta non dovrebbe contenere l’elenco completo dei clienti.
È anche rispetto a questa fase che un intermediario intelligente può distinguere se il client sta subendo o meno un attacco DDoS HTTP. Attraverso la comprensione del contesto del client, gli intermediari possono valutare se le richieste stanno arrivando troppo velocemente o se le risposte vengono accettate troppo lentamente. Le deviazioni dai tassi di trasferimento previsti possono indicare che il client è coinvolto in un tentativo di consumare le risorse in modo che avvenga un’interruzione del servizio.
La frequenza con cui vengono attaccate le applicazioni web è in aumento, insieme ad altre tipologie di attacco. Per questo i responsabili della sicurezza devono rimanere vigili nel tentativo di sradicare le fonti di potenziali disastri prima che raggiungano con successo le informazioni maggiormente critiche sull’azienda e sui consumatori gestiti attraverso l’applicazione.
Uno sviluppo sicuro contribuisce molto nel percorso di prevenzione di un numero significativo di attacchi, ma non si è mai troppo prudenti. La prevalenza di attacchi zero-day e le nuove tipologie rendono, infatti, difficile per gli sviluppatori scoprire, affrontare e fissare una vulnerabilità prima che possa essere sfruttata.
Sia che si stia utilizzando la sicurezza delle applicazioni web come tappabuchi per dare agli sviluppatori (o ai vendor, nel caso di vulnerabilità legate alla piattaforma applicativa), più tempo per risolvere una criticità, sia che la si adotti come prima linea di difesa dall’ondata crescente di attacchi alle app web, seguire le tre C della sicurezza delle app web sicuramente migliorerà la propria impostazione di sicurezza e fornirà una migliore protezione complessiva del web e delle API.
