Riesgos de seguridad de los sistemas de carga y descarga de archivos

3

Sé que hay muchas publicaciones sobre este tema. Pero esas publicaciones generalmente hablan de restringir los tipos de archivos y tamaños, etc. Por lo tanto, no sirve a mis necesidades ya que mi sistema no tiene restricciones.

Supongamos que tenemos una aplicación web que acepta las cargas de los usuarios que han iniciado sesión. Estos usuarios se autentican a través de Active Directory. Los usuarios anónimos no están permitidos.

Los usuarios pueden cargar cualquier tipo de archivo al sistema. Luego, los usuarios pueden obtener una vista previa de los archivos cargados a través de nuestro visor de propósitos múltiples. En este momento admitimos algunos tipos de archivos básicos, como imágenes, música, videos, archivos pdf y archivos de oficina. Para los tipos visibles, decido buscar en el diccionario los tipos visibles, y si el tipo no existe, no se verán, sino que se descargarán directamente.

Tengo curiosidad por los riesgos de seguridad que tengo, por lo tanto, intentaré elaborar mi sistema.

Tengo dos sistemas diferentes en cuanto al procedimiento de mantenimiento de archivos:

  1. Una aplicación internet donde el almacenamiento es un sistema de archivos estructurado donde los nombres de los archivos se cambian con guías
  2. Una aplicación intranet donde el almacenamiento es un sistema de archivos no estructurado donde los archivos están directamente en la unidad de red a medida que el usuario los carga, y los usuarios también pueden acceder a los archivos a través de la unidad de red

Para ambas aplicaciones, la estrategia de vista previa es la misma.

Todos los archivos se sirven desde un método de acción al que solo se puede acceder mientras se autentica. Y el recorrido de la ruta lógica para los archivos cargados se permite .

Los archivos que no son de Office se devuelven al cliente y se muestran en las etiquetas img , video y embed html.

Por otra parte, los archivos de Office primero se ejecutan a través de bibliotecas de interoperabilidad de Microsoft Office, se convierten a pdf, luego se devuelven al cliente y, nuevamente, se muestran como un pdf normal.

Me pregunto, ¿a través de estos procesos estoy comprometiendo cualquier seguridad aquí en el lado del servidor? Sé que el usuario puede cargar archivos maliciosos, pero ¿hay alguna manera de que el usuario pueda dañar mi sistema al escribir o leer el proceso de los archivos?

    
pregunta Tolga Evcimen 23.01.2017 - 06:40
fuente

2 respuestas

2

Desde la perspectiva del servidor, está permitiendo que otros pongan cosas directamente en el sistema de archivos sin (mucho) validación. El almacenamiento de la base de datos es comparativamente más seguro, ya que los datos binarios no son ejecutables directamente. Sin embargo, el almacenamiento directo de archivos utilizando el sistema de archivos del sistema operativo tiene un mejor rendimiento.

Si los archivos se almacenan en un almacenamiento de archivos, un hack dirigido podría ser cargar un archivo especialmente diseñado en el servidor, y luego activar el servidor para procesarlo (ya sea un xml, zip, exe, etc.) p>

Como mínimo, debe alterar los permisos de la carpeta que contiene los archivos cargados por el usuario para que no sean ejecutables. Iría un paso más allá y reemplazar todas las extensiones de archivo mediante programación a algo como .exe_ , .pdf_ . Después de todo, no es necesario que almacene los archivos de la forma en que se cargan, solo tiene que presentar los datos en la lógica de la aplicación. La modificación de la extensión del archivo podría romper cualquier asociación de tipo de archivo o mecanismos de activación automática.

    
respondido por el kevin 23.01.2017 - 15:02
fuente
2

Por lo general, la ruta regular en el hackeo web puede ser de forma resumida y rápida, como por ejemplo:

  • Encuentre una vulnerabilidad (escaneo, huellas digitales, etc.)
  • explotar la vulnerabilidad
  • Escribe algún tipo de carga malvada / shell o lo que sea
  • Accede / ejecuta esas cosas malvadas
  • Más y más no importantes para esta pregunta, pasos después de esto.

En tu sistema, el tercer punto es gratis !. No estoy diciendo que vayas a ser hackeado. Pero con un sistema como este, está poniendo las cosas un poco más fáciles si se completan los pasos anteriores, eso es todo.

Recuerda que solo un punto débil y todo es posible. Por supuesto lo más peligroso es la inyección directa de comandos. Si no está presente, está bien, pero tal vez después de explotar otra vulnerabilidad podría ser posible lanzar algún tipo de comando en el sistema, por ejemplo, a través de inyección SQL. Dependiendo de los sistemas, bases de datos y versiones, podría ser posible ejecutar comandos del sistema desde la base de datos.

Entonces, ¡cuidado con TODOS! Inyección XSS, inyección SQL, inyección de comando, CSRF, RFI, etc.

Y, por supuesto, verifique la versión de TODOS sus componentes (servidor web, kernel, sistema operativo, etc.). Si usa un componente con vulnerabilidades conocidas, tal vez pueda ser hackeado incluso con un buen desarrollo en el lado de la aplicación.

    
respondido por el OscarAkaElvis 23.01.2017 - 14:33
fuente

Lea otras preguntas en las etiquetas