Creazione di una lista nera di tipi di file per proteggere l'applicazione PHP

9

Sto lavorando in un sistema PHP in cui l'utente può caricare file.

Sto provando a proteggere il sistema da codici maligni, quindi sto pensando a un tipo di lista nera di file che devo bloccare dal caricamento.

So che una lista bianca è migliore di una lista nera e questo è il mio approccio comune, ma in questo caso Devo fare una lista nera di file per molte ragioni (fuori dal mio controllo), ma continuo a cercare sicurezza (se possibile).

Questo è il mio script corrente (sto controllando il tipo MIME per ottenere il tipo di file):

        $finfo = finfo_open(FILEINFO_MIME_TYPE);
        $check= finfo_file($finfo,$file["tmp_name"]);
        finfo_close($finfo);

        $dangerMime = array('application/x-bsh', 'application/x-sh', 'application/x-shar', 'text/x-script.sh');
        if (in_array($check, $dangerMime)) {
            //block upload
        }
        else {
            //allow upload
        }

L'elenco corrente di tipi MIME da bloccare è:

  • 'application/x-bsh', 'application/x-sh', 'application/x-shar', 'text/x-script.sh'

Sto provando a bloccare qualsiasi file .sh , poiché il sistema è in esecuzione in CentOS sotto Apache. Ci sono altri tipi di file che dovrei anche bloccare?

Di seguito sono riportate alcune informazioni importanti:

Il server è un CentOS 7.2 con Apache 2.4.6. Di seguito sono riportate le autorizzazioni della directory di upload:

drwxr-xr-x  4 apache apache 4096 Jan  8 12:23 uploads

Nota: in questo progetto, mi comporto come sviluppatore, quindi non posso modificare i permessi dei file.

    
posta James 31.01.2016 - 19:55
fonte

4 risposte

22

Dalla tua descrizione non è chiaro il motivo per cui vuoi bloccare esattamente questi file. Vedo le seguenti possibilità:

  • Si desidera bloccare i file che potrebbero infettare il server stesso. Sfortunatamente questo può riguardare qualsiasi cosa: shell, perl, python, awk, ... e naturalmente binari compilati. Ma per ottenere questi file eseguiti senza chiamarli esplicitamente con un interprete, è necessario impostare il bit eseguibile, il che non dovrebbe essere il caso se il file viene caricato da un'applicazione web. Questo è almeno il caso dei sistemi UNIX, perché su Windows l'estensione è sufficiente e ci sono anche PoweShell, JavaScript, Batch e tutti gli altri file. Tuttavia, qualcosa deve almeno attivare l'esecuzione del file o avere la directory di upload nel percorso per le librerie DLL e condivise.
  • O vuoi bloccare i file che potrebbero essere eseguiti dal server web stesso, cioè dall'interno dell'applicazione web. Questi sono file PHP, ASP, CGI ... che verranno eseguiti tramite un URL e causare danni all'utente o al server. Ovviamente funziona solo se la directory di upload è raggiungibile da un URL o se l'autore dell'attacco riesce a uscire dalla directory di upload con attacchi path traversal o simili o se l'hacker gestisce un codice lato server per includere questi file (ad esempio l'inclusione di file locali) attacco).
  • O vuoi bloccare i file che potrebbero essere inclusi per offrire malware all'utente, ad esempio documenti PDF corrotti, reindirizzamento javascript a siti di malware. In questo caso hai probabilmente una directory di upload che è raggiungibile da un URL perché vuoi che gli utenti scarichino questi file. Sfortunatamente per tali file non solo il tipo di file che vedi è importante, ma anche il contesto in cui sono chiamati (cioè come immagine, script, css, oggetto ...) e non sei in grado di controllare questo utilizzo.

... but in this case I need to do a blacklist of files for many reasons,

Dato che ovviamente non sai quali file possono essere pericolosi, un tale tipo di lista nera non funzionerà mai. Ci saranno sempre tipi di file mancanti o l'autore dell'attacco nasconderà il suo file dietro un altro tipo, ovvero costruisca un poliglotta .

    
risposta data 31.01.2016 - 20:10
fonte
14

Non bloccare alcun tipo MIME specifico. Blocca qualsiasi tipo di esecuzione dei file caricati. Un modo semplice è quello di memorizzare i file caricati al di fuori della web root e servirli tramite script. Se ciò non è possibile, archivia i file in una sottodirectory e configura il server non eseguire script in quella directory . Ricordati di farlo per qualsiasi linguaggio di scripting che potrebbe essere abilitato sul server.

Se non è possibile modificare la configurazione per vari motivi, controllare il nome del file e farlo correttamente. Le stringhe PHP possono contenere byte NULL, i nomi dei file non possono, quindi se un utente malintenzionato carica un file chiamato "hack.php \ 0.jpg", potresti visualizzare l'estensione come ".jpg" che è valida, ma verrebbe salvata come "hack" .php ", rendendoti nuovamente vulnerabile. Controlla i caratteri in un nome file rispetto a una lista bianca.

    
risposta data 01.02.2016 - 04:17
fonte
6

Are there any other filetype that I also should block?

Non importa, dato che finfo_file può essere ignorato , vedi ad esempio qui: codifica gusci Web in blocchi IDAT PNG . mime_content_type non sembra essere più affidabile.

Devi controllare l'estensione del file oltre al controllo mimetype, poiché è molto più affidabile, poiché i nomi dei file sono molto meno complessi dei contenuti dei file.

Un ulteriore controllo di tipo mime è ancora una buona idea come difesa in profondità, per filtrare semplici attacchi. Come hai detto, una whitelist sarebbe l'approccio corretto , ma se hai sicuramente bisogno di andare con una lista nera, aggiungerei almeno i mimi del PHP alla blocklist:

  • text / php
  • text / x-php
  • application / php
  • application / x-php
  • application / x-httpd-php
  • application / x-httpd-php-source

Inoltre, hai davvero bisogno di esecuzione nella directory dei caricamenti? In caso contrario, rimuovilo per maggiore sicurezza.

    
risposta data 31.01.2016 - 20:13
fonte
2

Suggerisco una quarantena a breve termine di tutti i file caricati. È possibile utilizzare la scansione dei sistemi locali e gli strumenti AV in una prigione temporanea. In questo modo è possibile aggiungere una routine per cercare file dannosi e ignorare tutti i diversi nomi di file. Questo ferma il gioco whack-a-mole.

Ciò aggiungerebbe una certa latenza all'applicazione.

So che questa non è una soluzione di codifica, ma risolve i difetti fondamentali con la lista nera e non ti obbliga a regolare le autorizzazioni, come hai detto che non hai il controllo.

Mi sono imbattuto in un'applicazione che ha inserito nella lista nera il tuo modo di proporre. L'ho trovato mentre stavamo facendo l'analisi forense dopo che l'avversario aveva preso il controllo e si era nutrito dei beni aziendali per nove mesi. Se questo non è un buon motivo per fermare la lista nera, allora divertiti. Whack-Whack.

    
risposta data 02.02.2016 - 17:33
fonte

Leggi altre domande sui tag