Usando la combinazione di estensione del file e tipo MIME (come output per file -i -b) per determinare i file non sicuri?

Naviga le tue risposte
15

Permettiamo agli utenti di caricare un numero di file, che inviamo a scribd (doc, xls, ppt, ecc.) o mostriamo come video noi stessi (flv, mov, mp4, etc in flowplayer).

Per evitare che gli utenti caricino file non sicuri, controlliamo un insieme di estensioni di file "sicure" conosciute e quindi controlliamo l'output del comando file -i -b che ci fornisce il tipo MIME. 

Usage: file [OPTION]... [FILE]...
Determine file type of FILEs.
...
-i, --mime                 output mime type strings

Questa protezione è adeguata per mantenere gli "script non sicuri" fuori dal nostro server o la gente usa qualcosa di diverso?

    
posta siliconpi 24.09.2011 - 12:44
fonte

3 risposte

15

Avviso. I passaggi che descrivi non sono sufficienti per essere sicuri, se quei file sono disponibili dai tuoi server.

Spiegazione. Poiché i browser fanno lo sniffing dei contenuti in una varietà di circostanze per indovinare il tipo MIME appropriato, esistono una serie di attacchi scripting cross-site che rimangono possibili. La categoria generale è talvolta nota come XSS per lo sniffaggio dei contenuti.

Vedi il seguente documento di ricerca:

Anche i seguenti post e messaggi del blog parlano di questa minaccia:

Difese. Ti consiglio di adottare le seguenti difese e attenuanti:

  1. Ospita il contenuto in un dominio separato, che viene utilizzato solo per ospitare contenuti caricati dall'utente. In questo modo verrà eseguito il sandbox, quindi gli attacchi XSS in grado di sniffare contenuti possono solo attaccare il contenuto di altri utenti e non possono attaccare il tuo sito. (Ad esempio, Wikipedia e Facebook usano questa difesa.)

  2. Assicurati di impostare un'intestazione Content-Type: corretta su ogni risposta che serve il contenuto caricato dall'utente. Controlla il tipo di contenuto per assicurarti che sia una delle varie opzioni su una lista bianca di tipi di contenuto sicuri. Evita di inviare un tipo MIME non valido (ad esempio */* , unknown/unknown , application/unknown ) ed evita le risposte prive di un'intestazione Content-Type: ; quelli sono soggetti allo sniffing del tipo di contenuto del browser e quindi ad alto rischio di attacco. Evita i tipi MIME che fanno sì che IE7 faccia lo sniffing di tipo contenuto (vedi la carta di Barth et ale per un elenco, nella Tabella 4).

  3. Durante la pubblicazione di contenuti forniti dall'utente, non servirne mai uno con un tipo MIME non sicuro che può attivare l'esecuzione del codice attivo. Ad esempio, evita quanto segue: text/html , application/x-shockwave-flash , poiché possono contenere codice privilegiato. Purtroppo non penso che sia sicuro pubblicare contenuti Flash forniti dall'utente dal tuo sito.

  4. Durante la pubblicazione di contenuti forniti dall'utente, includi un'intestazione X-Content-Type-Options: nosniff insieme all'intestazione Content-Type: , per disabilitare lo sniffing del tipo di contenuto su alcune versioni di IE.

  5. Per contenuti che non ti aspetti di essere visualizzabili nel browser, contrassegnali in modo che il browser li gestisca come download di file: ad esempio, aggiungi un'intestazione Content-Disposition: attachment .

(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.)

    
risposta data 25.09.2011 - 02:07
fonte
4

Probabilmente non è sicuro. Esistono vari attacchi che ingannano lo sniffer del tipo di contenuto nel credere che un file sia il tipo di contenuto sbagliato. Ecco un esempio particolarmente infame:

link

Il suggerimento del poster precedente è buono per proteggere il server da script malevoli: spostare i file caricati all'esterno della web root e scrivere uno script per inviarli all'utente. Vuoi evitare che il tuo server web o il tuo runtime eseguano i file caricati di un utente. Non hai specificato una lingua, ma qui c'è un esempio di PHP:

link

Un altro aspetto trascurato della "sicurezza dei file" è la protezione dei file per gli utenti. Se stai permettendo agli utenti di scaricare file che sono stati caricati da altri utenti, gli utenti malintenzionati possono utilizzare il tuo sito per diffondere malware. In questo caso, probabilmente desideri mettere in quarantena i file caricati finché non li puoi scansionare con AV.

    
risposta data 25.09.2011 - 16:34
fonte
4

Penso che sia adeguato. Tuttavia, vorrei ancora mai mettere i file caricati in una directory a cui è possibile accedere direttamente tramite il server web: gli utenti accedono ai file tramite uno script di download. In questo modo, anche se qualcuno riesce a caricare qualcosa di eseguibile, non verrà eseguito.

Fai molta attenzione quando chiami "file" a proposito, se il nome file fornito dall'utente è un argomento, assicurati di eseguirlo correttamente prima di usarlo in system ().

    
risposta data 24.09.2011 - 12:53
fonte

Leggi altre domande sui tag

Distanza tra due password L'impostazione httponly impedisce il furto di una sessione usando XSS?