it-swarm-eu.dev

Vulnerabilità del tag IMG

È sicuro visualizzare immagini da domini arbitrari? Cioè diciamo che ho un'immagine sulla mia pagina:

<img src="http://badguy.com/image.gif" />

Cosa succede se image.gif Restituirà un vettore di attacco js, ​​ma non l'immagine? C'è qualche vettore noto?

Ho provato a servire javascript:alert(1) o lo stesso, ma con codifica base64. Ma senza fortuna. Qualche idea?

54
Paul Podlipensky

C'era una "vulnerabilità" in cui l'immagine poteva inviare un HTTP 401 Unauthenticated response, che attiva una schermata di accesso per l'utente. Se lo imposti come avatar del forum, genererebbe un popup di accesso per chiunque visiti una pagina in cui appare il tuo avatar. Molte persone tenteranno quindi di accedere con una combinazione di nome utente e password, probabilmente quella per l'account del forum.

Un mio amico l'ha scoperto qualche anno fa, ma al giorno d'oggi non sembra più funzionare. Almeno non sono riuscito a riprodurlo facilmente qualche mese fa. Modifica: ho sbagliato, questo attacco è ancora possibile!/Modifica

Per quanto riguarda gli attacchi XSS in questo modo, sei al sicuro. Il browser interpreterà o dovrebbe sempre interpretarlo come un'immagine, indipendentemente dal contenuto o dalle intestazioni che invia. Puoi personalizzare l'immagine in base alla richiesta (fornendo una piccola immagine al software del forum controllando di nuovo l'immagine in modo che non la ridimensioni, quindi grande per tutti gli altri). Oppure dai al browser molti dati gif fino a quando la memoria si esaurisce o qualcosa del genere. Ma non ci sono vere e proprie grandi vulnerabilità qui che consentono l'esecuzione di codice in modalità remota, per quanto ne so.

Quello che sei solo moderatamente sicuro sono gli attacchi CSRF. L'immagine può emettere un HTTP 302 Moved Temporarily risposta e collegamento a una nuova posizione. Ad esempio, potrebbe essere collegato a, non ricordo l'URL specifico, qualcosa come https://accounts.google.com/logout e disconnettersi da google (ha funzionato qualche mese fa). Oppure, leggermente più maliziosamente: http://example.com/guestbook.php?action=post&message=spam-url.example.com.

Solo le richieste GET possono essere fatte in questo modo, per quanto ne so. O se l'immagine fosse originariamente caricata come POST, suppongo che potrebbe anche reindirizzare il POST, ma non modificare i dati POST. Quindi è abbastanza sicuro.

Ultimo ma non meno importante, se l'attaccante controlla gli URL di, ad esempio, avatar del forum (come nei forum SMF), è possibile ottenere informazioni dai visitatori come il loro indirizzo IP. Ho scritto uno strumento qualche tempo fa che utilizzava il action=who pagina di SMF per collegare gli indirizzi IP ai nomi utente. Quando ho iniziato a mostrarlo agli utenti (mostra "Ciao $ nome utente con IP: $ IP" nell'immagine) si è scatenato l'inferno. "Come hai potuto saperlo?!" Erano per lo più dei primi anni dell'adolescenza, quindi sapevano qual era un indirizzo IP, ma non lo sapevano Non so che non potrei hackerarli con esso. È comunque considerata un'informazione di identificazione personale, almeno nei Paesi Bassi, quindi gli amministratori non erano abbastanza contenti di questa pratica. Se non lo visualizzi, nessuno lo saprà mai.

Nota: se questo post sembra scritto in fretta, lo è. Anch'io sono appena sveglio. Forse lo ripulirò domani se è troppa narrazione e non nomina abbastanza fatti concreti e vulnerabilità. Spero che questo abbia aiutato comunque!

54
Luc

Il tag IMG tenterà di interpretare i dati come un'immagine, quindi Javascript non verrà eseguito.

Sarà possibile inviare un'immagine che, una volta decodificata, richiederà enormi quantità di memoria ("bomba PNG"), ed è possibile che le routine grafiche stesse siano vulnerabili a contenuti dannosi (un'immagine accuratamente realizzata che, una volta decodificata, attiva l'esecuzione del codice incorporato). C'era una tale vulnerabilità quasi dieci anni fa , e mentre è improbabile, potrebbe fuoriuscire un altro.

[~ # ~] aggiorna [~ # ~] : un altro fatto . E n altro e questo ha un punteggio CVSS di 9.3 - " Vi è un totale compromesso dell'integrità del sistema. Vi è una completa perdita di protezione del sistema, con conseguente nell'intero sistema compromesso "

Poi il HTTP_REFERER tag consentirà al proprietario del sito di immagini di sapere quali pagine sono state visitate e, mediante l'uso di cookie di tracciamento, è possibile divulgare alcune informazioni (ad es. il sito dannoso ospita un'immagine condivisa tra i siti A, B e C Il proprietario dell'immagine può vedere che un determinato utente sul sito A è la stessa persona di un altro utente del sito B, poiché l'immagine imposta un cookie quando utilizzato sul sito A, e ora lo stesso cookie arriva da un utente del sito B). A seconda dello scenario, ciò potrebbe essere indesiderabile.

Incorporando le parti dell'immagine del progetto del sito Host, un utente malintenzionato potrebbe indurre l'utente a credere che il sito stia ospitando alcuni contenuti che in realtà non sono presenti. Ciò richiede che HTML/CSS sia vulnerabile a un'improvvisa modifica della dimensione dell'immagine. Ad esempio, un sito di borsa potrebbe visualizzare, al posto di uno striscione 200x80, uno striscione 200x600 le cui file più in alto sono identiche allo striscione originale e la parte sottostante è realizzata per simulare il sito di borsa e viene "spostata" su uno stock ticker e riproduce lo stesso ticker stock, ma con valori diversi. Un utente incauto potrebbe quindi essere indotto a credere a cifre di borsa totalmente false. Se un numero sufficiente di utenti si convince, ciò potrebbe consentire una sorta di schema "pump and dump".

Una variazione di ciò che si verifica spesso accade è quando si collega l'immagine senza l'autorizzazione appropriata. Il proprietario del sito Web, che si assume il costo di trasportare e fornire l'immagine a il tuo spettatori, ha la possibilità di cambiare l'immagine con qualcosa di completamente diverso . A volte questo viene fatto di proposito in anticipo, cioè un'immagine "succosa" viene seminata nei forum appropriati (ad esempio un pasticcio contro una squadra di calcio?), Quindi viene scambiata con qualcosa con contenuto opposto (lo stesso con i rivali dell'Arco di quella squadra) . Per ulteriore divertimento, il webmaster della pesca alla traina potrebbe registrare gli IP originali che hanno scaricato l'immagine e continuare a inviare loro l'immagine originale. Quindi i fan del team A pubblicizzeranno un lampone contro il loro team e non capiranno perché tutti ridono - ogni volta loro guardano l'immagine, vedono beffardo del team B. Che funge da avviso: non dare per scontato che l'immagine che STAI vedendo sia la stessa vista dai TUOI UTENTI .

18
LSerni

JavaScript stesso non verrà eseguito, anche se il server remoto cambia MIME Content-Type per text/javascript, poiché i browser si aspettano che alcuni tipi MIME siano presenti all'interno del tag IMG. Ciò non significa che siano sicuri da usare, però.

Un thread che ti suggerisco di leggere è è sicuro consentire alle immagini esterne di essere allegate al Blog o ad altri contenuti Web? . In breve, tuttavia, i server da cui si collegano immagini esterne possono ancora leggere tutti i dati dalla richiesta HTTP che è stata inviata loro dal browser dell'utente finale (vale a dire indirizzo IP richiesta, stringa agente utente, versione protocollo e in origine non HTTPS richiedere anche altre intestazioni di richiesta, tra cui referer stringa URL e ovviamente cookie HTTP non protetti).

Il server remoto potrebbe anche generare immagini in modo dinamico, creando potenzialmente altre cause di preoccupazione (contenuto inappropriato, paura di un disordine aggiungendo informazioni sulla richiesta dell'utente finale come indirizzo IP, ...) o semplicemente monitorando l'attività dell'utente sui server ispezionando le intestazioni della richiesta HTTP descritte in precedenza, oppure drop cookie di tracciamento di terze parti con la loro risposta. L'esposizione dell'URL nella stringa referer di richieste HTTP non protette viene spesso trascurata e può esporre gli indirizzi Web del server che potrebbero non piacerti (posizione CMS, dati della sessione URL, .. .). Lo stesso vale per i cookie non sicuri che non sono limitati a un singolo dominio (posizione) e possono essere letti e persino sovrascritti da terze parti.

Inoltre, il codice dannoso può propagarsi attraverso immagini predisposte su sistemi client che non sono stati adeguatamente corretti. Uno degli exploit più famosi è stato il bug GDI + che poteva consentire l'esecuzione di codice in modalità remota su versioni precedenti senza patch di Windows. Ci sono anche altri exploit simili , alcuni dei quali non sono ancora stati affrontati correttamente su tutti i sistemi.

Di alcuni degli exploit più recenti, in alcuni browser è possibile attivare il codice Java (non JavaScript) da un'immagine SVG appositamente predisposta [1][2] :

Exploit-DB - Triggering Java codice da un'immagine SVG :

SVG è un formato di file basato su XML per immagini statiche o animate. Alcune specifiche SVG (come SVG 1.1 e SVG Tiny 1.2) consentono di attivare alcuni Java quando viene aperto il file SVG.

e

Metasploit - Squiggle 1.7 SVG Browser Java Code Execution :

Questo modulo abusa del supporto SVG per eseguire Java nel browser Squiggle incluso nel framework Batik 1.7 attraverso un file SVG predisposto che fa riferimento a un file jar. Per ottenere l'esecuzione di codice arbitrario, il browser deve soddisfare le seguenti condizioni: (1) Deve supportare almeno SVG versione 1.1 o successive, (2) Deve supportare Java e (3) Il controllo "Applica script sicuro" deve essere disabilitato Il modulo è stato testato su piattaforme Windows e Linux

E un po 'di più sui possibili exploit SVG può essere letto nel thread Exploit o altri rischi per la sicurezza con il caricamento SVG? .

Quindi, in breve, non è troppo sicuro e probabilmente dipende dalla tua fiducia nei server remoti da cui collegheresti le immagini per non sfruttarle.

10
TildalWave

Sì, sei al sicuro.

Naturalmente, la pagina che ti viene offerta quando clic destro> Visualizza immagine potrebbe essere dannosa, ma nessuno script verrà eseguito nel contesto del tuo sito web.

Inoltre, non dimenticare che il proprietario del sito Web dell'immagine può tracciare i tuoi visitatori su tutte le pagine in cui è incorporata l'immagine.

6
copy

Una richiesta IMG è una richiesta GET a un server arbitrario, che potrebbe non essere sicuro

La risposta del server può eliminare o sovrascrivere i cookie che potrebbero influire sul funzionamento del browser.

lteriori informazioni

Stackoverflow una volta è stato morso da questo bug, in cui il logout REST era accessibile da una semplice richiesta GET.

Penso che lo scenario sia andato così:

  1. Uno spammer ha pubblicato spam in una determinata pagina.
  2. In quella pagina, includevano un get per /users/logout in un tag IMG
  3. I cookie di autenticazione per l'utente sono stati rimossi tramite le intestazioni HTTP.
  4. Ogni volta che un amministratore o un moderatore tentava di rimuovere lo SPAM venivano disconnessi.

Questo è uno dei motivi per cui esiste una pagina di disconnessione quando si fa clic su "Esci" su SO.

A parte: Anche se SO è un sito HTTP (no "s"/SSL), penso che i cookie sicuri sarebbero vulnerabili

2