X-Content-Type-Options previene davvero gli attacchi di sniffing dei contenuti?

Sfondo. X-Content-Type-Options: è un'intestazione progettata per difendi contro attacchi di sniffing dei contenuti MIME . Gli attacchi di sniffing dei contenuti MIME sono un rischio quando si consente agli utenti di caricare contenuti (ad es. Immagini, documenti, altri file) sul proprio sito Web, dove possono essere scaricati da altri utenti.

Come dice @Rook, questo non ha nulla a che fare con l'intercettazione / acquisizione del traffico di rete.

Quali attacchi non previene? Poiché X-Content-Type-Options: è supportato solo su alcuni browser, non protegge gli attacchi contro gli utenti che utilizzano altri browser. In particolare, si suppone su IE, Chrome e Firefox 50 . Vedi anche Quali sono i rischi per la sicurezza che consente agli utenti di caricare contenuti sul mio sito? per altri attacchi che non fa evitare, ad esempio, il caricamento di malware o di contenuti sgradevoli, il caricamento di contenuti che sfruttano una vulnerabilità nel browser dell'utente, ecc.

Quale tipo di contenuto deve essere restituito? Dovresti restituire il tipo di contenuto appropriato per quel file. Non dovresti consentire agli utenti di caricare contenuti non sicuri con tipi di contenuto pericolosi. Per maggiori dettagli, consultare le risposte alle seguenti domande:

1. È sicuro servire qualsiasi file caricato dall'utente sotto i soli tipi di contenuto MIME elencati in bianco?

2. È sicuro memorizzare e riprodurre tipi mime forniti dall'utente?

3. Protezione di sniffing MIME

4. Perché dovrei limitare il tipo di contenuto dei file da caricare sul mio sito?

5. Quali sono i rischi per la sicurezza che consente agli utenti di caricare contenuti sul mio sito?

6. Come posso essere protetto dalle vulnerabilità delle immagini?

7. Uso dell'estensione di file e del tipo MIME (come output per file -i -b) per determinare i file non sicuri?

Questo argomento è stato ampiamente discusso e documentato altrove su questo sito, quindi non ho intenzione di provare a ripetere tutti i consigli utili trovati lì.

Aggiornamento: ho appena appreso che impostare correttamente le intestazioni Content-Type e X-Content-Type-Options non è sufficiente per la sicurezza. A quanto pare, Flash ignora l'intestazione Content-Type , che potrebbe consentire il caricamento di un SWF dannoso, che può quindi fare tutto ciò che fare con un XSS. (Sigh, stupido Flash.) Sfortunatamente, nessuna quantità di whitelisting dei tipi di contenuto di file può fermare questo attacco. Di conseguenza, sembra che l'unica soluzione sicura sia ospitare il contenuto caricato dall'utente su un dominio separato.

Ecco una risposta di Michal Zalewski ricevuta per email:

The short answer is that it works in MSIE, and only in some specific cases. It won't protect you against (much less zealous) sniffing in most other browsers; but more importantly, won't discourage plugins from doing things such as the crossdomain.xml risk outlined above; and won't necessarily prevent subresource loads with mismatched MIME types (i.e., loading an image as application/x-shockwave-flash via <embed>).

What sniffing attacks X-Content-Type-Options:nosniff doesn't prevent?

Sniffing da strumenti che non conoscono X-Content-Type-Options : alcuni browser e plug-in che possono recuperare risorse di rete. (Ad esempio, storicamente Java GIFAR, Flash loadPolicyFile ...)

What Content-Type should be returned to user instead of text/plain?

Non c'è una buona risposta, quindi se hai bisogno di ospitare file di testo non fidati dovresti prendere la solita mitigazione di ospitarli su un hostname separato (e idealmente un indirizzo IP).

Alternativa: codifica HTML, aggiungi <pre> e pubblica come text/html .