Cómo defenderse frente a la inclusión remota de archivos de imagen, por ejemplo, RFI usando un archivo .gif (Apache / PHP)?

Usar las funciones de GD para convertir es una buena manera de resolver el problema, pero agrega sobrecarga como notaste. Además, ¿por qué usas incluir?

Supongo que has hecho todas las mitigaciones habituales:

• Solo permite ciertas extensiones y verifica contra ellas
• Usa nombres de archivos aleatorios
• usa getimagesize ()
• Verificar el tipo de contenido

Otras cosas que puedes probar

• deshabilita la ejecución de archivos php en el directorio de carga de imágenes
• use un dominio separado para cargar las imágenes o almacenarlas fuera de webroot

Su código PHP nunca debe evaluar un archivo de datos. Puede imprimir el contenido de un archivo de imagen, pero include() ing un archivo de imagen es un uso insano del código. Supongo firmemente que lo que estás haciendo es usar el código PHP para servir imágenes, y como PHP no evalúa nada que no esté entre las etiquetas "<? ?>" , esto funciona en la mayoría de los casos. Este es definitivamente el enfoque equivocado.

Puede que estés buscando la función readfile() .

Aparte de eso, no escriba declaraciones que incluyan información externa.

Me cuesta pensar en un escenario donde el uso de include() , para incluir < em> y evalúe / ejecute un archivo de imagen, como parte de otro archivo PHP es un escenario válido, ¿cuándo lo necesita?
¿Podrías elaborar sobre el escenario?

Si necesita include() un archivo, se evaluará. Y como muchos formatos de imagen permiten agregar comentarios, el archivo podría contener comandos PHP válidos. Por lo tanto, la defensa sería copiar el contenido / los datos de la imagen y almacenarlo en un nuevo archivo o eliminar los comentarios.

Lo más probable es que la compresión con pérdida sea una exageración (aunque supongo que debería ser posible falsificar una imagen que contenga un código de operación que se interpelará como PHP válido al incluirla y al mismo tiempo ser una imagen válida; no lo hago. saber si sobreviviría a una copia de la imagen sin pérdida intacta).

Si está hablando de imágenes cargadas que contienen código PHP que ejecuta el servidor web al servir las imágenes, la defensa es mucho más fácil:

• No permita que las extensiones de archivo que no sean .php se interpeneten como PHP.
  Si necesita crear un archivo dinámico .png -files, cámbieles el nombre .png.php y use la reescritura de URL para ocultar el .php en el lado del cliente.
• Mueva las imágenes cargadas (o cualquier otro archivo) a un directorio configurado para ser ignorado por PHP.
• Nunca almacene los archivos cargados con su nombre original.

El módulo Suhosin Hardened-PHP tiene cierta protección contra la inclusión de archivos remotos (RFI) / Local File Incluir ataques (LFI). La configuración open_basedir de PHP se puede usar para prevenir ataques de LFI. Como forzar a PHP a incluir desde un directorio que es de solo lectura. La RFI se puede prevenir completamente estableciendo allow_url_include=Off , y esto ha sido predeterminado por varios años.

El endurecimiento de sus configuraciones es un buen enfoque de defensa en profundidad. Pero no es un sustituto para probar su software y parchar vulnerabilidades conocidas. El proyecto w3af es de código abierto y se puede usar para probar vulnerabilidades de LFI / RFI. Sitewatch es lo que uso para asegurarme de que mis aplicaciones web son seguras.

1. No utilice PHP, JSP, JSPX, ASP o ASPX
2. No permitir ninguna carga de archivos, especialmente imágenes
3. No utilice ninguna función o clase de manejo de archivos

No estoy seguro acerca de PHP, pero si sus archivos de imagen están en una carpeta de imágenes, puede usar un .htaccess para bloquear todas las solicitudes que no provengan de sus propios sitios. (Encabezado de referencia HTTP)