La modifica dell'estensione di un file eseguibile caricato in .png lo rende sicuro?

Ci sono fondamentalmente due modi principali in cui un file caricato può essere dannoso: eseguendolo (come script o binario) o eseguendolo / utilizzato in un'applicazione e abusando di un exploit in esso contenuto (ad esempio un MP3 caricato che viene poi aperto da un giocatore specifico, abusando di una nota debolezza in esso).

In altre parole, tutto dipende da cosa succede con il file dopo il caricamento. Se qualcuno è in grado di caricare uno script Perl, ma il server non esegue mai i file caricati o addirittura non ha installato Perl, nulla può mai accadere. In generale: se ti assicuri che il file caricato non venga mai eseguito o interpretato, sarai al sicuro.

Rinominare i file aiuta solo con una cosa: su alcuni sistemi operativi, alcune estensioni di file possono essere collegate con un'applicazione specifica. Se si rinomina il file, è possibile impedire che il file venga aperto con un'applicazione collegata. Ma a seconda del sistema e della configurazione, i file caricati potrebbero ancora essere aperti con un'applicazione vulnerabile. Per rimanere nell'esempio sopra: se un file caricato viene aperto con un lettore MP3, anche se lo si rinomina in song.png , sarebbe comunque in grado di sfruttare un punto debole nel lettore (a meno che il giocatore abbia il proprio livello di controllando e ad esempio accetta solo .mp3 file).

I file rinominati non sono immagini improvvisamente, solo per la ridenominazione. Su Unix e sistemi simili, c'è persino il comando file per analizzare il tipo / tipo MIME di un file.

Conclusione: ai miei occhi c'è solo una cosa che puoi fare. Sii molto specifico nel tuo setup su cosa può e sarà fatto con i file caricati. Qualsiasi libreria, estensione o applicazione che accetta questi file dovrebbe sempre essere aggiornata alla versione più recente.

No. Rinominare un file non aumenta la sicurezza.

He says to me, that by making all files images no harm can be done to the server.

for example evilscript.evil would become evilscript.png

Quando rinomini evilscript.evil in evilscript.png non lo trasformi in un'immagine. Cambia semplicemente il suo nome. Generalmente, il nome di un file non è rilevante. È solo un nome dato a un blocco di dati, niente di più.

Se puoi eseguire uno script caricato, probabilmente lo puoi fare indipendentemente dal suo nome. Se non è possibile, il caricamento di uno script dannoso non danneggia il sistema, poiché lo script non verrà comunque eseguito.

Tuttavia, può impedire l'esecuzione accidentale di un file. L'unica protezione che la ridenominazione potrebbe fornire è la protezione dall'avvio accidentale da parte di Windows Explorer (o una shell che utilizza analogamente le estensioni di file). In questo modo, rinominare virus.exe in virus.exe~ aiuta effettivamente, quando accidentalmente tocchi Invio su di esso.

Le shell Unix usano i formati di file invece delle estensioni. Ad esempio, puoi salvare uno script come evilscript.png ed eseguirlo con una shell Linux, a condizione che il file abbia il permesso "execute". In termini di sicurezza, in genere è meglio controllare i permessi dei file invece dei nomi di file.

Il controllo dell'unica estensione di un file caricato non è sufficiente. Ad es .: verifica la risposta su questa domanda .

Una proposta: esiste un modo più affidabile per scoprire il tipo di un file. Se il tuo amico sta eseguendo il server su un computer Unix, puoi utilizzare il comando " file " che controlla il contenuto del file per determinare il formato.

Esistono due problemi, che proteggono dagli attacchi diretti sul server e proteggono dagli attacchi di altri client (che a loro volta possono portare ad attacchi al server)

Prima il server, quando un client richiede un file, il server deve decidere se servirlo o eseguirlo in qualche modo. Questa descrizione può dipendere da vari fattori, tra cui.

1. L'estensione del file
2. La directory in cui si trova il file
3. Indica se il bit eseguibile è impostato.

Non sono a conoscenza di server Web che eseguono il controllo dei contenuti sul lato server, ma non posso escludere che uno possa esistere.

Idealmente sul server non metterei i file forniti dall'utente in una directory in cui l'esecuzione dello script è consentita in primo luogo, ma limitare l'estensione del file è probabilmente una ragionevole politica di "difesa in profondità" nel caso in cui un file inavvertitamente finisca nel posto sbagliato.

Se il server decide di servire il file, deve decidere quale tipo di mime inviare. I server Afaict di solito scelgono il tipo mime in base all'estensione del file. Il cliente deve quindi decidere cosa fare con il file. Dovrebbe basarlo sul tipo mime inviato dal server ma in pratica potrebbe invece basarlo sull'estensione del file o sul controllo del contenuto del file,

Se il browser sceglie di trattare il file come un tipo che può coinvolgere lo scripting lato client, diventa importante il dominio da cui viene servito il file. Se il file è servito dal tuo dominio principale, è probabile che lo script legga i cookie che hai impostato e li usi per impersonare l'utente.

Credo che una restrizione dell'estensione del file debba far parte della strategia di sicurezza, ma non dovrebbe essere tutto. L'archiviazione in directory che vietano l'esecuzione di script, l'applicazione di contenuti che corrispondono all'estensione e l'uso di un nome di dominio separato devono essere tutti considerati parte della strategia di difesa complessiva.

Questo è sicuro.

Si può sempre introdurre codice eseguibile all'interno di un'immagine:

• Carica il tuo codice PHP con un'altra estensione.
• Inseriscilo nei metadati, ad esempio EXIF.
• Usa pixel colorati in modo specifico in modo che la loro rappresentazione binaria sia il codice PHP desiderato, che sopravviverà alla ricodifica (l'ho visto in realtà nella realtà, sfruttato usando: link ).

Quindi dovresti già presumere che i contenuti del tuo file non siano sicuri quando sono forniti dall'utente. Anche se ricodifichi l'immagine, e anche se converti i formati, è ancora un'immagine quindi non eseguirla maleducata . Se il tuo server web (come Apache o Nginx) lo esegue tramite l'interprete PHP, allora qualcuno troverà un modo per far sì che PHP faccia qualcosa di brutto. Forzando l'estensione come una delle poche estensioni della whitelist, puoi dire al tuo server web che si tratta di un'immagine (non eseguibile) e che non dovrebbe passare attraverso l'interprete.

Ci sono, ovviamente, alcuni rischi correlati a cui prestare attenzione:

• Il tuo utente potrebbe inserire byte nulli o altre cose divertenti nel nome del file, il che potrebbe consentire loro di scegliere la propria estensione dopotutto.
• Il tuo utente potrebbe provare a utilizzare il path traversal se gli permetti di scegliere il nome del file, il che potrebbe consentire loro di fare ogni sorta di cose.
• Potresti commettere un errore nella configurazione del server web e tutto viene eseguito attraverso l'interprete indipendentemente dall'estensione (l'ho già visto prima: è un bug silenzioso, perché PHP emette letteralmente tutto ciò che non riconosce, quindi le immagini sembrerà lo stesso prima e dopo l'interpretazione di PHP).
• Il file potrebbe contenere un exploit per un decodificatore specifico, ad esempio se sai che l'amministratore potrebbe visualizzare la tua immagine e che utilizza un browser che ha un visualizzatore PNG vulnerabile, potresti caricare un'immagine PNG che sfrutta tale vulnerabilità.

I primi due sono facilmente risolvibili: non lasciare mai che l'utente scelga il proprio nome file o almeno un elenco di caratteri che sono sicuramente sicuri, come ^[a-zA-Z0-9_-]*$ (alfanumerico, trattino basso e trattino).

Il terzo può essere controllato inserendo un file chiamato "test.png" e inserendo <?php echo "test1"; in esso. Quando si richiede il file tramite curl, si dovrebbe vedere il codice completo. Se vedi solo "test1", allora è vulnerabile.

Infine, l'ultimo è difficile da controllare e alquanto fuori portata. È possibile utilizzare uno scanner di virus sul lato server, ma gli scanner antivirus catturano solo alcuni casi comuni e di solito non sono in grado di rilevare tutte le varianti di una vulnerabilità, se sono a conoscenza della vulnerabilità in primo luogo. L'utente dovrebbe, idealmente, aggiornare il proprio sistema e non eseguire software vulnerabili. Ma se ti trovi in un ambiente ad alta sicurezza, dovresti applicare la difesa in profondità e fare cose come ricodificare l'immagine, forse solo permettere agli utenti di visualizzare le immagini in una macchina virtuale, ecc. Ma questo è fuori portata per questa domanda .

Riepilogo: ci sono alcuni attacchi correlati che non hai dimostrato di essere mitigati, ma considerando solo lo snippet di codice pubblicato: quella parte è sicura.