Come difendere l'inclusione di file remoti di immagini, ad es. RFI usando un file .gif (Apache / PHP)?

Utilizzare le funzioni GD per convertire è un buon modo per risolvere il problema, ma aggiunge un sovraccarico come hai notato. Inoltre perché usi include?

Suppongo che tu abbia fatto tutte le solite attenuazioni:

• Consenti solo determinate estensioni e controlla contro di loro
• Utilizza nomi di file casuali
• usa getimagesize ()
• Controlla il tipo di contenuto

Altre cose che potresti provare

• disabilita l'esecuzione dei file php nella directory di caricamento dell'immagine
• utilizzare un dominio separato per caricare le immagini o memorizzarle al di fuori del webroot

Il tuo codice PHP non dovrebbe mai valutare un file di dati. Può stampare il contenuto di un file immagine, ma include() in un file immagine è un uso folle del codice. Suppongo strongmente che quello che stai facendo sia utilizzare il codice PHP per servire le immagini, e poiché PHP non valuta nulla che non sia tra i tag "<? ?>" , questo funziona nella maggior parte dei casi. Questo è sicuramente l'approccio sbagliato.

Forse stai cercando la funzione readfile() .

Oltre a questo, non scrivere include istruzioni che prendono input esterni.

Faccio fatica a pensare a uno scenario in cui l'uso di include() , per includere < em> e valutare / eseguire un file immagine, come parte di un altro file PHP è uno scenario valido, quando è necessario?

Potresti approfondire lo scenario?

Se è necessario include() di un file, verrà valutato. E poiché molti formati di immagine consentono di aggiungere commenti, il file potrebbe contenere comandi PHP validi. Quindi la difesa potrebbe essere quella di copiare i contenuti / dati dell'immagine, e memorizzarla in un nuovo file o rimuovere i commenti.

La compressione lossy è molto probabilmente un overkill (anche se penso che dovrebbe essere possibile creare un'immagine che contenga codice operativo che verrà interpretato come PHP valido includendolo mentre allo stesso tempo è un'immagine valida; sapere se sarebbe sopravvissuto a una copia dell'immagine senza perdita intatta).

Se stai parlando di immagini caricate che contengono codice PHP che viene eseguito dal server web al momento di servire le immagini, la difesa è molto più semplice:

• Non consentire l'estensione di estensioni di file diverse da .php come PHP.
  Se hai bisogno di PHP dinamico creato .png -files, rinominale .png.php e utilizza la riscrittura degli URL per nascondere .php sul lato client.
• Sposta le immagini caricate (o qualsiasi altro file) in una directory configurata per essere ignorata da PHP.
• Non memorizzare mai file caricati con il loro nome originale.

Il modulo Suhosin Hardened-PHP ha una certa protezione contro Remote File Include (RFI) / File locale Includi (LFI) attacchi. La configurazione open_basedir di PHP può essere utilizzata per prevenire attacchi LFI. Come forzare PHP a includere da una directory che è di sola lettura. RFI può essere completamente prevenuto impostando allow_url_include=Off , e questo è stato predefinito per un certo numero di anni.

Indurire le tue configurazioni è un buon approccio difensivo in profondità. Ma non è un sostituto per testare il software e patch delle vulnerabilità note. Il progetto w3af è open source e può essere utilizzato per testare le vulnerabilità LFI / RFI. Sitewatch è quello che uso per assicurarmi che le mie applicazioni web siano sicure.

1. Non utilizzare PHP, JSP, JSPX, ASP o ASPX
2. Non consentire caricamenti di file, in particolare immagini
3. Non utilizzare alcuna funzione o classe di gestione dei file

Non sei sicuro di PHP, ma se i tuoi file di immagine sono in una cartella di immagini, puoi usare un .htaccess per bloccare tutte le richieste che non provengono dai tuoi siti. (Intestazione del referrer HTTP)