Vettori XSS in img src e background-image url

Naviga le tue risposte
3

Sono un po 'confuso sulle vulnerabilità XSS quando servo img.src e l'URL di sfondo. Da quello che ho capito, l'unico modo per eseguire javascript in questo caso è utilizzare il protocollo javascript. Consideriamo questo esempio: 

if (location.hash.indexOf('javascript:') !== 0) {
    img.style.backgroundImage='url("'+location.hash+'")';
 }
 img.src='some/local/path/'+location.hash;

Esiste una vulnerabilità XSS in questo codice?

    
posta Maciej Krawczyk 01.06.2016 - 20:33
fonte

2 risposte

5

No , nei browser moderni non è possibile XSS tramite l'attributo style o src di un tag <img> .

Quindi nessuno di questi eseguirà il codice JS in qualsiasi browser aggiornato: 

<img src="javascript:alert(1)">
<img src="x.jpg" style=background-image:url('javascript:alert(2)')">

Il supporto per Javascript negli attributi CSS ha a lungo abbandonato . Puoi trovare alcuni vecchi riferimenti a riguardo qui .

Analisi del tuo codice di esempio

location.hash inizia sempre con un simbolo # . Poiché questo carattere è illegale in JS e non è un inizio valido di un nuovo URL, non sarebbe possibile alcun XSS in primo luogo. (Ad esempio, eval(location.hash) produce sempre un errore di sintassi.)

Supponiamo che tu ignori # e location.hash possa davvero contenere qualsiasi stringa tu voglia.

Quindi questo controllo di sicurezza è difettoso: 

(location.hash.indexOf('javascript:') !== 0)

Un utente malintenzionato potrebbe ancora costruire un URL che inizia con JaVaScRiPt: . Inoltre, è rischioso presumere che nessuna implementazione possa mai consentire spazi iniziali o caratteri di controllo (ad esempio \t\x00javascript: ). E la codifica dell'URL? Un payload che inizia con javascript%3a passerebbe il tuo filtro. Inoltre, vuoi consentire il protocollo data: ? Se desideri limitare l'URL alle posizioni assolute, puoi autorizzare gli inizi http:// e https:// invece di mettere in black list javascript: .

Questo va bene: 

img.src='some/local/path/'+location.hash;

Anche se l'attributo src era suscettibile al codice di script, il prefisso some/local/path/ garantisce che non possa essere trasformato in un URL JS. Tuttavia, un utente malintenzionato potrebbe specificare qualsiasi percorso relativo a un file immagine sullo stesso server, che potrebbe risultare indesiderato.

NB: Si tratta della costruzione di URL javascript: dannosi. Se desideri utilizzare valori controllati dall'utente come location.hash per l'output HTML o un contesto diverso, devi disinfettare correttamente la stringa.

    
risposta data 01.06.2016 - 22:25
fonte
1

Sì, è un problema, forse anche un grosso problema, ma "XSS" probabilmente non è il termine giusto.

Che cosa potrebbe andare storto?

  1. esecuzione di codice in modalità remota usando svg, in particolare i browser più vecchi
  2. le immagini fuori sede perdono l'indirizzo IP dell'utente (aka lat / lon), userAgent e le prestazioni nette
  3. le immagini dannose sono state vettori, un sacco di 0 giorni nel passato
  4. Una GIF speciale o anche solo una grossa e grossa porca può portare la pagina / CPU a macinare
  5. le immagini di grandi dimensioni possono essere utilizzate per iniettare molti dati noti per aiutare a rompere la crittografia
  6. il tuo sito potrebbe "pubblicizzare" qualcosa a cui non vuoi essere associato
  7. un'immagine fuori sito può confermare che un utente specifico ha ricevuto un link specifico e visitato

Mentre nessuno di questi è tradizionale XSS, sono bummers.

Vorrei raccomandare una sorta di scelta tra una lista bianca di immagini sul sito se si desidera funzionalità di personalizzazione.

    
risposta data 02.06.2016 - 03:53
fonte

Leggi altre domande sui tag

Proteggere me stesso in Ucraina L'accesso pubblico a specifici nomi di file e tipi deve essere negato preventivamente?