È sicuro servire qualsiasi file caricato dall'utente sotto i soli tipi di contenuto MIME in lista bianca?

Question

È sicuro servire qualsiasi file caricato dall'utente sotto i soli tipi di contenuto MIME in lista bianca?

#1 da (11 voti)
#2 da (9 voti)
#3 da (6 voti)
#4 da (2 voti)

16

Diciamo che sviluppo un'applicazione che,

Consente a qualsiasi utente di caricare un file di tipo di contenuto e estensioni mime elencati in bianco (parola e pdf).
Fornisce i file con l'estensione e il tipo di contenuto consentiti.

Questo è un rischio per la sicurezza? Perché?

Alcuni browser dedurranno il tipo di contenuto dai byte del file (usando le intestazioni magiche) e scartano il tipo di contenuto che sto specificando nelle intestazioni?

Qual è la soluzione per renderlo sicuro? Devo affermare che i file che vengono caricati hanno byte magici che corrispondono al tipo mime fornito dal client?

So che questa domanda è simile a È sicuro memorizzare e riprodurre tipi di mime forniti dall'utente? , ma non pensare che sia un duplicato.

virus appsec file-upload

posta Andy 15.02.2012 - 18:17

fonte

4 risposte

Leggi altre domande sui tag virus appsec file-upload

Utilizzando legittimamente strumenti come Havij posso identificare il computer di origine per un programma?

score 11 · Answer 1

contenuto HTML - sniffing, come delineato da Krzysztof; principalmente ma non esclusivamente IE.
jar: vulnerabilità degli URL nel vecchio Firefox
Contenuto simile a un file JAR ( GIFAR et al) - ospita qualcosa che può essere interpretato come un Java l'archivio implica XSS a causa della diversa politica Same Origin applicata da Java.
Un file contenente qualcosa che assomiglia un po 'al contenuto crossdomain.xml può essere preso di mira dalla chiamata loadPolicyFile per ottenere XSS per un chiamante Flash.

Should I assert the files being uploaded have magic bytes matching the client provided mime type?

Insufficiente contro i camaleonti (file ugualmente validi come entrambi i tipi).

What is the solution to make this secure?

L'unica soluzione efficace è quella di pubblicare i contenuti caricati non attendibili da un nome host diverso dal tuo sito principale.

Questo diverso nome host può essere un sottodominio del tuo sito principale se sei preoccupato solo per il codice JavaScript diretto XSS / Same Origin Policy.
Deve essere un sottodominio disgiunto se è necessario impedirgli di leggere i cookie (come gli ID di sessione). Cioè, può essere insecure.example.com se hai il tuo sito principale su www.example.com, ma in quel caso non devi nemmeno permettere al tuo sito di rispondere su "example.com". non è possibile impedire ai cookie example.com di ereditare in insecure.example.com su IE. Procedura consigliata: reindirizza tutti gli accessi a example.com a www.example.com.
Deve essere un dominio completamente diverso se è necessario impedire la forzatura dei cookie: cioè, insecure.example.com può scrivere un cookie che verrà letto da www.example.com, potenzialmente sostituendo i cookie impostati da www .example.com. Si tratta di una vulnerabilità meno severa: la possibilità di leggere i cookie in genere comporta il dirottamento di sessione, mentre la forzatura dei cookie porta solo alla negazione del servizio (poiché www.example.com non funzionerà senza i suoi cookie).
Deve anche essere pubblicato su un indirizzo IP diverso, se si è interessati a prevenire il furto dei cookie utilizzando una vulnerabilità nei vecchi plugin Java, o se si hanno altri servizi in esecuzione su porte che non si vorrebbe applet per poter accedere.

Tra loro, i browser e i plug-in hanno reso l'hosting di file caricati in modo sicuro una terribile prova.

score 9 · Answer 2

Sfortunatamente, nel tuo esempio, Internet Explorer cercherà comunque di rilevare il tipo MIME dai primi 256 byte del contenuto dei file (si chiama MIME sniffing). Citando la documentazione MSDN sull'argomento :

2. If the server-provided MIME type is either known or ambiguous (my note: application/pdf is known), the buffer is scanned in an attempt to verify or obtain a MIME type from the actual content. If a positive match is found (one of the hard-coded tests succeeded), this MIME type is immediately returned as the final determination, overriding the server-provided MIME type (this type of behavior is necessary to identify a .gif file being sent as text/html). During scanning, it is determined if the buffer is predominantly text or binary.

Ho appena confermato questo comportamento utilizzando il seguente file PHP:

<?php header('Content-Type: application/pdf'); ?>
<html>
<p>Hello, <b>world</b></p>

Visualizza contenuto HTML in IE8 / Win XP SP2.

Puoi modificare questo processo specificando X-Content-Type-Options: nosniff intestazione HTTP nella risposta, ma è supportato in IE8 + . Fortunatamente, altri browser si fidano delle intestazioni HTTP e lo sniffing MIME è molto più leggero in esse, per es. documenti di Firefox . C'è un ottimo whitepaper che documenta lo sniffing MIME in vari browser.

Se possibile, dovresti anche provare a controllare i byte magici dal contenuto del file. Ti suggerisco inoltre di utilizzare Content-disposition: attachment header.

score 6 · Answer 3

Sniffing dei contenuti. La tua proposta non è sufficiente: sarà vulnerabile agli attacchi di sniffing dei contenuti. Ho scritto altrove sulle strategie per prevenire gli attacchi di sniffing dei contenuti . Ci sono una varietà di difese. Ecco i principali:

Includi un'intestazione Content-Type: nella risposta. Assicurati che includa un tipo MIME valido (evita tipi MIME non validi).
Includi un'intestazione X-Content-Type-Options: nosniff nella risposta. Questo spegnerà gli algoritmi di content-sniffing di IE, sulle versioni recenti di IE.
Se non desideri che il contenuto venga visualizzato nel browser, può aiutare a impostare Content-Disposition: attachment , in modo che il browser lo tratti come un download di file.

Anche questi passaggi non sono garantiti per essere sufficienti. Ad esempio, se l'utente utilizza IE6, sarà comunque vulnerabile.

(Se ti sembra fastidioso, hai ragione, incolpati gli utenti di Apache per aver incluso una configurazione di default scadente che ha infranto gli standard web per molti anni e ignorato le richieste di fare qualcosa al riguardo. Purtroppo, ormai è troppo tardi: siamo bloccati con una grande base di browser che fa cose pericolose.)

Dominio separato. Una difesa migliore è quella di ospitare il contenuto fornito dall'utente in un dominio separato, che viene utilizzato solo per il contenuto caricato dall'utente. In questo modo, un attacco di successo per il contenuto non può attaccare il contenuto del tuo sito. Il caricamento di un utente può ancora attaccare i caricamenti di altri utenti, ma potrebbe essere tollerabile.

Controlla la tua lista bianca. Sembra che tu pensi che i file PDF e Word siano innocui. Tuttavia, questi sono due formati di file potenti e pericolosi. PDF è noto per essere un vettore. I file PDF dannosi abbondano e possono penetrare con successo in molti vecchi visualizzatori di PDF. Il rischio PDF è così elevato che Chrome prende precauzioni speciali prima di consentirti di scaricare e visualizzare un documento PDF nel tuo visualizzatore PDF. Word è anche un formato di file potente e pericoloso, che può essere un host per gli attacchi. Per questo motivo, non considererei innocuo Word o PDF.

Potresti essere in grado di reindirizzare gli utenti a Google Documenti, per visualizzare il file Word / PDF nel browser tramite Google Documenti. Google convertirà il file Word / PDF in HTML e poi lo invierà al browser del visualizzatore. Questo può o non può essere accettabile nelle tue circostanze.

Scansiona i caricamenti di file per i virus. Ti consiglio di eseguire la scansione di tutti i contenuti caricati dagli utenti per i virus, utilizzando alcuni virus o scanner di malware. Per i file PDF, vedi anche Come eseguire la scansione di un PDF per malware? . Potresti voler eseguire la scansione del caricamento immediatamente quando viene caricato. Potresti anche considerare di riesaminare periodicamente i file più vecchi (questo potrebbe rilevare alcuni malware che non erano stati rilevati in precedenza, poiché le definizioni di antivirus / malware sono state aggiornate).

Ulteriori informazioni. Vedi anche Elenco di controllo di Mozilla per i caricamenti di file , nella loro versione sicura standard di codifica. È un bel elenco di buone pratiche di sicurezza.

Riepilogo. In sintesi, la difesa più potente ed efficace che puoi utilizzare è quella di posizionare il contenuto caricato dall'utente su un dominio separato. Quindi, come protezione aggiuntiva, potresti prendere in considerazione le altre difese elencate qui.

Aggiornamento: ho appena saputo di un altro problema con il tuo schema. 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 può fermare questo attacco. Di conseguenza, sembra che l'unica soluzione sicura sia ospitare il contenuto caricato dall'utente su un dominio separato.

score 2 · Answer 4

Penso che le altre 2 risposte siano buone. Ma ecco un'altra cosa a cui pensare: anche se hai avuto un completo successo nel limitare i tipi di contenuti che offri, i documenti Word e i documenti PDF possono ancora essere dannosi da soli.

Un documento PDF può sfruttare una delle centinaia di vulnerabilità esistenti nelle versioni precedenti di Adobe Reader. La migliore soluzione è quella di eseguire la scansione di ogni file caricato con rilevamento antivirus / malware. (Anche se si tratta ancora di una mitigazione limitata a causa della natura del gatto e del topo delle firme dei virus.)