Nello scenario del mio avatar di caricamento dell'utente, cambio l'estensione immagine dell'utente in jpg. Questo sta facendo in modo che i browser agiscano in modo diverso? È incline all'errore per i browser quando leggono gli avatar degli utenti? Inoltre, rende la mia app web più sicura quando un utente malintenzionato carica un file php?
Quando carichi i file, devi assicurarti che l'estensione del file sia quella che approvi, altrimenti nota come approccio alla lista bianca. Non dovresti rinominare ogni estensione in .jpeg, questo causerà problemi. La maggior parte degli HTTPD imposterà il tipo mime in base all'estensione del file, che informa il browser su come decodificare il contenuto.
C'è un altro problema con i caricamenti di file. Apache "ricadrà" sulla seconda estensione di file se non ha un tipo mime per la prima estensione di file. Quindi, per impostazione predefinita, backdoor.php.fjfl verrà eseguito come file .php, Ouch. Raccomando di rinominare il file, come per la chiave primaria, oltre ad avere una lista bianca di estensioni di file.
Anche se l'utente sta caricando un'immagine valida, può comunque causare problemi di sicurezza. Ad esempio, i metadati delle immagini potrebbero contenere un tag php, che è utile per trasformare un semplice File locale Includi vulnerabilità nell'esecuzione di codice in modalità remota .
Come @Rook ha detto che non dovresti cambiare l'estensione in quanto potrebbe causare problemi. Ha anche sottolineato che i metadati potrebbero contenere dati dannosi, il che è molto vero. Quindi ecco i passi che dovresti seguire, più o meno:
Nel caso in cui uno dei controlli sopra riportati fallisse, basta interrompere il processo ed eliminare il file e restituire un semplice messaggio di errore che spiega che l'immagine non è buona.
(1) Non utilizzare mai alcuna parte di un nome file inviato dall'utente nel nome file memorizzato. La disinfezione di un nome file è un lavoro infido, non facile da fare in modo affidabile come sembra, soprattutto se l'app potrebbe finire in esecuzione su un server Windows e Linux.
Memorizzalo come qualcosa come 2395862.jpeg , con il nome del file derivato ad esempio dalla chiave primaria dell'entità database correlata.
Se devi presentare un nome "amichevole" al browser finale, utilizza una riscrittura per poterlo pubblicare come /avatar/2395862/anyname.jpeg mentre è effettivamente memorizzato come 2395862.jpeg .
(2) Assicurati di memorizzare i file in una directory separata che non contenga nient'altro. Questa directory dovrebbe essere l'unica a cui l'utente di script Web ha accesso in scrittura. Dovrebbe avere le autorizzazioni bloccate in modo che solo i file statici possano essere serviti da esso. Su Apache questo dovrebbe essere fatto da un% di livello superiore.htaccess o httpd.conf e le sostituzioni disattivate in modo che non sia possibile scrivere un file .htaccess in questa directory per avere alcun effetto.
(3) È possibile che i file caricati dall'utente contengano contenuti che si mascherano come un tipo diverso. Ad esempio, in alcuni browser la presenza di tag HTML nel file potrebbe indurli a considerare il file come un documento HTML, incluso JavaScript. I plug-in possono anche interpretare erroneamente i file con conseguente cross-site scripting (vedi l'attacco GIFAR per un esempio).
Per questo motivo, dovresti considerare che qualsiasi repository di file caricati dall'utente sia compromesso per lo scripting cross-site e attenuarlo servendo tutti i file caricati dall'utente da un dominio diverso. In questo modo, qualsiasi script immesso non sarà in grado di eseguire il cross-site-script nel tuo sito Web principale. Assicurati che non ci sia modo di accedere alle risorse caricate dagli utenti dal tuo sito web principale.
Il sito separato per le risorse utente può essere un dominio completamente diverso o può essere un sottodominio. Ma se si tratta di un sottodominio, devi assicurarti che non ci sia nulla nel dominio genitore: quindi se offri risorse utente da avatars.myforum.com il tuo forum principale può essere a www.myforum.com ma non deve essere a myforum.com . In caso contrario i browser condivideranno i cookie tra loro.
Leggi altre domande sui tag web-browser file-upload