Cosa passa ancora attraverso il WAF: tecniche di bypass e come mitigarlo

La convinzione che avere un WAF equivalga ad avere un perimetro di sicurezza è una delle più costose che un team tecnico possa sostenere. I WAF operano su rappresentazioni di richieste: ricevono byte, interpretano secondo regole, decidono se il modello corrisponde a un attacco noto. Il problema è che tra l’interpretazione del WAF e l’interpretazione dell’applicazione c’è un divario. Gli aggressori consapevoli di questa lacuna la sfruttano con tecniche che esistono da più di un decennio e rimangono efficaci perché si basano sulle ambiguità dei protocolli HTTP e non su difetti specifici del prodotto.

Come la doppia codifica aggira l'ispezione del carico utile

La codifica URL è un meccanismo HTTP legittimo: ' (virgolette singole) può essere rappresentato come %27. La maggior parte dei WAF decodifica questa codifica prima di applicare le regole: comportamento corretto, poiché anche l'applicazione la decodificherà.

Il problema si presenta con la doppia codifica. La stringa %2527 viene decodificata in due passaggi: prima in %27, poi in '. Un WAF che esegue solo un ciclo di decodifica vede %27 e lo considera una rappresentazione innocua di virgolette singole. L'applicazione, durante l'elaborazione della richiesta, esegue la propria decodifica e arriva al ' che l'aggressore voleva introdurre. Il carico utile è arrivato intatto.

Le variazioni includono spazi di codifica come %09 (tabulazione invece di spazio, equivalente in molti contesti SQL) e la combinazione di codifiche maiuscole e minuscole che alcuni motori regex non normalizzano.

Cloudflare applica la normalizzazione delle richieste prima di eseguire le regole: una canonicalizzazione che annulla più livelli di codifica. Ciò mitiga la maggior parte delle tecniche di doppia codifica, ma l'efficacia dipende dalla completezza della normalizzazione applicata a ciascun campo ispezionato.

Contrabbando di richieste HTTP: quando WAF e l'origine non sono d'accordo

HTTP/1.1 consente due modi per indicare la dimensione del corpo di una richiesta: Content-Length, che specifica i byte esatti, e Transfer-Encoding: chunked, che invia il corpo in parti. Quando sono presenti due intestazioni con valori in conflitto, il comportamento non è definito dal protocollo, ma dall'implementazione di ciascun server.

Un WAF che dà la priorità a Content-Length e un server di origine che dà la priorità a Transfer-Encoding non saranno d'accordo su dove finisce una richiesta. Un utente malintenzionato che controlla questo conflitto fa sì che il WAF veda una richiesta innocua mentre il server ne vede due: la prima legittima, la seconda con contenuti dannosi che non hanno mai superato l'ispezione. Nel corso degli anni, il contrabbando di richieste HTTP ha interessato diversi WAF commerciali, richiedendo soluzioni specifiche per ciascuno di essi.

Cloudflare normalizza le richieste prima di inoltrarle all'origine. Affinché l'attacco funzioni su un'architettura Cloudflare, il server di origine dovrebbe ricevere connessioni dirette, il che ci porta alla mitigazione più importante e meno applicata.

Ciò che Cloudflare non può realmente proteggere

La logica aziendale è il caso più chiaro. Il WAF non ha contesto per la sua applicazione: non sa che un trasferimento di R$50.000 in rapida sequenza è sospetto, che si dovrebbe accedere all'endpoint /api/export solo con il ruolo admin o che discount_percentage non dovrebbe accettare valori negativi. Gli attacchi IDOR, la manipolazione dei parametri di prezzo e l'abuso dei flussi di autenticazione arrivano come richieste valide dal punto di vista WAF, perché lo sono. Questa protezione appartiene all'applicazione.

Gli zero-day sono il secondo caso. Quando viene pubblicato un CVE critico, Cloudflare ha bisogno di tempo per sviluppare una firma. Questo intervallo può durare ore o giorni e durante questo periodo l'applicazione viene esposta anche con set di regole gestite attive. Le regole WAF non sostituiscono le patch dell'applicazione.

Il bypass più semplice: accedere direttamente alla fonte

L'intero modello di protezione WAF di Cloudflare dipende da una condizione: il traffico deve passare attraverso il proxy per essere ispezionato. I record DNS in modalità solo DNS (la nuvola grigia sul dashboard) non passano attraverso il proxy. Se il sottodominio che serve l'applicazione è solo DNS, il WAF semplicemente non esiste per quel traffico.

La seconda condizione è l'IP di origine. Se un utente malintenzionato scopre il vero IP del server, può connettersi direttamente alla porta 443 con l'intestazione Host corretta e aggirare completamente il perimetro. Questo IP potrebbe essere stato esposto tramite DNS storico indicizzato da SecurityTrails prima della migrazione, log di trasparenza dei certificati TLS emessi direttamente all'IP o intestazioni di posta elettronica inviate dal server.

La mitigazione consiste nel configurare il server di origine per accettare connessioni solo dagli intervalli IP Cloudflare pubblicati in https://www.cloudflare.com/ips/. Un gruppo di sicurezza o una regola firewall che accetta solo questi intervalli elimina il contatto diretto con l'origine. Per coloro che desiderano eliminare completamente le porte aperte su Internet, Cloudflare Tunnel stabilisce una connessione in uscita dal server al perimetro senza esporre alcun IP.

Il modello di minaccia da comunicare

WAF è efficace contro una categoria specifica di aggressori: coloro che utilizzano strumenti di scansione automatizzata, non adattano i payload e cercano obiettivi deboli su larga scala. Contro scanner di vulnerabilità, script di exploit generici e bot che testano SQL injection e XSS su ogni parametro trovato, un WAF ben configurato blocca la stragrande maggioranza dei tentativi senza intervento manuale.

Contro un utente malintenzionato dedicato che studia l'applicazione, mappa gli endpoint e adatta i payload specificatamente per quello stack, la protezione è diversa. Esistono tecniche di bypass, alcune funzionano a seconda dello stato di normalizzazione e della specificità delle regole, ed è ancora possibile accedere direttamente all'origine se l'IP viene divulgato. WAF fa guadagnare tempo, riduce la superficie di attacco automatizzata e aggiunge un livello di visibilità su ciò che viene tentato, ma non sostituisce l'autenticazione forte, la convalida dell'input dell'applicazione, l'applicazione di patch alle dipendenze e il controllo granulare degli accessi a livello aziendale.