vulnerabilità dei tag IMG

C'era una "vulnerabilità" in cui l'immagine poteva inviare una risposta di HTTP 401 Unauthenticated , che avrebbe attivato una schermata di accesso per l'utente. Se lo imposti come avatar del forum, verrà generato 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 trovato qualche anno fa, ma oggigiorno non sembra più funzionare. Almeno non riuscivo 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, o dovrebbe, interpretarlo sempre come un'immagine indipendentemente da cosa contenga o da quali intestazioni essa invia. È possibile personalizzare l'immagine in base alla richiesta (servendo una piccola immagine al software del forum per precedere l'immagine in modo che non la riduca in scala, quindi grande per tutti gli altri). Oppure alimenta il browser con un sacco di dati gif finché la memoria non si esaurisce o qualcosa del genere. Ma non ci sono vere grandi vulnerabilità qui che consentono l'esecuzione di Remote Code per quanto ne so.

Ciò che sei solo moderatamente sicuro sono gli attacchi CSRF. L'immagine può emettere una risposta HTTP 302 Moved Temporarily e collegarsi a una nuova posizione. Ad esempio, potrebbe collegarsi a, non ricordo l'URL specifico, qualcosa come https://accounts.google.com/logout e disconnetterti da Google (questo ha funzionato alcuni mesi fa). O, 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 è stata originariamente caricata come richiesta POST, suppongo che potrebbe anche reindirizzare il POST, ma non modificare i dati POST. Quindi è abbastanza sicuro.

Ultimo ma non meno importante, se l'utente malintenzionato controlla gli URL degli avatar forum ad esempio (come nei forum SMF), è possibile ottenere informazioni da visitatori come il loro indirizzo IP. Ho scritto uno strumento qualche tempo fa che utilizzava la pagina action=who di SMF per collegare gli indirizzi IP ai nomi utente. Quando ho iniziato a mostrarlo agli utenti (mostra "Hello $ username with IP: $ IP" nell'immagine) si scatenò l'inferno. "Come potresti saperlo?!" Erano per la maggior parte dei tecnici di fascia medio-alta, quindi sapevano quale fosse l'indirizzo IP, ma non sapevano che non potevo hackerarli con esso . Tuttavia, sono considerate informazioni di identificazione personale, almeno nei Paesi Bassi, quindi gli amministratori non erano molto contenti di questa pratica. Se non lo visualizzi, nessuno lo saprà mai.

Nota: se questo post sembra scritto in fretta, lo è. Anche a malapena sono sveglio. Forse lo pulirò domani se è troppo storytelling e non citerò abbastanza fatti concreti e vulnerabilità. Spero che questo sia stato d'aiuto comunque!

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 siano vulnerabili a contenuti dannosi (un'immagine accuratamente realizzata che, quando decodificato, attiva l'esecuzione del codice incorporato). C'era una tale vulnerabilità quasi dieci anni fa , e mentre improbabile, un altro potrebbe saltar fuori .

UPDATE : un altro ha fatto . E altro , e questo ha un punteggio CVSS di 9.3 - " C'è un totale compromissione dell'integrità del sistema: c'è una perdita completa della protezione del sistema, con conseguente compromissione dell'intero sistema "

Quindi, il tag HTTP_REFERER consentirà al proprietario del sito di immagini di sapere quali pagine sono state visitate e, attraverso l'uso di cookie di tracciamento, è possibile divulgare alcune informazioni (ad esempio 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 sta arrivando da un utente del sito B). A seconda dello scenario, questo potrebbe essere indesiderato.

Incorporando nell'immagine parti del design del sito host, un utente malintenzionato potrebbe indurre l'utente a credere che il sito stia ospitando contenuti che in realtà non sono presenti. Ciò richiede che HTML / CSS sia vulnerabile a un'improvvisa modifica delle dimensioni dell'immagine. Ad esempio, un sito di borsa potrebbe visualizzare, al posto di un banner 200x80, un banner 200x600 le cui righe più in alto sono identiche al banner originale, e la parte sottostante è realizzata per simulare il sito di borsa e viene "spinta" su un supporto ticker e riproduce lo stesso ticker azionario, ma con valori diversi. Un utente sprovveduto potrebbe quindi essere indotto a credere che le figure siano totalmente false. Se un numero sufficiente di utenti si convince, questo potrebbe consentire una sorta di schema "pump and dump".

Una variazione di ciò che spesso accade accade è quando si collega l'immagine senza autorizzazione appropriata. Il proprietario del sito web, che si assume il costo di trasportare e fornire l'immagine ai tuoi spettatori, ha la possibilità di cambiare l'immagine con qualcosa di completamente diverso . Questo a volte viene fatto apposta in anticipo, vale a dire, un'immagine "succosa" viene seminata nei forum appropriati (ad esempio un mash contro una squadra di calcio?), Quindi viene scambiata con qualcosa con contenuti opposti (lo stesso con i rivali storici di quella squadra) . Per maggiore divertimento, il webmaster di trolling può registrare gli IP originali che hanno scaricato l'immagine e continuare a inviare loro l'immagine originale. Quindi i fan della squadra A pubblicizzeranno un lampone contro il proprio team, e non capiranno perché tutti ridono - ogni volta che loro guardano l'immagine, la vedono beffarsi della squadra B . Che funge da avviso: non assumere che l'immagine che stai vedendo sia la stessa dei TUOI UTENTI sta vedendo .

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

Un thread che suggerisco di leggere è è sicuro consentire l'aggiunta di immagini esterne a Blog o a qualsiasi contenuto Web? . In breve, i server che collegano le immagini esterne possono comunque leggere tutti i dati dalla richiesta HTTP che è stata inviata loro dal browser dell'utente finale (ovvero richiedere l'indirizzo IP, la stringa dell'agente utente, la versione del protocollo e in non HTTPS originari richiedi anche altre intestazioni di richiesta, tra cui referer stringa URL e, naturalmente, cookie HTTP non protetti).

Il server remoto potrebbe anche generare immagini dinamicamente, potenzialmente creando altre cause di preoccupazione (contenuto inappropriato, paura di aggiungere informazioni sulla richiesta dell'utente finale come l'indirizzo IP, ...) o semplicemente tracciare l'attività degli utenti sui server ispezionando HTTP richiedere le intestazioni descritte in precedenza o rilasciare cookie di tracciamento di terze parti con la loro risposta. L'esposizione dell'URL nella stringa referer di richieste HTTP non protette è spesso trascurata e può esporre gli indirizzi Web del tuo server che potrebbero non piacere a loro (posizione CMS, dati della sessione URL, ...) . Lo stesso vale per i cookie non protetti che non sono limitati a un singolo dominio (posizione) e possono essere letti e persino sovrascritti da una terza parte.

Inoltre, il codice dannoso può propagarsi attraverso immagini create su sistemi client che non sono stati adeguatamente riparati. Uno dei più famosi exploit di questo tipo era il bug GDI + che poteva consentire l'esecuzione di codice in modalità remota su versioni precedenti di Windows prive di patch. Esistono anche altri exploit simili , alcuni dei quali non ancora adeguatamente indirizzati su tutti i sistemi .

Di alcuni recenti exploit di questo tipo, l'attivazione di codice Java (non JavaScript) da un'immagine SVG appositamente predisposta è possibile su alcuni browser ^{[1] [2]} :

Exploit-DB - Triggering Java Code from a SVG Image:

SVG is a XML-based file format for static or animated images. Some SVG specifications (like SVG 1.1 and SVG Tiny 1.2) allow to trigger some Java code when the SVG file is opened.

e

Metasploit - Squiggle 1.7 SVG Browser Java Code Execution:

This module abuses the SVG support to execute Java Code in the Squiggle Browser included in the Batik framework 1.7 through a crafted SVG file referencing a jar file. In order to gain arbitrary code execution, the browser must meet the following conditions: (1) It must support at least SVG version 1.1 or newer, (2) It must support Java code and (3) The "Enforce secure scripting" check must be disabled. The module has been tested against Windows and Linux platforms

E si può leggere un po 'di più sui possibili exploit SVG negli Sfruttamenti o altri rischi per la sicurezza con il caricamento di SVG? thread.

Quindi, in breve, non è troppo sicuro e probabilmente dipende dalla tua fiducia sui server remoti che collegherei le immagini da non sfruttarle.

Sì, sei al sicuro.

Ovviamente, la pagina viene visualizzata quando Fai clic con il pulsante destro del mouse > Visualizza immagine potrebbe essere dannoso, ma nessuno script verrà eseguito nel contesto del tuo sito web.

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

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

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

Ulteriori informazioni

Stackoverflow una volta veniva morso da questo bug, in cui l'API REST di logout era accessibile da una semplice richiesta GET.

Penso che lo scenario sia andato così:

1. Uno spammer ha postato spam su una determinata pagina.
2. In quella pagina, includevano un recupero 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 ha provato a rimuovere lo SPAM, sono stati disconnessi.

Questo fa parte del motivo per cui esiste una pagina di disconnessione quando fai clic su "Esci" su SO.

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