Domanda:
Cosa potrebbe fare un "
user1910744
2016-09-01 05:42:30 UTC
view on stackexchange narkive permalink

La maggior parte dei WAF quando blocca XSS bloccherà tag ovvi come script e iframe , ma non bloccano img .

Teoricamente, puoi img src = 'URL OFFSITE' , ma qual è la cosa peggiore che può succedere? So che puoi rubare IP con esso, ma è così?

Esempio di cosa significa @grochmal con le librerie di rendering: puoi attaccare alcune versioni di Windows molto vecchie senza patch con la [vulnerabilità Metafile] (https://en.wikipedia.org/wiki/Windows_Metafile_vulnerability) presente.
"" Questo invierà una richiesta GET a quel dominio, passando tutti i cookie, come le sessioni, che hai memorizzato.Se funziona, è principalmente colpa della tua banca, perché quelle azioni non dovrebbero verificarsi in una richiesta GET.
^ Non proprio perché si verificano in una richiesta GET.Più simile: perché il sito web della banca è vulnerabile agli attacchi CSRF.
Otto risposte:
#1
+112
Blender
2016-09-01 11:19:06 UTC
view on stackexchange narkive permalink

Firefox (corretto in Nightly 59.0a1), Safari (corretto in Safari Technology Preview 54), Edge e Internet Explorer visualizzano una finestra di dialogo di autenticazione se richiedi un'immagine e il server chiede di eseguire l'autenticazione con l'autenticazione HTTP di base. Ciò consente a un utente malintenzionato di visualizzare una finestra di dialogo di autenticazione quando il browser di un utente tenta di caricare l'immagine:

  • Firefox . Risolto a partire da Nightly 59.0a1, ma l'avviso presente nell'ultima versione stabile:

    Firefox displaying an "Authentication Required" dialog

  • Safari . Risolto a partire da Safari Technology Preview 54, ma il modale è ancora presente nell'ultima versione stabile. Nota che è una finestra di dialogo modale e il resto del sito Web è disattivato. "Le tue informazioni di accesso verranno inviate in modo sicuro" è anche tecnicamente vero, ma potrebbe dare a un utente disattento un'impressione sbagliata:

    Safari displaying a modal authentication dialog

  • IE11 . Una finestra di dialogo nativa di Windows blocca l'intero browser:

    IE11 displaying a native dialog

Se scegli realm una stringa molto lunga di a \ ta \ ta \ t ... a \ t , IE11 si blocca completamente.

Un nome di dominio e un regno 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.

Può essere.È un po 'nello stesso regno di qualcuno che digita erroneamente il nome di dominio e chiude comunque il server del cattivo.
Questo è chiamato attacco di phishing 401.
@Xander qualsiasi riferimento?Una semplice ricerca su Google "401 phishing attack" non restituisce alcuna buona informazione.
@HamZa Usa invece "401 phishing" (tra virgolette).Alcuni dei riferimenti più vecchi (online) sembrano essere scomparsi nel corso degli anni, ma sono rimasti ancora alcuni riferimenti più recenti.Ovviamente puoi ancora trovarlo anche nella letteratura stampata, anche se non ho un riferimento immediato.
Ho trovato questo tipo di attacco di bug / phishing sul dominio google.com e mi hanno detto che non lo considerano un bug di sicurezza.
I programmi di ricompensa dei bug di @ThomasOrlita sono notoriamente rigidi su ciò che costituisce una vulnerabilità nell'ambito.
Qualcuno può confermare se funziona ancora?Il mio IE 11 non mi chiede con il violino collegato.
#2
+88
grochmal
2016-09-02 01:12:34 UTC
view on stackexchange narkive permalink

Come Anders dice: Blender fa un ottimo punto sulle finestre di dialogo di autenticazione e multithr3at3d ha ragione sugli attributi on. Inoltre, Anders aggiunge argomenti sul tag a e Matija ha un buon collegamento sull'utilizzo delle librerie che eseguono il rendering.

Eppure, nessuno già parlato di SVG.

Prima di tutto supponiamo che tutto l'input e l'output siano adeguatamente disinfettati, quindi i trucchi con onerror / onload sono non possibile. E che non siamo interessati alla CSRF. Stiamo cercando XSS.

La prima preoccupazione di <img src = è che non segue la stessa politica di origine. Ma probabilmente è meno pericoloso di quanto sembri.

Cosa fa il browser per visualizzare un tag < img >

< img src = "http: // dominio / immagine .png "> è abbastanza sicuro perché il browser non richiama un parser (ad esempio un parser XML o HTML), sa che ciò che verrà è un'immagine (gif, jpeg, png).

Il browser eseguirà la richiesta HTTP e leggerà semplicemente il MIME di ciò che è arrivato (nell'intestazione Conetent-Type , ad esempio image / png ). Se la risposta non ha un Content-Type diversi browser indovineranno in base all'estensione, ma cercheranno solo i MIME delle immagini: image / jpeg , image / png o image / gif (tiff, bmp e ppm sono dubbi, alcuni browser potrebbero avere un supporto limitato per indovinarli). Alcuni browser potrebbero anche provare a indovinare il formato dell'immagine in base a numeri magici, ma di nuovo non cercheranno di indovinare formati esoterici.

Se il browser può corrispondere al MIME (forse indovinato) carica il rendering corretto libreria, le librerie di rendering potrebbero avere un overflow, ma questa è un'altra storia. Se il MIME non corrisponde a una libreria di rendering di immagini, l'immagine viene scartata. Se la chiamata alla libreria di rendering fallisce, anche l'immagine viene scartata.

Il browser non è mai nemmeno vicino a un contesto di esecuzione (script). La maggior parte dei browser accede al contesto di esecuzione solo dal parser javascript e può raggiungere il parser javascript solo da application / javascript MIME o da XML o HTML parser (poiché potrebbero avere script incorporati).

Per eseguire XSS abbiamo bisogno di un contesto di esecuzione. Entra in SVG.

Uso di < img src = "domain / blah / blah / tricky.svg" >

Ahi, ahi. SVG è un formato grafico vettoriale basato su XML, quindi 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 dei tag <embed> o <object> dove lo scripting è supportato dai browser. Tuttavia, non farlo per i contenuti forniti dagli utenti!

Direi che consentire SVG all'interno di <img src = potrebbe essere pericoloso:

  • Un parser XML viene utilizzato per analizzare l'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> . Tuttavia, è piuttosto brutto, è inserire un tag nella lista nera in un determinato contesto. E la blacklist è una scarsa sicurezza.

  • <script> non è l'unico modo per ottenere il contesto di esecuzione in SVG, ci sono anche onmouseover (e famiglia) eventi presenti in SVG. Anche questo è difficile da inserire nella lista nera.

  • Il parser XML nei browser ha sofferto di problemi in passato, notevoli con i commenti XML sui blocchi di script. SVG può 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 si apre diversi possibili vettori per ottenere il contesto di esecuzione. Inoltre, è una tecnologia relativamente nuova e quindi non ben consolidata. Non sarei sorpreso di vedere CVE sulla gestione di SVG. Ad esempio ImageMagick ha avuto problemi con SVG.

Questo è uno dei motivi per cui sottoscrivo "negare tutto" e poi alcuni.:) Cattura casi limite come questo.
Accettato perché questo sembra decisamente il "peggiore" che puoi fare con questo XSS.
@user1910744 - Beh, SVG è abbastanza nuovo e si evolve molto velocemente.Sebbene non sia a conoscenza di alcun CVE relativo al browser per SVG, il numero di cose che possono andare storte è così grande che deve esserci qualcosa.Se fossi riuscito a ottenere dei fondi per andare a caccia di bug nel contesto della sicurezza del browser, SVG sarebbe il primo posto in cui avrei esaminato.
Perché un parser XML dovrebbe sapere come interpretare JavaScript o come reagire agli eventi?Questa affermazione deriva dall'esperienza personale nella creazione di browser o è un'ipotesi selvaggia sull'architettura del browser interno che potrebbe o non potrebbe rivelarsi corretta?
Il tuo ultimo punto sull'attributo `xlink: href` è già coperto dalle specifiche, nessun contenuto esterno può essere caricato da un contenuto img => xlink: href in un tag` `può fare riferimento solo a risorse interne.
-1
Grazie @grochmal:.Continuo a non capire perché avrebbero bisogno di inserire i tag nella blacklist quando la maggior parte delle librerie sembra implicitamente riguardare il whitelisting (aggiungendo callback che reagiscono esplicitamente a determinati tag), anche se riutilizzano lo stesso parser XML utilizzato per XHTML (che ènon necessario, poiché per XHTML potresti volere qualcosa di più specifico).Suppongo che "funziona e basta" sono arrivate di nuovo buone pratiche di sviluppo e sicurezza se questo è il caso: x
@MatthieuM.- Intendo la lista nera perché il codice `che stiamo analizzando SVG => trovato