Alcuni di voi potrebbero avere familiarità con questo attacco chiamato XSS autonomo. Di recente mi sono imbattuto in questo articolo a riguardo. Quindi, quanto può essere pericoloso questo tipo di attacco, anche se questo non ha accesso agli attuali elementi DOM? Qualcuno ha visto questo in natura?
Questo influisce anche sui browser mobili?
Un altro utile link .
L'XSS autonomo è pessimo quanto lo XSS stesso. È solo uno dei modi per fornire il carico utile. I link nella tua domanda descrivono due diversi vettori:
<iframe> con src di data:text/html,<html><script>alert(/xss/)</script></html> , ma ci sono molti, molti altri modi su come utilizzare gli URL di dati per XSS. Puoi guardare alcuni di essi cercando data: al foglio di sicurezza HTML5
È stato usato in natura? Sì, ad esempio l'ho usato per sfruttare una vulnerabilità Piwik XSS
with(location)with(hash)eval(substring(1)) ma ci sono molti vettori simili. Quindi, per riassumere - l'XSS autonomo non è ancora un altro tipo XSS (come XSS memorizzato o XSS basato su DOM), sono solo modi di assomigliare al payload. Non puoi davvero dire che è più pericoloso dello stesso XSS.
Questo è in realtà un vecchio problema. Puoi codificare qualsiasi tipo di supporto utilizzando l'URI data . È abbastanza comune utilizzarlo per incorporare immagini in un singolo file di markup.
<img src="data:image/png;base64,ABCdefghIjKlmNoPqrSTuvwxyZ01d" />
Il motivo per cui questo è pericoloso è che qualsiasi attacco XSS potrebbe consentire a un utente malintenzionato di incorporare un URI data . Se l'utente lo scarica, potrebbe accedere a qualsiasi tipo di file. Quel che è peggio, è un modo per incorporare dati che possono sfruttare altre vulnerabilità nei browser o nei componenti di rendering sottostanti, da un sito che l'utente si fida.
Ad esempio, immagina che Bob's Crazy Discount Spoons abbia avuto un attacco XSS in cui è possibile manipolare src di un'immagine:
http://bobscrazydiscountspoons.com/foo/bar.php?xss=data:image/png;base64,ABCdefghIjKlmNoPqrSTuvwxyZ01d
L'utente ora ha un payload sgradevole che sfrutta una vulnerabilità nel suo renderizzatore PNG del browser, invece di quei pazzi cucchiaini di sconto che desiderava.
Ovviamente ciò non è limitato alle immagini. Può essere utilizzato in qualsiasi posto in cui è possibile iniettare nella sorgente o nel collegamento di un oggetto. Lo stesso vale per essere in grado di iniettare questo tipo di dati in attacchi di iniezione HTML completi.
So how bad this kind of attack can be, even though this doesn't have access to the current DOM elements?
È peggio degli esempi piuttosto limitati nell'articolo collegato: in Firefox e Opera, data: URI do operano nello stesso contesto di sicurezza del documento che li include, quindi puoi accedere agli elementi DOM nel tuo dominio. Questo non succede in Chrome / Safari o IE9 (che ha deliberatamente solo un supporto parziale per gli% URI di% co_de).
Nel caso in cui è possibile includere documenti HTML, questo offre tutti gli stessi rischi del tradizionale XSS. Sono principalmente frame e link, ma sono possibili altri attacchi (*).
esempio: link - crea un collegamento e un iframe, inserendo il documento HTML digitato nei dati: URL in entrambi. Il codice nel documento collegato / incorniciato riprende il contesto di sicurezza di jsbin.com, permettendogli di avvisare il codice sorgente della pagina indice jsbin.
Di conseguenza, dovresti considerare% URI di% co_de per essere altrettanto rischioso degli% URI didata:, e disabilitarli ovunque la tua webapp consenta di inviare URI. (In realtà, la whitelisting degli schemi di URI di buona reputazione per attenersi a una selezione limitata come data: / javascript: è la migliore.)
(*: Ad esempio: metti un URI http attaccato da un utente malintenzionato in https e l'immagine non funzionerà, ma se l'utente può essere duplicato in immagine-clic-clic-destro, carica la risorsa come HTML, risultante in XSS.)
Leggi altre domande sui tag javascript web-application attacks xss