La maggior parte dei WAF durante il blocco di XSS bloccherà tag ovvi come script e iframe , ma non bloccano img .
In teoria, puoi img src='OFFSITE URL' , ma qual è il peggio che può succedere? So che puoi rubare IP con esso, ma è così?
Come Anders dice: Blender fa un ottimo punto sulle finestre di autenticazione, e korockinout13 ha ragione su gli attributi on. Inoltre, gli Aders aggiungono discussioni sul tag a e Matija hanno un buon link sullo sfruttamento delle librerie che fanno il rendering.
Eppure, nessuno ha ancora parlato di SVG.
Prima di tutto supponiamo che tutti gli input e gli output siano correttamente sterilizzati, quindi i trucchi con onerror / onload non sono possibili. E che non siamo interessati a CSRF. Siamo dopo XSS.
La prima preoccupazione per <img src= è che non segue la stessa politica di origine. Ma probabilmente è meno pericoloso di quanto sembri.
< img src="http://domain/image.png">èabbastanzasicuroperchéilbrowsernoninvocheràunparser(adesempiounparserXMLoHTML),sacheciòcheverràèun'immagine(gif,jpeg,png).
IlbrowsereseguiràlarichiestaHTTPeleggeràsemplicementeilMIMEdiciòcheèvenuto(nell'intestazioneConetent-Type,adesempioimage/png).SelarispostanonhaunContent-Typediversibrowserindovinerannoinbaseall'estensione,etuttaviasupporterannosoloimmaginiMIME:image/jpeg,image/pngoimage/gif(tiff,bmpeppmsonodubbi,alcunibrowserpotrebberoavereunsupportolimitatoperindovinarle).Alcunibrowserpotrebberopersinotentarediindovinareilformatodell'immaginebasatosunumerimagici,madinuovononcercherannodiindovinareiformatiesoterici.
SeilbrowserpuòcorrisponderealMIME(probabilmenteindovinato)caricalalibreriadirenderingcorretta,lelibreriedirenderingpotrebberoavereunoverflowmaquestaèun'altrastoria.SeilMIMEnoncorrispondeaunalibreriadirenderingdiimmagini,l'immaginevienescartata.Selachiamataallalibreriadirenderingfallisce,anchel'immaginevienescartata.
Ilbrowsernonèmainemmenovicinoauncontestodiesecuzione(script).Lamaggiorpartedeibrowseraccedonoalcontestodiesecuzionesolodalparserjavascriptepossonosoloraggiungereilparserjavascriptdalapplication/javascriptMIMEodaiparserXMLoHTML(poichépotrebberoaverescriptincorporati).
PereseguireXSSabbiamobisognodiuncontestodiesecuzione.EntrainSVG.
Ahi, ahi ahi. SVG è un formato grafico vettoriale basato su XML, pertanto richiama il parser XML nel browser. Inoltre SVG ha il tag <script> ! Sì, puoi incorporare javascript direttamente in SVG.
Questo non è così pericoloso come sembra all'inizio. I browser che supportano SVG all'interno dei tag <img> non supportano lo scripting all'interno del contesto . Idealmente dovresti usare SVG all'interno di <embed> o <object> tag dove lo scripting è supportato dai browser. Eppure, non farlo per i contenuti forniti dagli utenti!
Direi che consentire a SVG all'interno di <img src= può essere pericoloso:
Un parser XML viene utilizzato per analizzare SVG, sia che si trovi all'interno del tag <img> o <object> . Il parser è certamente ottimizzato con alcuni parametri per ignorare i tag <script> nel contesto <img> . Eppure, è abbastanza brutto, è mettere in blacklist un tag in un certo contesto. E la lista nera è scarsa sicurezza.
<script> non è l'unico modo per ottenere il contesto di esecuzione in SVG, ci sono anche gli eventi onmouseover (e famiglia) presenti in SVG. Questo è di nuovo difficile da inserire nella blacklist.
Il parser XML nei browser ha sofferto di problemi in passato, notevoli con i commenti XML attorno ai blocchi di script. SVG potrebbe presentare problemi simili.
SVG ha pieno supporto per gli spazi dei nomi XML. Ahi di nuovo. xlink:href è un costrutto completamente valido in SVG e il browser all'interno del contesto del parser XML probabilmente lo seguirà.
Quindi sì, SVG apre diversi vettori possibili per raggiungere il contesto di esecuzione. Inoltre, è una tecnologia relativamente nuova e quindi non ben temprata. Non sarei sorpreso di vedere CVE sulla gestione SVG. Ad esempio ImageMagick ha avuto problemi con SVG .
Firefox (corretto in Nightly 59.0a1), Safari (risolto in Safari Technology Preview 54), Edge e Internet Explorer visualizzano una finestra di autenticazione se richiedi un'immagine e il server chiede di autenticarsi con l'autenticazione di base HTTP. Ciò consente a un utente malintenzionato di visualizzare una finestra di autenticazione quando il browser di un utente tenta di caricare l'immagine:
Firefox . Risolto da Nightly 59.0a1, ma l'avviso presente nell'ultima versione stabile:
IE11.UnafinestradidialogonativadiWindowsbloccal'interobrowser:
Se rendi realm una stringa molto lunga di a\ta\ta\t...a\t , IE11 si blocca completamente.
Un dominio e un dominio ben scelti possono indurre gli utenti a inviare i loro nomi utente e password al server di un utente malintenzionato o rendere il tuo sito Web completamente inaccessibile.
<img src=http://evil.com non è un problema eccessivo, ma <img src=a onerror=alert('XSS')> può essere utilizzato per iniettare qualsiasi codice JavaScript arbitrario. Infatti, qualsiasi tag HTML combinato con qualsiasi attributo evento "on" (ad esempio onerror, onclick, onuchstart, ecc.) Può essere utilizzato per eseguire payload JavaScript illimitati.
Ok, che ne dici di questo: (Probabilmente dovresti tirarti indietro.)
<img src="file://uhoh.gif”>
Oh lo so, giusto? Che mostro!
Beh, potrebbe essere, se stai usando SMB ...
È un bug che è stato intorno per 18 ANNI! Vedi questo rapporto sulle vulnerabilità del 1997. Ecco la stessa vulnerabilità a BlackHat, nel 2015 .
Ciò riguarda Internet Explorer, incluso Microsoft Edge. Va notato che questo non ha effetto sui browser Chrome o Mozilla. IE tenta di eseguire l'autenticazione automatica sul sito Web dell'utente malintenzionato, passando il nome utente e l'hash NTLM password sul server remoto, e sì anche su Internet (!!).
Concludo quindi che assolutamente nessuno dovrebbe usare un tag IMG, mai.
Sì, ma è XSS? No, non necessariamente lancia o costituisce un attacco XSS, di cui sono a conoscenza. Sebbene possa essere lanciato da uno, non è un requisito. Il conteggio su più reti?
Penso che "img XSS" intendi "sito che consente valori arbitrari per l'attributo src="" di <img /> elementi".
... nel qual caso il rischio principale è di Cross Site Request Forgery (CSRF) in quanto significa che un utente malintenzionato può fare in modo che un target faccia una richiesta arbitraria GET , l'esempio canonico è che "il sito Web della banca mal codificato rende trasferimenti di denaro usando GET richieste "-vulnerabilità.
Tuttavia non deve necessariamente essere un Cross Site Forgery - Immagino che il principale tipo di sito che consente di fornire <img /> di elementi forniti dall'utente sia un forum web - e web- i forum tendono ad avere pannelli di controllo dell'amministratore nello stesso sito web, quindi se qualsiasi azione "utile" di amministratore o moderatore può essere invocata tramite GET, questa è un'altra possibilità, ma questo rientra ancora nell'ombrello CSRF.
La risposta di D fa notare che un GET può essere usato per emettere comandi sia croce sito e sul sito stesso . Voglio approfondire questo concetto perché dire "È una richiesta GET - stai attento" di solito non riesce a comunicare perché potrebbe essere un problema.
Un attacco che può essere fatto che altre risposte non hanno coperto è Denial of Service. Considera quanto segue:
Sei su un forum, e qualcuno pubblica un messaggio che ha una% di% di co_de incorporata - questo porta a tutti a essere disconnesso quando l'immagine viene caricata. Ora, nessuno degli utenti può utilizzare il forum, a patto che vedano quella pagina.
Questo è un esempio relativamente banale, ma ciò nonostante è un potenziale problema. Per mostrare come potrebbe essere più un problema, immagina che si tratti di una sorta di sito di notizie o altro che visualizza i commenti degli utenti sulla pagina principale e dopo il login, sei reindirizzato lì. Ora nessuno può mai accedere senza essere disconnesso immediatamente.
Fino ad ora non si tratta di attacchi cross-site. Possono essere semplicemente trasformati in quello, però - immagina se Facebook o un altro sito web popolare permette una fonte arbitraria di immagini e pubblichi il seguente <img src="/logout" /> - le persone verranno disconnesse senza nemmeno dover essere su <img src="http://yourdomain.com/logout"/>.Questopuòvariaredafastidioso("Ugh, il sito web richiede la mia password di nuovo ") a potenzialmente problematico ("Aspetta, dove è andato tutto il mio lavoro non salvato?").
È del tutto possibile che non sia nemmeno il logout a cui l'immagine è indirizzata, e se è yourdomain.com che fa sì che gli utenti "lascino" il sito Web senza il loro consenso? O forse il più plausibile http://yourdomain.com/deleteMyUser che finirà per sovraccaricare il tuo server per fare calcoli pesanti?
Ciò che trovo più irritante di questo tipo di attacco è che non è nemmeno un problema con gli stessi tag http://yourdomain.com/findPrimes?count=9001 - anche se la tua webapp è attenta con le immagini, qualcun altro potrebbe non esserlo. Il nocciolo del problema è che il link di disconnessione (o qualsiasi altra risorsa che un utente malintenzionato potrebbe sfruttare) può essere invocato solo tramite img e l'immagine è semplicemente vettoriale per far sì che i browser emettano quel GET . Il problema è che non è del tutto ovvio per molti sviluppatori che è il caso.
Oltre a ciò che tutte le altre risposte già menzionate, l'immagine stessa potrebbe essere deliberatamente modificata in modo tale che l'analisi lo sfrutta e consenta l'esecuzione di codice in modalità remota, vedi Può semplicemente decomprimere un'immagine JPEG per attivare un exploit?
Blender fa un ottimo punto sulle finestre di autenticazione e korockinout13 ha ragione sugli attributi on . Ho un'aggiunta, però.
In alcune situazioni è possibile utilizzare il controllo delle immagini per modificare il layout della pagina e fingere parti della pagina. Non è molto potente dato che non posso fare nulla di dinamico, ma a volte può essere usato in modi intelligenti.
Ad esempio, se riesco a inserire un tag img nella pagina dei risultati di ricerca cercandone uno, potrei avere un'immagine con risultati di ricerca falsi inclusi. In questo modo potrei far sembrare che una ricerca di "UFO" sulle notizie locali restituisca storie sul grande sbarco alieno del 2016.
Se la vulnerabilità si trova all'interno di un tag a che esegue un'azione, è possibile inserire un'immagine che imita altre parti della pagina. In questo modo, quando l'utente fa clic su "OK", in realtà fa clic sulla mia immagine che contiene una rappresentazione di un falso pulsante "OK", ma in realtà fa parte del collegamento "Elimina".
Se riesco a creare i miei link con le immagini in essi, questo è ancora migliore ...
Come ho detto, non è l'attacco più potente del mondo, ma è una ragione sufficiente per non permettere le immagini dove non sono necessarie.