Recreando subidas / imágenes vinculadas con imágenes creadas desde * php

6

Según lo sugerido en mi pregunta StackOverflow , ahora dirijo esto hacia el grupo de Seguridad de la Información, ya que nadie pudo responder mi pregunta a pesar de los múltiples votos ascendentes.

Las imágenes subidas por el usuario representan una gran parte del contenido del sitio en el que estoy trabajando. Intenté almacenarlos fuera de webroot y buscarlos con readfile() por razones de seguridad, pero fue demasiado lento, así que tuve que volver al método anterior.

Ahora estoy buscando asegurarme de que todas las subidas estén saneadas al 100% ya que se almacenarán dentro de webroot. Mi pregunta es, si un usuario cambiara el nombre de un script dañino a .jpg, .gif, .png o .bmp y lo subiera, ¿seguiría siendo dañino cuando se ejecutara o buscara si la imagen se recreaba con una función como esta? :

function imageCreateFromAny($filepath) { 
    $type = exif_imagetype($filepath); // [] if you don't have exif you could use getImageSize() 
    $allowedTypes = array( 
        1,  // [] gif 
        2,  // [] jpg 
        3,  // [] png 
        6   // [] bmp 
    ); 
    if (!in_array($type, $allowedTypes)) { 
        return false; 
    } 
    switch ($type) { 
        case 1 : 
            $im = imageCreateFromGif($filepath); 
        break; 
        case 2 : 
            $im = imageCreateFromJpeg($filepath); 
        break; 
        case 3 : 
            $im = imageCreateFromPng($filepath); 
        break; 
        case 6 : 
            $im = imageCreateFromBmp($filepath); 
        break; 
    }    
    return $im;  
} 

En otras palabras, ¿existe alguna forma de engañar a una de las funciones imagecreatefrom* para que ejecute el contenido como un script en lugar de una imagen o incluso un script dañino que se haya ejecutado se reduciría a una imagen rota?

Actualizar También verificaré los tipos de archivos y las extensiones, pero quería saber si el usuario logró omitirlos, este último recurso ayudaría a proteger a mi servidor y / o clientes de alguna manera. Gracias.

    
pregunta DanL 07.03.2016 - 15:09
fuente

3 respuestas

4
  

¿incluso un script dañino que se haya ejecutado a través de esto se reduciría a una imagen rota?

No, cualquier código dañino en la imagen sigue ahí.

Pero si es seguro realmente depende de lo que haga con la salida de imageCreateFromAny .

Por sí solo, imageCreateFromX no hace nada a la imagen. No lo vuelve a crear, solo crea un identificador de recurso de imagen, por lo que si lo desea, puede cambiar aún más la imagen. Pero se conserva cualquier código dañino dentro de la imagen.

Su exif_imagetype check puede omitirse fácilmente , por lo que no garantiza que la imagen no contenga código dañino.

Entonces, si no verifica la extensión del archivo y usa su función, por ejemplo, de esta forma: imagepng(imageCreateFromAny($imageName), $imageName); , entonces eso sería inseguro.

  

¿hay alguna forma de engañar a una de las funciones imagecreatefrom* para que ejecute el contenido como un script?

Esperemos que no. Eso no sería una vulnerabilidad en su código, sino una vulnerabilidad en el propio PHP.

Entonces, ¿cuál es la solución? ¿Cómo puede asegurarse de que la imagen cargada no contenga ningún código dañino? Dos ideas vienen a la mente:

respondido por el tim 07.03.2016 - 15:49
fuente
1

Este método solo reduce la medida en que los datos de la imagen interactúan con el PHP que lo procesa, pero el archivo que interactúa con algo que tiene una superficie de ataque mucho mayor que el archivo de lectura () lo hace.

También validar el contenido es seguro para su servidor web, no significa que sea seguro para el cliente.

Almacenarlos dentro de webroot conlleva riesgos adicionales: el tiempo de ejecución de PHP buscará felizmente cualquier archivo que se le envíe para el código PHP y luego lo ejecutará. El código que has agregado aquí no hace nada para evitar eso. El código PHP se introduce en el tiempo de ejecución de PHP a través de 2 rutas, ya sea como lo asigna el servidor web (normalmente se basa en la presencia de una URL que se resuelve con un nombre de archivo que termina en '.php') o incluye / require / eval / create_function, etc. Código PHP.

Puede agregar capas de protección contra el primer método mediante

  • no permitir que los archivos cargados tengan una extensión .php
  • restringir las cargas a un árbol de directorios designado donde el traspaso de PHP está deshabilitado en el servidor web
  • cargar el contenido a la raíz del documento de un servidor web independiente que no tiene PHP en absoluto

Las capas de defensa para el segundo método son un poco más complicadas y costosas: auditorías de código, suexec, desactivación de algunas funciones php, bloqueo de la caché de código de operación.

Una herramienta útil, para la cual ya has hecho la mitad del trabajo duro en tu código y que proporciona protección para los clientes es convertir el archivo; si es un BMP o GIF convertir a un PNG. Para JPeg, use webp (si sus usuarios lo pueden tolerar), etc. Aunque esto no será completamente a prueba de balas, va un largo camino para eliminar ataques de ataques.

El código que nos ha mostrado solo lee el contenido y comprueba que es un formato de imagen válido. El malware, incluido el malware escrito en PHP, se puede integrar en cualquiera de estos formatos de archivo. Su código no determina si se debe aceptar contenido que no sea verificar que el formato del archivo sea correcto, ni muestra que el contenido se modifique de ninguna manera.

En su estado actual, no está agregando mucho valor.

    
respondido por el symcbean 07.03.2016 - 17:22
fuente
0

Creo que no hay forma de ejecutar un script a través de sus imágenes, pero recuerde que los ataques de malware y nuevas técnicas se descubren todos los días, entonces, debe implementar diferentes niveles de defensa. Te recomiendo lo siguiente:

  1. Implementar validaciones: establece un límite de tamaño, un formato de nombre de archivo y el tipo de extensiones. Las validaciones son muy importantes, ya que es el primer punto de ataque, por ejemplo, un ataque de inyección nula, alguien puede crear un archivo llamado "script.sh% 00img.bmp" y podría ejecutarse en su servidor. Recuerde que las validaciones deben estar en el servidor secundario.
  2. Implementar mecanismos anti-automatización, como un CAPTCHA. Podría reducir el riesgo de ataques de denegación de servicio con este tipo de mecanismos de seguridad.
  3. Endurecimiento del servidor web: establezca un directorio aislado para sus archivos, establezca los permisos correctos, por ejemplo, no establezca permisos de ejecución para sus archivos, mensajes de error personalizados y páginas de error y las acciones cuando se presente un error y otras configuraciones más.

Espero que esta información te ayude.

Buena suerte.

    
respondido por el hmrojas.p 07.03.2016 - 16:37
fuente

Lea otras preguntas en las etiquetas