No WAF

Il suo team di sicurezza le ha appena dipinto un quadro a tinte fosche delle minacce informatiche e lei sa bene che la sua applicazione web è un campo minato di vulnerabilità. Mettere a posto questi problemi sembra un'impresa che richiederà un tempo compreso tra l'eternità e il mai.

WAF: non proprio quello che sperava

Ma un attimo: una soluzione c'è. Si chiama Web Application Firewall e intercetta le vulnerabilità più diffuse, come gli attacchi di injection e i Distributed Denial of Service (DDoS). Senza scrivere una riga di codice. Le basta indirizzare tutto il traffico web al WAF: sarà lui a ispezionare le richieste HTTPS e a bloccare quelle pericolose.

I WAF ispezionano tutte le richieste HTTPS dirette alla sua applicazione web e bloccano quelle che appaiono pericolose. Decifrano le richieste HTTPS ed esaminano header e body alla ricerca di potenziali minacce, decidendo se bloccarle in base al contenuto, all'indirizzo IP o al pattern delle richieste.

I WAF offrono inoltre protezione contro gli attacchi DDoS, bloccando improvvisi picchi di traffico. Lo si può fare con regole semplici, come la frequenza delle richieste e l'indirizzo IP di origine. In alternativa, possono ricorrere all'intelligenza artificiale per riconoscere i pattern di accesso tipici degli attacchi DDoS e bloccarli.

Non lo faccia.

Il WAF è un errore. Vediamo perché.

Bloccare la propria app

I WAF possono impedire agli utenti legittimi di accedere alla sua applicazione web, scambiando la normale attività per un attacco. È molto probabile, infatti, che la sua web app riceva input contenenti stringhe "sospette" che le espressioni regolari intercetteranno per errore: per esempio, se la sua app è rivolta a clienti tecnici, può capitare che contenga snippet di JavaScript che assomigliano a un attacco. Peggio ancora, la sua app potrebbe richiedere input intrinsecamente pericolosi: se, per esempio, accetta HTML da un componente di rich-text editor e lo restituisce direttamente, posso dirle ciò che già sa, ovvero che dovrebbe fare l'escape delle stringhe anziché trasportare l'equivalente di un attacco. Ma rimuovere queste debolezze, una volta che ci sono, è difficile; e finché non potrà dedicarvi il suo team, il WAF renderà la sua web app inutilizzabile.

Per la protezione DDoS, il WAF blocca improvvisi aumenti di traffico, ma questo apre la porta al peggior tipo di falso positivo: quello che scatta quando la sua app diventa virale e i visitatori non riescono a usarla. È qui che il filtraggio avanzato dei WAF, basato sul machine learning (ML), può tornare utile: pur non essendo perfetto, è migliore degli approcci basati su pattern impiegati dalla maggior parte dei filtri WAF.

Bloccare singoli indirizzi IP è chiaramente troppo a grana fine, e il passo successivo è bloccare interi paesi, escludendo tutti i clienti di un'intera nazione. Magari oggi non ha clienti in quel paese, ma con il WAF si preclude anche la possibilità di scoprire potenziali nuovi mercati.

L'approccio raccomandato per gestire i falsi positivi è impostare il WAF in modalità dry run, in modo che, anziché bloccare, registri nel log gli input sospetti. Si analizzano poi i log per individuare eventuali falsi positivi e, in caso affermativo, o si allentano le regole (rischiando di lasciar passare attacchi reali) o si corregge il proprio codice (cosa che sta rimandando da anni). Ho visto organizzazioni tenere il WAF in dry run per due anni, per il timore — assolutamente legittimo — di compromettere il funzionamento della propria app. Risultato: app rallentata, nessun beneficio in termini di sicurezza e decine di migliaia di dollari spesi in licenze, senza mai ottenere alcun vantaggio reale.

Lasciar passare gli attacchi

La varietà dei possibili nuovi attacchi va oltre l'immaginazione di chi progetta i WAF e oltre la sua, ma non quella degli hacker. È così che si presenta l'immagine speculare del falso positivo: il falso negativo, ovvero attacchi reali che vengono lasciati passare.

Le espressioni regolari, il modo più comune di filtrare il testo, hanno limiti precisi in ciò che riescono a rilevare. Devono essere predefinite per attacchi specifici e restare semplici, per garantire un'elaborazione rapida. Per ragioni di velocità vengono scansionati solo i primi kilobyte di header e body HTTP; e anche alzando questo limite, ce ne sarà sempre uno oltre il quale gli attacchi passano.

Anche il blocco degli indirizzi IP è una fonte di falsi negativi, perché gli attaccanti possono passare facilmente a nuovi indirizzi sfruttando dei proxy.

La principale categoria di attacchi contro cui i WAF non possono fare nulla è poi quella che nasce dalla logica della sua applicazione. Se una pagina avrebbe dovuto essere protetta da password e non lo è, o se le autorizzazioni consentono a un utente di scrivere quando dovrebbe poter solo leggere, la responsabilità è sua. Nessuno si aspetta che un WAF rilevi vulnerabilità di questo tipo: è proprio per questo che la sicurezza web va implementata anzitutto nel proprio codice.

Flessibilità?

Mentre cerca di muoversi tra falsi positivi e falsi negativi, è forte la tentazione di mettere a punto le regole, personalizzarle in modo chirurgico sulle proprie esigenze o addirittura crearne di nuove. Non lo faccia.

Gli esperti di sicurezza hanno già studiato le tipologie di attacco usate dagli hacker. Gli hacker non inventeranno attacchi su misura per lei e, se lo facessero, non potrebbe comunque saperlo in anticipo. Le vulnerabilità della sua app sono quasi certamente le stesse coperte dai ruleset standard. Se la sua app avesse davvero debolezze così particolari da richiedere una diagnosi ad hoc e nuove regole di protezione, quel tempo di sviluppo dovrebbe dedicarlo non al cerotto, ma al miglioramento dell'app stessa.

Bilanciare precisione e recall — falsi negativi contro falsi positivi — è difficile, se non impossibile, persino per gli esperti. Per questo definiscono livelli di protezione che le permettono di scegliere il compromesso che preferisce. Cesellare quell'equilibrio rispetto a milioni di potenziali richieste web future non vale lo sforzo.

Un rischio in più

Questi limiti, di per sé, rendono in genere il WAF un saldo negativo. Ma c'è di più: il WAF stesso può rappresentare un rischio per la sicurezza. Deve decifrare l'HTTPS per ispezionare i dati, creando così un ulteriore potenziale punto di fuga; e il codice del WAF, a sua volta, può contenere vulnerabilità. Per non parlare del fatto che può rallentare le comunicazioni, dato che ogni richiesta lo attraversa.

Troppo spesso, pur consapevoli di tutto questo, i manager decidono comunque di adottare un WAF come soluzione tampone, con l'idea di risolvere le vulnerabilità più avanti. Ma una volta installato il WAF, il team si adagia, le buone pratiche di sicurezza non vengono mai adottate e il codice dell'applicazione diventa sempre meno sicuro. Il tutto mentre il WAF, in realtà, non sta offrendo la sicurezza che ci si immagina.

Nonostante questi limiti, ci sono situazioni in cui usare un WAF può avere senso, anche se non ne ricaverà comunque grande sicurezza:

Se esiste un requisito esterno che impone un WAF — se la Request for Proposals di un cliente o le normative di settore le impongono di conformarsi a uno standard formale di sicurezza — allora, naturalmente, lo aggiunga: il WAF è necessario, ma non per la sicurezza.

Se sta mettendo in produzione una web app di terze parti, che non ha sviluppato lei e che non può correggere, il WAF può essere l'unica strada per aggiungere un minimo di sicurezza. Anche in questo caso resta il rischio di adagiarsi su una percezione distorta del proprio livello reale di sicurezza, ma almeno non sta allontanando ulteriormente il suo team dalle buone pratiche di sviluppo.

Detto ciò, c'è una buona ragione di sicurezza per usare un WAF: la protezione DDoS. Quando un Denial of Service Attack genera traffico massivo, il WAF è in grado di rilevarlo e bloccarlo. Il riconoscimento dei pattern di attacco tramite ML offre una buona accuratezza.

Per una protezione DDoS più avanzata, per le web app più grandi vale la pena affidarsi a un team di esperti umani pronti a rispondere, come quelli di Google Cloud Armor Managed Protection e AWS Shield Advanced.

Molti clienti ci contattano cercando di acquistare con urgenza servizi di protezione DDoS — un WAF o un team di esperti — quando l'attacco è già iniziato e non c'è più tempo: meglio attivarli in anticipo.

Se decide di usare un WAF, scelga quello offerto dal suo cloud provider: Google Cloud Armor o AWS Shield. Con i servizi cloud paga in base al consumo, anziché vincolarsi a un costoso canone mensile per un prodotto che potrebbe non usare davvero. Inoltre, dato che i dati transitano già attraverso il cloud e, in molte architetture, i servizi cloud decifrano comunque i suoi dati, usare un WAF del suo cloud provider riduce al minimo l'impatto su prestazioni, sicurezza e privacy.

Vedi questo articolo di Mac Chaffee e questo thread su StackExchange per preziosi dettagli tecnici su questi punti.