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?
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
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
Sì, dovresti usare un router corretto e dichiarare il selettore <-> – Bergi