Ho un sito Web di php per caricare le immagini. Gli utenti possono caricare immagini sul mio sito web. Un utente afferma di poter hackerare il mio sito Web utilizzando un'immagine caricata.
Ho aperto tutte le immagini che ha caricato sul mio server con il blocco note. L'ultima riga di un'immagine è:
Àpa@ ;
<?php
echo "test ok";
?>
Può hackerare il mio sito web usando questa immagine? Come impedisco agli utenti di caricare immagini come questa?
I caricamenti di immagini (qualsiasi file in generale) sono molto difficili da rendere completamente sicuri - specialmente in PHP, che fornisce molti vettori di attacco.
Se, ad esempio, visualizzi l'immagine chiamando
require($someImage);
e quell'immagine ha codice PHP all'interno (come quello che hai postato), può essere interpretata ed eseguita come tale.
La mia ipotesi è che, se afferma di essere il proprietario del tuo sito, probabilmente lo ha fatto. L'immagine che hai fornito di per sé non farà nulla se non stampare "test ok", ma quel codice potrebbe essere facilmente scambiato per alcuni che forniscono accesso non autorizzato (anche completamente illimitato) al tuo sito e al tuo server.
Per assicurarti che il file caricato sul tuo sito sia effettivamente un'immagine, rielaborala usando GD (o Imagick) e salva l'immagine elaborata. È una cattiva pratica salvare l'immagine originale, specialmente usando il nome del file originale, in quanto si apre a molti altri attacchi (ad esempio directory traversal e sovrascrittura di file).
Ulteriori informazioni: link
Sì, il tuo server potrebbe eseguire codice PHP all'interno di un file immagine se non è configurato correttamente :
Un esempio è image.gif.php . Un file può essere sia un'immagine valida che uno script PHP valido, non è sufficiente controllare semplicemente la dimensione dell'immagine o altre proprietà. Né è sufficiente per strip metadata , una GIF non compressa può contenere PHP come dati di immagine (sebbene possa essere non utile), PNG supporta blocchi di dati arbitrari .
La falla sta accettando caricamenti con un controllo insufficiente della sanità, in particolare tentando di impedire nomi di file indesiderati (ad esempio .php ) utilizzando una espressione regolare non ancorata come \.(png|gif|jpg|jpeg) (nessuna $ ancora), e consente di pubblicare le immagini da una directory con l'elaborazione PHP abilitata. La migliore pratica è che probabilmente non dovresti mai usare un nome utente fornito come-è.
Questi sono abbastanza classici convalida dei dati e input validation errori.
Se segui le istruzioni di installazione di PHP (per Apache 2) avere qualcosa di simile nella configurazione di Apache:
<FilesMatch "\.ph(p[2-6]?|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
Nota l'ancora $ , impedirà che file.php.gif venga interpretato da PHP.
(Quello che manca da quelle istruzioni è assicurarsi che PHP sia limitato da un contesto <Directory> contenente solo codice attendibile e non scrivibile dall'utente del server web .)
Se non segui queste istruzioni e utilizzi mod_mime AddType (o AddHandler ) invece:
AddType application/x-httpd-php .php # STOP!
Questo può causare lo stesso problema perché mod_mime può fare qualcosa che non ti aspetti con più estensioni. Vedi link (grazie a Hendrik Brummermann per indicare questo fuori). Questo rischio può essere mitigato con il contesto <Directory> configurato correttamente per consentire solo il codice attendibile.
Questo documento (PDF) è un po 'vecchio, ma copre bene le mitigazioni: link
Un'altra possibile fonte di problemi è costituita da istruzioni include / require non sicure (anch'esse trattate in quel PDF) che consentono a un utente malintenzionato di caricare% content% di contenuto co_de alterando stringhe di query o intestazioni di richieste HTTP.
Vedi anche la recente domanda correlata: Rischi di un caricamento di immagini PHP formare
(anche se non penso sia corretto affidarsi a include per verificare le immagini), e
Usa PHP per controllare il file di immagine caricato per malware? (che contiene un insieme utile di collegamenti).
Suppongo che tu stia eseguendo LAMP (e una risposta per altre configurazioni di php sarebbe molto simile).
Molto probabilmente, il suo codice non può fare nulla per il tuo sito .
Supponiamo che Apache stia servendo file fuori /var/www sul tuo server. Dì che qualcuno visita index.php sul tuo sito web.
/index.php
/var/www/index.php
Se Apache sta eseguendo mod_php, controllerà se index.php corrisponde a una regola nel file di configurazione mod_php in qualche modo. Il tuo file di configurazione mod_php (probabilmente a /etc/apache2/mods-available/php5.conf ) è molto probabilmente un superset di questo esempio minimale che ho creato qui sotto:
<IfModule mod_php5.c>
<FilesMatch ".+\.ph(p[345]?|t|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
</IfModule>
Diciamo che un utente carica un'immagine, diciamo evil_image.png , e contiene un codice PHP arbitrario.
Diciamo anche che lo servi agli utenti da qualche parte, ad esempio in /images/evil_image.png (quindi all'interno del tuo filesystem, /var/www/images/evil_image.png ).
Quando qualcuno cerca di recuperare questa immagine accedendo al tuo sito web a /images/evil_image.png , Apache eseguirà i passaggi che ho descritto sopra. Al passaggio 3, /images/evil_image.png non corrisponde allo schema dal tuo file di configurazione, quindi non eseguirai il codice come php . Servirai semplicemente l'immagine all'utente.
L'utente riceverà il file immagine contenente il testo malevolo memorizzato al suo interno. Ciò che è importante è che il tuo server non abbia provato a eseguire il codice, rendendolo inefficace .
Non sto dicendo che è impossibile che quel codice sia eseguito. Ti dirò che devi assolutamente perdere la configurazione del tuo server web per far sì che quel codice venga eseguito.
Leggi altre domande sui tag php webserver web-application