it-swarm.dev

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

In Tangled Web Michal Zalewski dice:

Evita di usare Content-Type: application/octet-stream e usa invece application/binary, specialmente per tipi di documenti sconosciuti. Evita di restituire Content-Type: text/plain.

Ad esempio, qualsiasi piattaforma di hosting di codice deve prestare attenzione quando si restituiscono file eseguibili o archivi di origine come application/octet-stream, poiché esiste il rischio che possano essere interpretati erroneamente come HTML e visualizzati in linea.

La logica testuale/semplice successivamente implementata in Internet Explorer e Safari per rilevare l'HTML in tal caso è davvero una brutta notizia: priva gli sviluppatori web della possibilità di utilizzare in modo sicuro questo tipo MIME per generare documenti in chiaro specifici dell'utente e non offre alternative . Ciò ha comportato un numero considerevole di vulnerabilità delle applicazioni Web, ma fino ad oggi gli sviluppatori di Internet Explorer sembrano non avere rimpianti e non hanno modificato il comportamento predefinito del loro codice.

Il sito utilizza X-Content-Type-Options:nosniff. L'autore dice quanto segue su questa intestazione:

L'uso di questa intestazione [X-Content-Type-Options] è altamente raccomandato; sfortunatamente, il supporto per esso [...] ha solo un supporto limitato in altri browser. In altre parole, non si può fare affidamento come unica difesa contro lo sniffing dei contenuti.

Quali contenuti sniffing attacca X-Content-Type-Options:nosniff non impedisce? Che cosa Content-Type dovrebbe essere restituito all'utente anziché text/plain?

19
Andrei Botalov

Sfondo. X-Content-Type-Options: è un'intestazione progettata per difesa contro attacchi di sniffing di contenuto MIME . Gli attacchi di sniffing di 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 intercettare/catturare il traffico di rete.

Quali attacchi non impedisce? Perché 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 5 . Vedi anche Quali sono i rischi per la sicurezza di consentire agli utenti di caricare contenuti sul mio sito? per alcuni altri attacchi che non impedisce, ad esempio, il caricamento di malware o contenuti non salati, il caricamento di contenuti che sfruttano una vulnerabilità nel browser dell'utente, ecc.

Quale tipo di contenuto deve essere restituito? È necessario restituire il tipo di contenuto appropriato per quel file. Non devi consentire agli utenti di caricare contenuti non attendibili con tipi di contenuto pericolosi. Per ulteriori dettagli, consultare le risposte alle seguenti domande:

  1. È sicuro pubblicare qualsiasi file caricato dall'utente solo con tipi di contenuto MIME in white list?

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

  3. protezione 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 di consentire agli utenti di caricare contenuti sul mio sito?

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

  7. tilizzando la combinazione di estensione di file e tipo MIME (come output dal file -i -b) per determinare i file non sicuri?

Questo argomento è stato ampiamente discusso e documentato altrove in questo sito, quindi non proverò a ripetere tutti i consigli utili trovati lì.


Aggiornamento: ho appena imparato che l'impostazione di Content-Type e X-Content-Type-Options le intestazioni in modo appropriato non sono sufficienti per la sicurezza. Apparentemente, Flash ignora l'intestazione Content-Type , che potrebbe consentire il caricamento di un file SWF dannoso, che può quindi fare tutto ciò che faresti con un XSS. (Sospiro, stupido Flash.) Sfortunatamente, nessuna quantità di whitelist dei tipi di contenuto dei file può fermare questo attacco. Di conseguenza, sembra che l'unica soluzione sicura sia quella di ospitare il contenuto caricato dall'utente su un dominio separato.

23
D.W.

Ecco una risposta di Michal Zalewski ricevuta via email:

La risposta breve è che funziona in MSIE e solo in alcuni casi specifici. Non ti proteggerà dallo sniffing (molto meno zelante) nella maggior parte degli altri browser; ma soprattutto, non scoraggerà i plugin dal fare cose come il rischio crossdomain.xml descritto sopra; e non impedirà necessariamente il caricamento di risorse secondarie con tipi MIME non corrispondenti (ovvero, il caricamento di un'immagine come application/x-shockwave-flash tramite <embed>).

6
Andrei Botalov

Cosa annusa lo X-Content-Type-Options: nosniff non impedisce?

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

Quale tipo di contenuto deve essere restituito all'utente anziché al testo/semplice?

Non c'è una buona risposta a ciò, quindi se devi ospitare file di testo non attendibili dovresti prendere la solita mitigazione di ospitarli su un nome host separato (e idealmente indirizzo IP).

Alternativa: codifica HTML, aggiungi un <pre> e fungere da text/html.

3
bobince