
Redazione RHC : 9 Settembre 2025 07:50
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.
Christmas Sale -40% 𝗖𝗵𝗿𝗶𝘀𝘁𝗺𝗮𝘀 𝗦𝗮𝗹𝗲! Sconto del 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮 del Corso "Dark Web & Cyber Threat Intelligence" in modalità E-Learning sulla nostra Academy!🚀
Fino al 𝟯𝟭 𝗱𝗶 𝗗𝗶𝗰𝗲𝗺𝗯𝗿𝗲, prezzi pazzi alla Red Hot Cyber Academy. 𝗧𝘂𝘁𝘁𝗶 𝗶 𝗰𝗼𝗿𝘀𝗶 𝘀𝗰𝗼𝗻𝘁𝗮𝘁𝗶 𝗱𝗲𝗹 𝟰𝟬% 𝘀𝘂𝗹 𝗽𝗿𝗲𝘇𝘇𝗼 𝗱𝗶 𝗰𝗼𝗽𝗲𝗿𝘁𝗶𝗻𝗮.
Per beneficiare della promo sconto Christmas Sale, scrivici ad [email protected] o contattaci su Whatsapp al numero di telefono: 379 163 8765.
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.
Redazione
Un nuovo allarme arriva dal sottobosco del cybercrime arriva poche ore fa. A segnalarlo l’azienda ParagonSec, società specializzata nel monitoraggio delle attività delle cyber gang e dei marketpla...

Cisco Talos ha identificato una nuova campagna ransomware chiamata DeadLock: gli aggressori sfruttano un driver antivirus Baidu vulnerabile (CVE-2024-51324) per disabilitare i sistemi EDR tramite la t...

Quanto avevamo scritto nell’articolo “Codice Patriottico: da DDoSia e NoName057(16) al CISM, l’algoritmo che plasma la gioventù per Putin” su Red Hot Cyber il 23 luglio scorso trova oggi pien...

Notepad++ è spesso preso di mira da malintenzionati perché il software è popolare e ampiamente utilizzato. Una vulnerabilità recentemente scoperta nell’editor di testo e codice open source Notep...

Una vulnerabilità critica associata all’esecuzione di codice remoto (RCE) in Outlook è stata sanata da Microsoft, potenzialmente consentendo a malintenzionati di attivare codice dannoso su sistemi...