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

19

Se un utente carica un file ma modifica la richiesta impostando il tipo mime su qualcosa di arbitrario, come "superdangerous / blackhatstuff", è sicuro per me inviare lo stesso tipo di mime a un altro utente più tardi su?

vale a dire. un altro utente scarica lo stesso file e ho impostato il mimetype su "superdangerous / blackhatstuff", è possibile impostare il tipo mime su qualcosa di potenzialmente pericoloso? Poiché si tratta di dati forniti dall'utente, ho la sensazione che non sia una buona idea archiviare e riprodurre senza una sorta di sterilizzazione. (Naturalmente sto disinfettando la query prima di memorizzare il tipo mime, quindi non mi occupo di attacchi SQL injection tramite il tipo mime.)

Sto usando clam AV per scansionare i file caricati, che si spera catturino alcuni degli attacchi mime sniffing, ma non è proprio quello che sto chiedendo qui.

Se questo è, in effetti, pericoloso, allora qual è la cosa giusta da fare? Non dovrei specificare un tipo mime e lasciare che sia il destinatario a indovinarlo? Dovrei provare a fare il mio mimo sniffing (sto usando PHP su Linux, che fornisce un'API per i file magic.)

Modifica: Altri dettagli

Lasciatemi spiegare lo scopo di questa funzione. L'applicazione in questione viene utilizzata come parte di un flusso di lavoro che richiede vari tipi di artefatti da sottoporre a revisione e approvazione, inclusi (ma non limitati a) documenti di parole, fogli di lavoro, immagini e archivi. Gli altri utenti dovranno essere in grado di scaricare questi artefatti per visualizzarli e prendere una decisione di approvazione.

Per evitare alcune evidenti violazioni, abbiamo una lista nera (come il caricamento di un file PHP o Javascript) e stiamo impostando Content-Disposition su "attachment; filename = ...". Stiamo eseguendo Clam AV sui file caricati come sanitizzazione di base, dal momento che non possiamo applicare una whitelist ai nostri utenti. L'app viene eseguita su una rete intranet e richiede l'autenticazione prima che sia possibile accedere a qualsiasi elemento e i nostri utenti sono [soprattutto] fidati.

Ad ogni modo, il fatto è che non sto chiedendo informazioni sulla sicurezza della memorizzazione dei file e sul permettere agli utenti di scaricare quei file. (Mi rendo conto che è un grande vettore di minacce, ma non è la domanda che sto chiedendo.) Sono molto più preoccupato di sapere se è possibile riprodurre un mime di tipo utente fornito dall'utente e, in caso negativo, qual è l'alternativa? Per non specificare affatto un tipo mime?

    
posta Mark E. Haase 03.11.2011 - 21:35
fonte

4 risposte

13

No, non dovresti rispondere all'utente del tipo MIME fornito dall'utente. L'attacco più semplice che stai esponendo ai tuoi utenti sarebbe quello di caricare file di testo / html con codice Javascript arbitrario, ad es. in [script] elementi. Gli utenti a cui è stato assegnato l'URL del file caricato eseguiranno Javascript, con conseguente XSS . Questo può essere in qualche modo mitigato servendo i file con Content-Type-Disposition: header header, ma ci sono dei modi per aggirarlo.

Un altro vettore memorizza applet Java dannosi o file Flash e molti altri file il cui tipo MIME li rende rilevanti per la sicurezza Web ( file manifest offline HTML5 , crossdomain.xml, vari file eseguibili su client - exe, vbs, ...).

Mentre ci siamo - assicurati di fornire i file forniti dall'utente da un dominio separato dalle tue applicazioni 'principali', per proteggerti dagli attacchi XSS ( lo stesso criterio di origine li interromperà se i file provengono da un dominio diverso).

    
risposta data 04.11.2011 - 00:10
fonte
10

La risposta breve: non è sicura. Permettere all'utente di specificare il tipo MIME e il contenuto del file è un buco XSS autoinflitto.

Un utente malintenzionato Mallory potrebbe specificare il tipo MIME text / html e fornire un documento HTML contenente Javascript pericoloso. Quando servi quel documento ad un altro utente, Alice, il browser di Alice eseguirà il Javascript dannoso. Il Javascript dannoso potrebbe rubare i cookie di sessione di Alice, la password di Alice per questo sito e tutti i dati di Alice su questo sito, o potrebbe manomettere il contenuto che Alice vede su questo sito.

Quindi, no, non è sicuro.

Modifica (11/4): ti vedo modificare la tua domanda per chiederti cosa dovresti fare. Questa è una domanda complessa, ma lascia che ti dia alcune strategie di base per difendermi da questa minaccia:

  • Opzione 1: nessun contenuto fornito dall'utente. Non ospita contenuti forniti dagli utenti. Quindi non devi preoccuparti di questo problema.

  • Opzione 2: consente solo i tipi MIME autorizzati. consente all'utente di caricare i dati e specificare un tipo MIME, ma solo se il tipo MIME fornito dall'utente si trova in una whitelist di tipo noto tipi MIME sicuri che non possono attivare l'esecuzione di codice dannoso. Ad esempio, text/plain e image/jpeg sono generalmente sicuri, se si applicano le difese appropriate contro gli attacchi di content-sning , e quindi potrebbe essere incluso nella whitelist. text/html e application/x-shockwave-flash non sono sicuri e non dovrebbero essere inclusi nella lista bianca.

  • Opzione 3: utilizza un dominio diverso. pubblica i contenuti caricati dall'utente da un dominio diverso. Assicurati che il dominio ospiti solo i contenuti inviati dagli utenti che non sono sensibili alla sicurezza. Non ospitare nessuno dei tuoi materiali su quel sito. Quindi, la politica di origine identica del browser isolerà gli attacchi: un file caricato malintenzionato potrebbe essere in grado di attaccare altri contenuti caricati dagli utenti su quel dominio, ma non di rubare password / cookie di sessione / ecc. dal tuo sito principale.

risposta data 04.11.2011 - 01:58
fonte
1

is it safe for me to send the same mime type back to a different user later on?

Ho intenzione di azzardare il mio braccio e dire di sì, ma potresti dover smettere se non funziona.

In questo caso, un ambiente chiuso con utenti per lo più fidati, caricamenti di elenchi in bianco o limitatori di tipi MIME aggiungerà un po 'di sovraccarico o di inefficienza per una certa percentuale della base di utenti. Più utenti hanno, più è probabile che abbiano un formato che non hai considerato. Se il formato del file di un utente non è nella tua lista, dovrai fare un'eccezione, modificare la tua white-list, o dovranno convertire il file in un formato diverso. Il suo lavoro e ha un costo.

Hai pensato al problema e hai fornito un po 'di attenuazione con la scansione anti-virus. Questa mitigazione non è sufficiente. È necessario assicurarsi di eseguire il backup del dispositivo e se la macchina si arresta per qualsiasi motivo e ripristinare tempestivamente il servizio perduto. Inoltre è necessario monitorare ciò che gli utenti stanno facendo con il tipo MIME e se si abusa o diventa un problema, allora è necessario attivare la lista bianca.

Questo in pratica si riduce a fornire agli utenti ciò di cui hanno bisogno e, se necessario, proteggerli gli uni dagli altri e da soli. A seconda di chi sono i tuoi utenti, potresti anche voler segnalare il problema e far sapere loro che starai guardando. Qualcosa del tipo: "Ciao a tutti, il nuovo server di revisione è a 192.168.0.240. Puoi inviare qualsiasi formato di file che desideri, il che è un po 'rischioso, ma eseguirò il log e esaminerò i caricamenti."

    
risposta data 09.11.2011 - 02:48
fonte
0

Bene, restituire il tipo di contenuto non modificato da un utente potrebbe finire con il tuo invio di contenuti sotto il tipo "third-reich-rules / heil-hitler", che potrebbe farti citare in giudizio e / o ridere in alcune cerchie con basso / strano senso dell'umorismo (come metà della terra che si trova tra gli oceani del Nord Atlantico e del Nord Pacifico).

I supponiamo che se vuoi rimandare un tipo di contenuto specificato dall'utente, è perché in realtà vuoi rimandare a un utente un file che è stato caricato da un altro utente - che è già un intero barattolo di vermi. E con "can" intendo "tanica da 20 galloni".

Puoi consolarti con l'idea che i server di posta elettronica lo fanno costantemente: ogni e-mail può contenere file allegati con molti tipi di contenuto di cui il server di posta elettronica non ha idea. Storicamente, questo ha implicato un sacco di problemi di sicurezza con gli agenti di posta che, dopo aver ricevuto un file contrassegnato come "eseguibile", lo trovavano adatto a reagire: "un eseguibile? Ottimo, eseguiamolo automaticamente!".

Se i tuoi avvocati non ti consentono di intraprendere la strada della non-mia-colpa, allora vorrai disinfettare completamente il contenuto del file, il che implica necessariamente conoscere il tipo di file, il che implica automaticamente sapere quale tipo di contenuto è appropriato. Quindi la questione di lasciare che il tipo di contenuto specificato dall'utente passi attraverso non dovrebbe essere rilevante. Se lo è, allora c'è qualcosa di sospetto nel tuo processo di igiene.

    
risposta data 03.11.2011 - 22:15
fonte

Leggi altre domande sui tag