Listino Supporto Partner Contatti 800 13.40.41

Articoli

Icona delle News


Mutation XSS nella ricerca Google

27/03/20 CoreTech Blog

×Non sei ancora nostro cliente Acunetix? Diventa Partner CoreTech e visita il nostro configuratore prezzi

Sei sicuro che il tuo sito web sia protetto dallo  Scripting tra siti se la ricerca Google non è avvenuta per cinque mesi?

Il 26 settembre 2018, uno degli sviluppatori che lavorano alla libreria Open-source Closure (originariamente creata da Google e utilizzata in Ricerca Google) ha creato un commit che ha rimosso parte della sanificazione dell'input. Presumibilmente, questo perché hanno incontrato problemi con la progettazione dell'interfaccia utente. L'autore di questo commit e i suoi revisori non hanno notato che questa modifica ha introdotto una vulnerabilità XSS.

Nel febbraio 2019, un ricercatore di sicurezza Masato Kinugawa ha scoperto questa vulnerabilità e l’ha segnalata a Google. Google ha reagito immediatamente e la vulnerabilità è stata risolta il 22 febbraio 2019, ripristinando il commit originale che lo ha causato. L'intero caso è stato descritto in molti dettagli da un altro esperto di sicurezza, LiveOverflow.

Come è successo l'XSS?

La vulnerabilità nella libreria di chiusura era molto difficile da rilevare. Si basava su una tecnica raramente utilizzata chiamata mutazione XSS. Le vulnerabilità di mutazione XSS sono causate da differenze nel modo in cui i browser interpretano lo standard HTML.

A causa delle differenze del browser, è molto difficile sanificare l'input dell'utente sul server. Il server deve tenere conto di tutte le differenze non solo tra i browser, ma anche le loro versioni. Il modo più efficiente per sanificare l'input rispetto a XSS è quello di farlo lasciando che il browser interpreti l'input senza eseguirlo effettivamente.

Esiste un'eccellente libreria lato client per la sanificazione XSS: DOMPurify. Questa libreria viene utilizzata anche da Closure. Tuttavia, DOMPurify non è infallibile. In rari casi, è necessaria un'ulteriore sanificazione. Ed era esattamente quella sanificazione in più che è stata rimossa nel settembre 2018 con l'aggiornamento alla chiusura.

Come funziona DOMPuriy?

DOMPurify sanifica l'input dell'utente utilizzando l'elemento template. I browser elaborano la proprietà innerHtml dell'elemento div e la stessa proprietà dell'elemento template in modo diverso. Nel caso dell'elemento div innerHtml viene eseguito immediatamente dopo l'assegnazione di un valore. Nel caso dell'elemento template è possibile applicare la sanificazione prima dell'esecuzione.

L'idea alla base di DOMPurify è prendere l'input dell'utente, assegnarlo alla proprietà innerHtml dell'elemento template fare in modo che il browser lo interpreti (ma non lo esegua) e quindi sanificarsi per il potenziale XSS. Tuttavia, è la logica alla base di tale interpretazione che è la causa sottostante della mutazione XSS.

In che modo il browser interpreta il codice HTML non valido?

Per comprendere come i browser interpretano HTML non valido, crea un documento HTML con solo il contenuto seguente:

<div><script title="</div>">

Quando lo apri nel browser, vedrai che il codice viene interpretato come segue:

<html>

<head></head>

<body>

<div><script title="</div>">

</script>

</div>

</body>

</html>

A questo punto, provare a creare un documento HTML con il contenuto seguente:

<script><div title="</script>">

Il browser interpreta questo codice in modo diverso:

Banner

<html>

<head>

<script><div title="</script>

</head>

<body>

">

</body>

</html>

Questa differenza è dovuta al fatto che quando il browser rileva il tag <script> passa dal parser HTML al parser JavaScript fino a quando non viene trovato il tag di chiusura.

Il male dietro noscript

Nella maggior parte dei casi, il browser interpreterà lo stesso documento sempre nello stesso modo indipendentemente dalle circostanze. Tuttavia, c'è un caso in cui questo comportamento può essere diverso a causa di determinate circostanze lato client: il tag noscript

La specifica HTML indica che il tag noscript deve essere interpretato in modo diverso a seconda che JavaScript sia abilitato o meno nel browser. Questa differenza nel comportamento del browser è esattamente ciò che Masato Kinugawa ha usato per il suo attacco di prova di concetto XSS. Si scopre che il codice HTML non valido viene interpretato in modo diverso quando assegnato alla proprietà innerHtml dell'elemento template (come se JavaScript fosse disabilitato) e in modo diverso quando viene assegnato alla proprietà innerHtml dell'elemento div (come se JavaScript fosse abilitato).

L'attacco Proof-of-Concept

Masato Kinugawa utilizzò il seguente carico utile per eseguire l'attacco proof-of-concept:

<noscript><p title="</noscript><img src=x onerror=alert(1)>">

Se JavaScript è disabilitato (come per l'elemento template utilizzato da DOMPurify per la sanificazione XSS), il browser interpreta il payload nel modo seguente:

<noscript>

<p title="</noscript><img src=x onerror=alert(1)>"></p>

</noscript>

Il valore di "</noscript><img src=x onerror=alert(1)>" è il valore dell'argomento title Pertanto, DOMPurify non sanificare il contenuto di input perché non vi è alcun JavaScript, quindi non vi è alcun rischio XSS.

 

Tuttavia, se JavaScript è abilitato (come per l'elemento div utilizzato dal browser) il browser interpreta il payload nel modo seguente:

<noscript>

<p title="</noscript>

Banner

<img src="x" onerror="alert(1)">

"">

"

L'elemento noscript termina presto e l'elemento img viene interpretato completamente, incluso il contenuto JavaScript dell'attributo onerror

E 'impossibile dire se qualcun altro ha scoperto questa vulnerabilità prima e se è stata utilizzata per scopi dannosi. Dal momento che la libreria di chiusura viene utilizzata anche in altri prodotti Google, questa vulnerabilità potrebbe aver interessato Gmail, Mappe, Documenti e altri servizi.


Articoli su Acunetix e Hacking

DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!

Knowledge Base su Acunetix e Hacking

Il Pen Testing applicativo con Acunetix
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft