Perché questo attacco XSS non funziona?

Question

Perché questo attacco XSS non funziona?

#1 da (3 voti)
#2 da (1 voti)

1

Ho un sito con il seguente javascript in esecuzione:

var t=location.hash.slice(1);
$("div[id="+t+"]").text("The DOM is now loaded and can be manipulated.");

Stavo pensando che se ho aggiunto il seguente all'URL:

#message]");alert('test');//

Che eseguirà il seguente javascript:

$("div[id=message]");alert('test');//]").text("The DOM is now loaded and can be manipulated.");

Ma quando viene eseguita la console viene stampato l'errore:

Syntax error, unrecognized expression: div[id=message]");alert('test');//]

Ho sbagliato a pensare che il mio input avrebbe generato il javascript che include alert ? Se è così, c'è qualche attacco XSS basato su DOM nelle prime due righe che ho postato?

dom xss

posta Abe Miessler 18.09.2014 - 23:37

fonte

2 risposte

1

La stringa t non è eval 'd , è una stringa letterale. La concatenazione di stringhe crea solo una nuova stringa, hai una situazione simile a un semplice var y = 'Hash: ' + location.hash.slice(1); che non apre un vettore XSS. Assegna semplicemente l'hash a una variabile in Javascript.

Il risultato funziona come:

$("div[id=#message]\");alert('test');//]").text("The DOM is now loaded and can be manipulated.");

Tieni presente che sono sfuggito al " , perché questo si traduce in un carattere% letterale% di carattere nella stringa, non nel codice sorgente JavaScript. Potresti usarlo come attacco se il codice fosse:

var t=location.hash.slice(1);
eval('$("div[id="'+t+'"]").text("The DOM is now loaded and can be manipulated.");');

che è (un motivo) perché l'uso di " è spesso scoraggiato in Javascript.

risposta data 19.09.2014 - 02:10

fonte

Leggi altre domande sui tag dom xss

Affidarsi all'elenco delle autorità di certificazione di openssl o fornire il mio Quali sono le principali differenze tra Analisi del codice sorgente e Static Application Security Test (SAST)?

score 3 · Accepted Answer

$("div[id="+t+"]")

Questa non è un'iniezione JavaScript. Affinché sia JS injection, il valore fornito dall'attaccante dovrebbe essere scritto in il codice JavaScript dall'esterno (ad esempio in un linguaggio di template sul lato server o eval nello stesso JS). Non sta succedendo qui, non c'è JavaScript generato dinamicamente. C'è solo una semplice concatenazione di stringhe fatte all'interno di JavaScript.

Non è un'iniezione HTML sul lato client. Affinché sia HTML injection, ci dovrebbe essere contenuto di markup degli attacker scritto sul DOM. Non c'è qui, solo la stringa statica The DOM is now loaded and can be manipulated. che viene scritta usando il metodo sicuro text() che non consente il markup.

Si è verificato un problema di iniezione qui, ma è solo Selector Injection. La variabile di stringa JS t viene copiata in un valore di attributo del selettore CSS in runtime JS. I caratteri speciali qui includono ] (che termina il valore dell'attributo) e backslash (che introduce gli escape CSS).

Questa è ancora una brutta cosa, ma la cosa peggiore che puoi fare con un'iniezione di selettore è fare in modo che l'applicazione selezioni l'elemento sbagliato, ad esempio:

http://victim.example.com/page#x],body,div[id=x

come risultato del selettore

div[id=x],body,div[id=x]

che, a causa del riferimento a <body> , sostituisce l'intera pagina con il testo The DOM is now loaded and can be manipulated.

Le iniezioni di selettori normalmente non portano a DOM XSS. È ipotizzabile che si possa scegliere come target un elemento che l'applicazione è quindi affidabile per eseguire come codice, ad esempio <script type="text/template"> . Ma quando non hai il controllo della stringa The DOM is now loaded and can be manipulated. allora non c'è sfruttamento che puoi fare, solo fastidio.

Puoi correggere l'iniezione del selettore di \xxx -escaping caratteri in t che sono speciali in CSS. Meglio, dove possibile, è quello di evitare le stringhe del selettore e i loro problemi di fuga andando direttamente all'ID dell'elemento:

$(document.getElementById(t))  // works for any character in t

Tuttavia in questo caso non sembra valsa la pena poiché gli attacchi che si possono fare con l'iniezione di selettori non sono affatto peggiori della funzionalità intenzionale di consentire a un attacco di sostituire qualsiasi div con il testo.