2009-12-14 18 views
5

me gustaría crear mi siguiente funcionalidad para la aplicación basada en la web:Carga y extracción de archivos (zip, rar, targz, tarbz) de forma automática - ¿problema de seguridad?

  1. usuario sube un archivo comprimido (ZIP/RAR/tar.gz/tar.bz etc) (contenido - varios archivos de imagen)
  2. contenedor se extrae automáticamente después de cargar
  3. imágenes se muestran en la lista de HTML (cualquiera que sea)

¿hay algún problema de seguridad que participan en proceso de extracción? P.ej. posibilidad de ejecución de código malicioso dentro de los archivos cargados (o archivo de archivo bien preparado), o si no?

Respuesta

7

Además de la posibilidad de explotar el sistema con cosas como desbordamientos de búfer si no se implementa con cuidado, puede haber problemas si extrae a ciegas un archivo comprimido bien elaborado con un archivo grande con patrones redundantes dentro (una bomba zip). La versión comprimida es muy pequeña, pero cuando la extrae, ocupará todo el disco, lo que provocará la denegación del servicio y posiblemente bloquee el sistema.

Además, si usted no es lo suficientemente cuidadoso, el cliente puede entregar un archivo zip con el contenido del lado del servidor, ejecutables (.php.asp, .aspx, ...) dentro y solicitar el archivo a través de HTTP, que, si no se configura correctamente puede dar lugar a la ejecución de código arbitrario en el servidor.

+0

Whoa, esa cosa zipbomb parece bastante devastadora;) (http://en.wikipedia.org/wiki/Zip_bomb). ¿Los otros formatos de archivo/algoritmos de extracción son libres de problemas? – gorsky

+0

El propósito de un algoritmo de compresión es comprimir lo mejor posible para que no se considere un defecto en el algoritmo. La entidad que descomprime el archivo debe realizar algunas comprobaciones de cordura sobre el tamaño e impedir la descompresión de archivos sospechosos. –

+0

Con el archivo zip, no se puede determinar con seguridad el tamaño con el que terminará hasta después de haber descomprimido. –

3

Además de la respuesta de Medrdad: Hospedaje de contenido proporcionado por el usuario es un poco complicado. Si está alojando un archivo zip, puede usarse para almacenar archivos de clase Java (también se usa para otros formatos) y, por lo tanto, se puede romper la "misma política de origen". (Hubo un ataque GIFAR en el que se adjuntó un archivo zip al final de otro archivo, pero que ya no funciona con Java PlugIn/WebStart). Los archivos de imagen deberían, como mínimo, verificarse que realmente sean archivos de imagen. Obviamente, hay un problema con los navegadores web que tienen vulnerabilidades de desbordamiento de búfer, que ahora su sitio podría ser utilizado para atacar a sus visitantes (esto puede hacer que no sea popular). Puede encontrar algún software del lado del cliente que utilice, digamos, expresiones regulares para pasar datos, de modo que se puedan ejecutar los datos en el medio del archivo de imagen. Los archivos Zip pueden tener nombres de archivo maliciosos (por ejemplo, cruce de directorios con ../ y caracteres extraños).

qué hacer (no necesariamente una lista exhaustiva):

  • usuario anfitrión suministra archivos en un dominio completamente diferente.
  • El dominio con archivos de usuario debe usar diferentes direcciones IP.
  • Si es posible, decodifique y recodifique los datos.
  • Hay otra pregunta de stackoverflow en las bombas zip: sugiero descomprimir usando ZipInputStream y parar si se vuelve demasiado grande.
  • Donde el código nativo toca los datos del usuario, hágalo en un chroot gaol.
  • Lista blanca de caracteres o reemplaza por completo los nombres de los archivos.
  • Potencialmente, podría utilizar un IDS de alguna descripción para buscar datos sospechosos (¡realmente no sé cuánto se hace esto, asegúrese de que su IDS no esté escrito en C!).
Cuestiones relacionadas