¿Es posible ejecutar un script php en un archivo de imagen? [duplicar]

Las cargas de imágenes (cualquier archivo en general) son muy difíciles de hacer completamente seguras, especialmente en PHP, que proporciona muchos vectores de ataque.

Si, por ejemplo, muestra la imagen llamando

require($someImage);

y esa imagen tiene un código PHP dentro (como el que usted publicó), puede interpretarse y ejecutarse como tal.

Supongo que, si afirma que es el propietario de tu sitio, probablemente lo haya hecho. La imagen que ha proporcionado en sí misma no hará nada excepto imprimir "prueba bien", pero ese código podría intercambiarse fácilmente por algunos que le otorguen acceso no autorizado (incluso sin restricciones) a su sitio y servidor.

Para asegurarse de que el archivo cargado en su sitio sea en realidad una imagen, vuelva a procesarlo con GD (o Imagick) y guarde la imagen procesada. Es una mala práctica guardar la imagen original, especialmente utilizando el nombre del archivo original, ya que esto se abre para muchos otros ataques (por ejemplo, recorrido de directorios y sobrescritura de archivos).

Más información: enlace

Sí, su servidor podría ejecutar código PHP dentro de un archivo de imagen si no está configurado correctamente :

enlace

Un ejemplo de eso es image.gif.php . Un archivo puede ser tanto una imagen válida como y un script PHP válido, no es suficiente simplemente para verificar el tamaño de la imagen u otras propiedades. Tampoco es suficiente para metadatos de tira , un GIF sin comprimir puede contener PHP como datos de imagen (aunque puede ser unpretty), PNG admite fragmentos de datos arbitrarios .

El defecto es aceptar cargas con una comprobación de sanidad insuficiente, específicamente intentando evitar nombres de archivos no deseados (por ejemplo, .php ) mediante el uso de una expresión regular no anclada como \.(png|gif|jpg|jpeg) (no $ anchor), y permitiendo que esas imágenes sean servidas desde un directorio con el procesamiento de PHP habilitado. La mejor práctica es que probablemente nunca debe usar un nombre de archivo provisto por el usuario tal como está.

Estos son validación de datos bastante clásicos y errores de validación de entrada .

Si sigue las instrucciones de instalación de PHP (para Apache 2) , Ten algo como esto en tu configuración de Apache:

<FilesMatch "\.ph(p[2-6]?|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

Tenga en cuenta el ancla $ , esto evitará que PHP se interprete a file.php.gif . (Lo que falta en esas instrucciones es asegurarse de que PHP esté limitado por un contexto <Directory> que contenga solo código de confianza, y no pueda ser escrito por el usuario del servidor web ).

Si no sigue esas instrucciones y usa mod_mime 's AddType (o AddHandler ) en su lugar:

AddType application/x-httpd-php .php      # STOP! 

Esto puede causar el mismo problema porque mod_mime puede hacer algo que no espera con multiples extensiones. Consulte enlace (gracias a Hendrik Brummermann por señalar) esto afuera). Este riesgo se puede mitigar con el contexto <Directory> configurado correctamente para permitir solo el código de confianza.

Este documento (PDF) es un poco antiguo, pero cubre bien las mitigaciones: enlace

Otra posible fuente de problemas son las declaraciones inseguras include / require (también cubiertas en ese PDF) que permiten que un atacante include cargue contenido al modificar cadenas de consulta o encabezados de solicitud HTTP.

Consulte también la reciente pregunta relacionada: Riesgos de una carga de imagen PHP forma (aunque no creo que sea correcto confiar en getimagesize para verificar las imágenes), y ¿Usa PHP para revisar el archivo de imagen cargado en busca de malware? (que contiene un conjunto útil de enlaces).

Voy a asumir que estás ejecutando LAMP (y una respuesta para otras configuraciones de php sería muy similar).

Lo más probable es que su código no pueda hacer nada en tu sitio .

Digamos que Apache está sirviendo archivos de /var/www en su servidor. Di que alguien visita index.php en tu sitio web.

1. Apache recibirá que están buscando /index.php
2. Apache buscará el archivo /var/www/index.php

3. Si Apache está ejecutando mod_php, entonces verificará si index.php coincide con una regla en el archivo de configuración mod_php de alguna manera. Su archivo de configuración mod_php (probablemente en /etc/apache2/mods-available/php5.conf ) es probablemente un superconjunto de este ejemplo mínimo que he creado a continuación:

   <IfModule mod_php5.c>
       <FilesMatch ".+\.ph(p[345]?|t|tml)$">
           SetHandler application/x-httpd-php
       </FilesMatch>
   </IfModule>
   

   • Si el nombre del archivo coincide, Apache ejecutará el archivo a través de un intérprete php, creando una página web que servirá al usuario.
   • Si el nombre del archivo no coincide, Apache solo se lo entregará al usuario.
   • (Estos detalles omiten muchos bits de apache que no creo que sean relevantes aquí)

Supongamos que un usuario carga una imagen, por ejemplo, evil_image.png , y tiene un código PHP arbitrario.

También digamos que lo sirve a usuarios de algún lugar, por ejemplo, en /images/evil_image.png (por lo tanto, dentro de su sistema de archivos, /var/www/images/evil_image.png ).

Cuando alguien intenta recuperar esta imagen accediendo a su sitio web en /images/evil_image.png , Apache ejecutará los pasos que describí anteriormente. En el paso 3, /images/evil_image.png no coincidirá con el patrón de su archivo de configuración, por lo que no ejecutará el código como php . Simplemente servirá la imagen al usuario.

El usuario recibirá el archivo de imagen que tiene el texto malicioso guardado en él. Lo importante es que su servidor no ha intentado ejecutar el código, por lo que resulta ineficaz .

No estoy diciendo que sea imposible ejecutar ese código. Le diré que debe perderse profundamente la configuración de su servidor web para que ese código se ejecute.