2009-09-28 12 views
7

¿Cuáles son los principales problemas de seguridad al considerar la carga de imágenes, más allá de lo normal para todas las cargas HTTP?Problemas de seguridad al aceptar cargas de imágenes

Estoy aceptando cargas de imágenes, y luego mostrar esas imágenes a otros usuarios.

¿Cómo debo verificar, por ejemplo, que la imagen cargada es en realidad un archivo de imagen válido? ¿Existen vulnerabilidades conocidas en los espectadores que sean explotables por archivos de imagen malformados por los que me preocupe la posibilidad de transmitir accidentalmente exploits? (Rápidamente google parece mostrar que hubo una vez en IE5/6.)

¿Debo eliminar todos los metadatos de imágenes para ayudar a los usuarios a prevenir las divulgaciones de información no intencional? ¿O hay algunas cosas que son seguras, necesarias o útiles para permitir?

¿Hay alguna característica misteriosa de los formatos de imagen comunes que podrían ser vulnerabilidades de seguridad?

¿Hay bibliotecas que se ocupen de estos problemas? (Y/o con otros problemas como convertir archivos JPEG progresivos a JPEG normales, reducir la resolución para estandarizar tamaños, optimizar PNG, etc.)

Respuesta

2

Algunas cosas que aprendí recientemente de un web security video:

  • la opción nuclear es servir a todo el contenido cargado desde un dominio separado, que sólo sirve contenido estático - todas las características están deshabilitados y no se almacena nada importante allí.
  • Teniendo en cuenta el procesamiento de imágenes a través de imagemagick, etc. para eliminar el negocio divertido.
  • Para ver un ejemplo de lo que enfrenta, busque GIFAR, una técnica que coloca un GIF y Java JAR en el mismo archivo.
+0

Su primera opción no es fácil de conseguir para la mayoría de las personas, ya que supone que tiene un servidor completamente separado que no está relacionado de ninguna manera con la principal (contraseñas, etc.), y también es un poco inútil, dependiendo del objetivo de un atacante. –

+1

¿Qué calificador habría sugerido en lugar de "opción nuclear"? –

2

Su mayor riesgo es que un atacante intente cargar algún tipo de código ejecutable en su servidor. Si el archivo cargado se puede examinar en la web, el atacante puede hacer que el código se ejecute en su servidor. Su mejor protección es guardar primero el archivo cargado en una ubicación que no se puede consultar públicamente, intente cargarlo como una imagen en su lenguaje de programación y permitirlo si se puede analizar correctamente como una imagen. Muchas veces la gente querrá cambiar el tamaño de la imagen de todos modos así que realmente hacer esto no es trabajo extra. Una vez que se valida la imagen, puede moverla al área pública para su servidor web.

Además, asegúrese de tener un límite en el tamaño de carga del archivo. La mayoría de las plataformas tendrán algún tipo de límite establecido por defecto. No desea que un usuario malintencionado llene su disco con una carga de archivos interminable.

+0

¿De qué manera la publicación de un archivo a través de HTTP hace que se ejecute en el servidor? –

+0

Depende de su plataforma. En PHP, por ejemplo, si subo una imagen llamada myhackerscript.php y luego navego hacia ella en su sitio web, ¿adivina qué? myhackerscript.php se ejecuta en su servidor. – Asaph

+0

Es cierto, definitivamente, y eso es un buen consejo para cualquier carga. Sin embargo, ¿qué pasa con los riesgos para mis usuarios? –

2

El riesgo de propagación de errores dentro formateadores imagen no es "exactamente" su problema, pero puede ayudar de todos modos, siguiendo la práctica general de la cartografía ".jpg" a su idioma ejecutable, y el procesamiento de cada imagen de forma manual (de esta manera puede hacer también referencias).

Necesita ser cuidadoso de:

  • gente subir código como imágenes (.jpg con real C# código dentro)
  • cualquier extensión no válidos (que revisar esto)
  • gente tratando de hacer ataques relacionados con el camino

El último es lo que tendrá que tener cuidado, si está leyendo dinámicamente imágenes (como lo hará, si sigue mi primer consejo).

Así que asegúrese de abrir código solo en la carpeta correspondiente y, probablemente más importante, bloquee al usuario que hace este trabajo. Me refiero al usuario del servidor web. Asegúrese de que solo tenga permisos para , lea desde la carpeta en la que está trabajando, y otras cosas lógicas.

¿Metadatos de separación? Claro que por qué no, es muy amable de tu parte, pero no estaría loco por eso.

0

Una de las vulnerabilidades que conozco es una "puerta trasera WMF". WMF es "metarchivo de Windows", un formato gráfico representado por la biblioteca de Windows GDI. Aquí está wikipedia article.

El atacante es capaz de ejecutar código arbitrario en la máquina del usuario. Esto puede suceder cuando el usuario solo ve el archivo a través del navegador, incluido, entre otros, Internet Explorer. El tema se dice que está fijado en 2006.

Cuestiones relacionadas