All’interno di un test di sicurezza, i ricercatori di Ethiack hanno trovato un modo per aggirare anche i firewall per applicazioni Web più severi utilizzando una tecnica insolita: l’iniezione di JavaScript tramite inquinamento dei parametri HTTP. L’oggetto del test era un’applicazione ASP.NET con le regole di filtraggio più rigide. Qualsiasi tentativo di iniettare costrutti XSS standard veniva bloccato, ma grazie alle peculiarità dell’elaborazione dei parametri duplicati, i ricercatori sono stati in grado di raccogliere un payload funzionante che il firewall non aveva nemmeno rilevato.
La chiave per aggirare il problema era che il metodo ASP.NET HttpUtility.ParseQueryString() combina parametri identici utilizzando le virgole.
Pertanto, una stringa di query come q=1’&q=alert(1)&q=’2 si trasforma nella sequenza 1′,alert(1),’2. Quando inserita in JavaScript, questa diventa jsuserInput = ‘1’,alert(1),’2; – ovvero, il codice diventa sintatticamente corretto e l’operatore virgola richiama alert. Questo comportamento consente la distribuzione di frammenti dannosi su più parametri ed evita i classici controlli di firma. Mentre ASP.NET e ASP classico combinano i valori, altre piattaforme come Golang o Python Zope funzionano con gli array, quindi la tecnica non è applicabile ovunque.
 Avvio delle iscrizioni al corso Cyber Offensive Fundamentals Vuoi smettere di guardare tutorial e iniziare a capire davvero come funziona la sicurezza informatica? La base della sicurezza informatica, al di là di norme e tecnologie, ha sempre un unico obiettivo: fermare gli attacchi dei criminali informatici. Pertanto "Pensa come un attaccante, agisci come un difensore". Ti porteremo nel mondo dell'ethical hacking e del penetration test come nessuno ha mai fatto prima. Per informazioni potete accedere alla pagina del corso oppure contattarci tramite WhatsApp al numero 379 163 8765 oppure scrivendoci alla casella di posta [email protected].
Se ti piacciono le novità e gli articoli riportati su di Red Hot Cyber, iscriviti immediatamente alla newsletter settimanale per non perdere nessun articolo. La newsletter generalmente viene inviata ai nostri lettori ad inizio settimana, indicativamente di lunedì. |
Per verificarne la robustezza, sono state testate diciassette configurazioni di diversi fornitori: AWS WAF, Google Cloud Armor, Azure WAF, open-appsec, Cloudflare, Akamai, F5, FortiWeb e NGINX App Protect.
Sono stati utilizzati quattro tipi di payload, rientranti in semplici iniezioni come q=’;alert(1) fino ad arrivare a quelle più complesse con delimitatori e bypass euristici. Solo Google Cloud Armor con ModSecurity, Azure WAF Default Rule Set 2.1 e tutti i livelli di sensibilità di open-appsec sono stati in grado di bloccare completamente tutte le varianti. Mentre le soluzioni AWS WAF, F5 e Cyber Security Cloud hanno fallito in tutti gli scenari. La percentuale complessiva di bypass è aumentata dal 17,6% per una richiesta di iniezione di base al 70,6% per l’inquinamento dei parametri avanzato.
L’hackbot autonomo utilizzato dai ricercatori è riuscito a trovare una soluzione alternativa per le soluzioni che hanno superato i test manuali. In Azure WAF, è stato possibile utilizzare l’elaborazione incoerente dei caratteri di escape tramite la sequenza test’;alert(1);//. In open-appsec, lo strumento ha trovato un’opzione funzionante in mezzo minuto anche per il profilo “critical”, variando le chiamate da alert a confirm e passando a costruzioni più ingegnose come q=’+new Function(‘a’+’lert(1)’)()+’. Per Google Cloud Armor, non è stato possibile aggirare il filtro, ma l’analisi ha mostrato che la logica del server è sensibile alle maiuscole e alle minuscole, il che potrebbe creare delle falle in futuro.
I risultati dei ricercatori di sicurezza evidenziano i limiti sistemici dei WAF basati su firme e persino quelli euristici. Il rilevamento completo degli attacchi distribuiti su più parametri richiederebbe una profonda comprensione della logica di un framework specifico e un’analisi nel contesto JavaScript , difficile da implementare a livello di proxy.
I tentativi di implementare il machine learning non garantiscono inoltre la sostenibilità, poiché i bot adattivi si adattano rapidamente e trovano pattern sicuri per se stessi.
In definitiva, i ricercatori ci ricordano che i firewall non possono essere l’unica barriera: la convalida degli input, un’adeguata schermatura e solide pratiche di sviluppo sono tutti elementi necessari. La combinazione di creatività umana e strumenti automatizzati dimostra quanto velocemente anche le vulnerabilità non standard possano essere esposte e perché i test continui rimangano imprescindibili.
Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.
Vulnerabilità
Cultura
Cyberpolitica
Cybercrime
Cybercrime