2012-11-08 12 views
8

Recentemente abbiamo incorporato il codice di qualcun altro che è stato testato e fallito per gli attacchi DOM XSS. Fondamentalmente i frammenti URL vengono passati direttamente in selettori di jQuery e consentire JavaScript da iniettare, in questo modo:Prevenire DOM XSS

"http://website.com/#%3Cimg%20src=x%20onerror=alert%28/XSSed/%29%3E)" 
$(".selector [thing="+window.location.hash.substr(1)+"]"); 

Il problema è che questo è effettuata in tutta loro script e avrebbe bisogno di un sacco di test di regressione per fissare esempio se sfuggiamo ai dati se le istruzioni non torneranno più vere in quanto i dati non corrisponderanno.

Il file JavaScript in questione è concatenato in fase di compilazione da molti file più piccoli, pertanto diventa ancora più difficile da risolvere.

C'è un modo per prevenire questi attacchi DOM XSS con un certo codice globale senza dover passare e eseguire il debug di ciascuna istanza.


ho proposto di aggiungere un po 'di espressione regolare nella parte superiore dello script di rilevare caratteri comuni utilizzati in attacchi XSS e di uccidere semplicemente lo script se restituisce true.

var xss = window.location.href.match(/(javascript|src|onerror|%|<|>)/g); 

if(xss != null) return; 

Questo sembra funzionare ma non sono felice al 100% con la soluzione. Qualcuno ha una soluzione migliore o qualche intuizione utile che possono offrire?

+0

Sì, sarà necessario risolvere il problema su tutti i file. Che cosa intendi con "sfuggire alle if-statement di interruzioni di dati"? E perché i selettori jQuery sono stati memorizzati negli hash degli URL? – Bergi

+0

Fondamentalmente la loro paginazione utilizza i parametri GET e il frammento di URL anche se ogni carico è un postback. Quindi consumano queste informazioni direttamente in jQuery senza analizzarle e c'è molta logica in cui if (param [0] == "str") ecc. Ecc. Per evitare questo, dovrei sfuggire a entrambi i valori. – sidonaldson

+0

Sì, dovresti usare un router corretto e dichiarare il selettore <-> – Bergi

risposta

6

Se rispettate la soluzione di espressione regolare, il che è ben lungi dall'essere ideale, ma potrebbe essere la scelta migliore dato il vostro vincoli:

Piuttosto che definire un'espressione regolare corrispondenza hash maligni (/(javascript|src|onerror|%|<|>)/g), che definirei un normale espressioni corrispondenti all'hash del suono (ad es. /^[\w_-]*$/).

Evita errori falso-positivi (ad esempio src_records), chiarisce cosa è autorizzato e cosa non lo è e blocca meccanismi di iniezione più complessi.

+2

Così vero. Fanne una whitelist invece di una lista nera! – Bergi

+0

Mi piace.Quindi crea una lista bianca di caratteri accettabili piuttosto che individuare alcune tecniche XSS. – sidonaldson

+0

L'ho modificato per corrispondere alle stringhe di ricerca e hash ... var urlSearch = window.location.search.match (/^[- \ w _ &? = +] * $ /); var urlHash = window.location.hash.match (/^[- \ w _ & = + #] * $ /); if (urlSearch == null || urlHash == null) return; – sidonaldson

0

Il problema è causato dal fatto che la stringa di input di jQuery può essere trattata come HTML, non solo come selettore.

Utilizzare nativo document.querySelector() anziché jQuery.

Se il supporto per IE7- è importante per voi, si può provare Sizzle motore di selezione che probabilmente, a differenza di jQuery e simile a nativa querySelector(), non interpreta stringa di input come qualcosa di diverso da un selettore.

+0

Questo non è un aiuto in quanto sto cercando di evitare una riscrittura. (ma dal punto di vista purista è corretto) – sidonaldson

Problemi correlati