Acerca de la seguridad de la aplicación web: archivos adjuntos del usuario [cerrado]

1

Tengo una aplicación web (software de foro) en la que estoy trabajando en una función sobre cómo el usuario adjunta archivos a las publicaciones del foro.

La aplicación está escrita en lenguaje ensamblador y la base de datos es SQLite.

El enfoque que utilicé es mantener los archivos adjuntos como blobs en la base de datos y permitir la descarga solo con los encabezados:

Content-type: application/octet-stream
Content-Disposition: attachment

De esta manera, los archivos nunca se almacenarán como archivos en el servidor.

No se planea implementar ninguna validación del tipo de archivo y contenido, porque se consideran superfluas en esta configuración (y quiero dar a los usuarios la máxima libertad, sin comprometer la seguridad, por supuesto).

Está claro que cargar archivos de gran tamaño es una forma de realizar ataques DoS, pero esto no es un tema de la pregunta preestablecida.

Los posibles errores en la aplicación web en sí, que causan desbordamientos de búfer y similares no son un problema también (son posibles, por supuesto, pero quiero preguntar sobre la arquitectura, no sobre la implementación).

La configuración cuestionada es el siguiente esquema:

  1. sin archivos: desde la solicitud POST - > al campo de blob de SQLite.
  2. en el campo de blob de SQLite - > a la red y al navegador del usuario.
  3. Siempre: application / octet-stream y Content-Disposition: attachment
  4. Sin validación del servidor del tipo de archivo y / o contenido.

Y la pregunta es:

¿Qué vectores de ataque todavía son posibles con el enfoque anterior?

P.S. La pregunta Funcionalidad de carga de archivos de Pentesting es similar, pero discute principalmente que los archivos cargados existen en el FS del servidor que es diferente del sistema que solicito.

    
pregunta johnfound 28.09.2017 - 13:47
fuente

2 respuestas

1

El vector posible es un ataque de rango de contenido, cuando se le pedirá un documento que no sea desde el principio, puede obligarlo a leer todo el contenido en la memoria para enviar solo un byte. Por lo tanto, puede golpear OOM en el servidor mientras que la carga útil de ancho de banda y red para el ataque se mide en cientos de bytes

    
respondido por el Alexey Vesnin 28.09.2017 - 15:14
fuente
0

Responderé con 2 puntos distintos.

  1. BLOBOS

    Se permiten los blobs en todas las bases de datos principales, pero la calidad de su implementación puede variar. De hecho, requieren que la base de datos pueda almacenar objetos de tamaño arbitrario, lo que no es la primera preocupación de una base de datos relacional. Como resultado, la inserción, eliminación o actualización frecuente de blobs puede terminar en una base de datos usando mucho más espacio del que realmente es necesario. Además, el riesgo de un problema de bajo nivel en el medio o escribir un blob es aproximadamente proporcional al tamaño del blob y eso podría resultar en una base de datos dañada. Más de mi opinión, pero prefiero almacenar archivos grandes directamente en un sistema de archivos (es su trabajo), y solo almacenar nombres en la base de datos.

  2. Malwares

    Usted no usa directamente los archivos adjuntos en su plataforma, pero los ofrece a sus clientes. Si uno de ellos carga maliciosamente o inadvertidamente un archivo que contiene un malware, su plataforma será un vector de difusión para ese malware. Aparte de los posibles problemas legales (pero asegúrese de que sus condiciones generales sean explícitas al respecto), la experiencia del usuario será muy mala = > al menos debe escanear cualquier archivo entrante con un software antivirus actualizado.

respondido por el Serge Ballesta 28.09.2017 - 14:02
fuente

Lea otras preguntas en las etiquetas