[section_title title=Parte 1]
A cura di Paolo Arcagni, Systems Engineer Manager Italy&Malta di F5 Networks
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.
È un problema che deve essere affrontato, 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. E non mi riferisco a quel qualcosa di “brutto” che sarà in grado di trasformarsi, come il famoso anatroccolo, in un bellissimo cigno. Parlo di una cosa simile ad un’ idra a 9 teste, insomma quel tipo di “brutto” del quale è possibile sbarazzarsi solo con azioni che hanno a che fare con il mito e la leggenda!
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.
Client (la connessione)
Il client, grazie all’Internet of Things, al BYOD e al cloud, è oggi una componente estremamente rilevante per garantire la sicurezza delle applicazioni web.
Il client deve essere controllato quando avviene la connessione, cioè quando 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.
Contesto (la richiesta)
Il punto successivo rispetto al quale valutare lo status della sicurezza è la richiesta. Quando un client verificato 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.
Per proseguire nella lettura dell’articolo vai alla pagina seguente.
