Le tre C della Web App Security

Gli attacchi alle applicazioni web sono in aumento. È 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.

CONTENUTO (LA RISPOSTA)

La risposta è l’ultima fase rispetto alla quale è ancora possibile fare dei controlli di sicurezza.

Bisogna confrontare la durata prevista e la tipologia di dati rispetto a ciò che realmente torna indietro dopo la call dell’applicazione o dell’API. Valutare i dati sensibili rispetto al carico utile per capire se possono essere indicativi di problematiche o malfunzionamenti nel flusso in entrata.

Assicurarsi 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 zeroday 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.

A cura di: PAOLO ARCAGNI, Systems Engineer Manager Italy&Malta di F5 Networks