Come posso essere protetto dalle vulnerabilità delle immagini?

Ho alcuni suggerimenti:

1. Utilizza un dominio separato. Ospita le immagini su un dominio separato che viene utilizzato solo per ospitare immagini fornite dall'utente.

   Ciò garantirà che molti attacchi a livello di browser possano avere solo effetti limitati. Ad esempio, supponiamo che il browser dell'utente sia vulnerabile agli attacchi di tipo "content-sniffing", quindi è possibile caricare un'immagine che alcuni browser considereranno come HTML contenente Javascript pericoloso; questa difesa garantisce che il Javascript dannoso può solo manomettere le immagini di altri utenti e non può accedere ai cookie o al contenuto del tuo sito o ad altri elementi sensibili alla sicurezza. Tuttavia, questo non si difende dagli attacchi di iniezione di codice che sfruttano una vulnerabilità (ad es., Un sovraccarico del buffer, un doppio free) ed eseguono il codice nativo.

2. Difenditi dallo sniffing dei contenuti. Segui pratiche che ho delineato altrove per difenderci dagli attacchi di tipo content-sniffing. Il più importante è impostare un'intestazione Content-Type: corretta sulle risposte HTTP in cui viene pubblicata l'immagine. Può anche essere utile includere un'intestazione X-Content-Type-Options: nosniff , per evitare che alcune versioni di IE provino a eseguire lo sniffing di tipo contenuto.

3. Converti in un formato fisso. Converti l'immagine di input in una bitmap (mantenendo solo i dati bitmap e gettando via tutte le annotazioni extra), quindi converti la bitmap nel formato di output desiderato. Un modo ragionevole per farlo è quello di convertire in formato PBM, quindi convertire in PNG.

   Questo non è un modo affidabile per fermare gli attacchi, ma riduce parte della superficie di attacco disponibile per l'attaccante. Ad esempio, impedisce all'utente malintenzionato di allegare metadati dannosi creati per sfruttare alcune vulnerabilità nell'analizzatore di immagini. Inoltre, non offre all'aggressore una scelta di formati di immagine. Per sconfiggere questa difesa, l'attaccante deve trovare una vulnerabilità nel decodificatore PNG, nel codice che legge i dati dei pixel dell'immagine. Impedisce all'utente malintenzionato di sfruttare una vulnerabilità nel decodificatore per qualche altro formato di immagine o nella parte del parser PNG che legge i metadati. Quindi, anche se potenzialmente utile per ridurre il rischio, non mi aspetterei che questa difesa da sola sia sufficiente.

4. Considera la casualità. Considera l'inserimento di un rumore casuale nell'immagine. Ad esempio, è possibile eseguire il loop su tutti i pixel e, per ciascuna delle tre intensità (corrispondenti a RGB) per quel pixel, scegliere casualmente tra l'aggiunta 1, la sottrazione 1 o l'abbandono di tale valore di intensità. Questo introduce un po 'di rumore nell'immagine, ma si spera non sia abbastanza per essere visibile agli spettatori. E, se sei fortunato, potrebbe rendere meno probabili alcuni attacchi, perché l'attaccante non può prevedere completamente il risultato della trasformazione. Questa difesa è altamente euristica e sicuramente non è garantita per essere efficace, ma è possibile che potrebbe essere d'aiuto, se usata in aggiunta alle altre difese che ho delineato, come una sorta di strategia di difesa e approfondimento della cintura e delle bretelle . Ma per favore comprendi che questa difesa da sola probabilmente non è adeguata.

A seconda di quanto ti preoccupa di questi rischi e della sensibilità del tuo sito, non è necessario che tu faccia tutti e quattro. Se non sei preoccupato delle vulnerabilità di iniezione di codice nel browser, potresti fare solo il numero 1 e il numero 2. Se desideri una protezione parziale contro le vulnerabilità di iniezione di codice nel browser, puoi fare solo # 1, # 2 e # 3.

Una possibile soluzione sarebbe quella di riscrivere il file come semplice formato noto prima di visualizzare l'immagine sul sito. per esempio. qualcuno carica un'immagine (eventualmente con un exploit), immediatamente il server legge l'immagine in modo sicuro e scrive una nuova immagine. Se il programma / script che utilizzava per leggere l'immagine caricata leggeva solo i dati a colori, la nuova immagine può contenere solo dati a colori.

Penso che dipenda dalla prospettiva? Dal punto di vista dell'utente finale, la protezione dagli exploit (esp memory / buffer overflow) dalle immagini o da qualsiasi altra fonte (ancora, che sfrutta le vulnerabilità del buffer overflow) trarrebbe vantaggio dall'assicurarsi che le funzionalità di protezione della memoria siano completamente abilitate. In Windows, vengono utilizzati meccanismi come DEP (basato su NX / XD) e ASLR per ridurre la probabilità di esecuzione del codice a causa di un sovraccarico del buffer. DEP può essere attivato per impostazione predefinita per tutte le applicazioni anziché solo opt-in, ad es.

Questo è in aggiunta ai soliti suggerimenti sull'uso dell'antivirus, sul mantenimento della patch del software e su altre cose ovvie.

Se hai un'opzione per sandboxare le tue applicazioni per limitare i danni (post-exploit), allora quella è anche una strada percorribile. Per lo meno, è possibile utilizzare il principio del privilegio minimo (ad esempio, non utilizzando account amministrativi laddove non necessario).

Spero che ti aiuti.