Questo codice utilizza l'uso di document.location.toString () una vulnerabilità XSS basata su DOM?

Question

Questo codice utilizza l'uso di document.location.toString () una vulnerabilità XSS basata su DOM?

#1 da (4 voti)
#2 da (1 voti)

5

Ho trovato il seguente codice JS in più applicazioni web. Penso che la ragione della popolarità di questo snippet di codice sia questa risposta accettata su SO . Gli sviluppatori sembrano utilizzare questo codice per molte schede del menu di commutazione:

var url = document.location.toString();
if (url.match('#')) {
    $('.nav-tabs a[href="#' + url.split('#')[1] + '"]').tab('show');
}

In pratica legge da document.location e passa qualsiasi cosa dopo un # a $() senza alcun sistema igienico-sanitario.

Anche lo Scanner attivo di Burp Suite lo segnala come un vero positivo.

Ho provato a sfruttarlo, ma mi sembra un falso positivo. La mia ipotesi è che dal momento che JS sta convertendo l'URL come una stringa, qualsiasi payload (inclusi i caratteri speciali) verrà considerato come una stringa.

Pubblicare questo qui solo per essere sicuro che voi ragazzi potete pensare ad altro modo per sfruttarlo per creare un XSS basato su DOM?

javascript jquery dom xss

posta Rahil Arora 24.05.2016 - 20:33

fonte

2 risposte

1

Questo era un vettore di attacco XSS piuttosto comune in jQuery e può ancora influire sui siti che utilizzano una versione obsoleta di jQuery.

link

In sostanza, se una stringa era un selettore non valido, jQuery assumerebbe che fosse HTML e lo analizza come HTML. In versione jQuery 1.9 jQuery ha mitigato questo rischio solo analizzando una stringa come HTML se è iniziato con < , quindi non dovrebbe essere possibile in jQuery moderno.

Sfortunatamente molti siti usano ancora versioni obsolete di jQuery (incluso lo Stack Exchange), che abilita il attacco semi-recente di WordPress XSS a causa di un errore in un file HTML per la libreria di icone dei font.

risposta data 24.05.2016 - 23:00

fonte

Leggi altre domande sui tag javascript jquery dom xss

Come funziona il consolidamento del percorso UNC e la firma SMB? Esiste un modo sicuro per utilizzare una chiave privata da un server condiviso?

score 4 · Accepted Answer

Questo snippet di codice è vulnerabile a XSS in jQuery precedente alla 1.9 (e in congiunzione con il plug-in jQuery Migrate). Anche ora rimane una cattiva pratica.

L'argomento stringa su $() (collegamento per jQuery() ) può essere analizzato come selettore CSS o codice HTML. L'analisi della stringa come HTML implica una vulnerabilità XSS, proprio come farebbe document.write() . D'altra parte, l'inserimento in un selettore CSS non è direttamente sfruttabile nei browser correnti.

Il changelog per la v1.9 spiega come hanno modificato l'analisi comportamento:

Prior to 1.9, a string would be considered to be an HTML string if it had HTML tags anywhere within the string. This has the potential to cause inadvertent execution of code and reject valid selector strings. As of 1.9, a string is only considered to be HTML if it starts with a less-than ("<") character. The Migrate plugin can be used to restore the pre-1.9 behavior.

Poiché la stringa dal tuo snippet ( '.nav-tabs a[href="#' + <payload> + '"]' ) non inizia con < , non sarai in grado di iniettare il tuo codice, quando la pagina sta eseguendo una versione corrente di jQuery.

Tuttavia, dovresti ancora disinfettare l'output. A volte, moduli diversi (ad esempio plug-in di Wordpress) sono dotati di una propria libreria jQuery che potrebbe inavvertitamente sovrascrivere la versione più recente e reintrodurre il comportamento precedente. Una semplice correzione sarebbe quella di rifiutare la stringa se location.hash non è alfanumerico o non è contenuto in un elenco di link predefiniti.