¿Cómo proteger una aplicación de los atacantes con acceso completo de lectura a la base de datos?

3

Trabajo en una aplicación web con el lado del cliente como una aplicación de Javascript de una sola página y el lado del servidor como un servicio REST. Esta aplicación administra datos de usuario confidenciales que no deben ser legibles ni siquiera por un atacante con acceso completo de lectura a la base de datos en vivo o algún archivo de base de datos.

Nuestro plan es:

  1. cuando el usuario se registra, genera claves asimétricas en el lado del cliente y las envía al servidor, con la clave privada cifrada con una clave derivada de la contraseña del usuario
  2. autentique al usuario pidiendo la clave privada cifrada del servidor y descifrela en el lado del cliente usando la contraseña del usuario. El descifrado exitoso equivale a una autenticación exitosa
  3. genere claves simétricas cuando se crea un documento confidencial, cifre el documento y comparta estas claves con los usuarios autorizados, estilo PGP
  4. para la recuperación de la contraseña, le damos al usuario su clave privada y confiamos en él para que esté seguro

Tenga en cuenta que asumimos que el atacante no controla ni el navegador ni un servidor en ejecución.

En este escenario, ¿qué vectores de ataque ves?

¿Es posible implementar un mecanismo de recuperación más simple que no requiera que el usuario almacene la clave privada?

¿Tiene alguna otra inquietud / recomendación?

Gracias

    
pregunta vidi 07.02.2017 - 15:19
fuente

2 respuestas

2
  

En este escenario, ¿qué vectores de ataque ves?

Si su plataforma es el navegador, un posible ataque podría ser modificar su código javascript en tránsito y agregar algunas líneas de código que compartan las claves generadas por el cliente con los malos.

Esto implica un ataque MITM exitoso en el tráfico descendente. Esto puede ser posible mediante el diseño en contextos donde hay un filtrado de contenido entre usted y el cliente que necesita leer contenido cifrado para tomar decisiones de filtrado. Si un atacante atacó el servidor de filtrado de contenido en lugar de su servidor o el navegador del cliente, es probable que pueda hacerse pasar por su servidor y modificar el javascript que el cliente ve, y nunca lo sabría.

Dijiste que ni el navegador ni el servidor están bajo el control de un atacante, pero si fuera así, obviamente sería fácil romper el protocolo.

Proporcionar al navegador un complemento que pueda verificar las firmas en el javascript descargado puede hacer que esto sea más seguro, pero no sé lo suficiente sobre el modelo de seguridad del navegador para hacer una suposición informada.

  

¿Es posible implementar un mecanismo de recuperación más simple que no requiera que el usuario almacene la clave privada?

Según su comentario para aclarar el diseño, diría que no.

    
respondido por el Pascal 07.02.2017 - 15:53
fuente
2

Si no fuera el navegador, el esquema sería correcto. Desafortunadamente, debido a varios problemas impuestos por el navegador, no lo es:

  1. MitM: como se mencionó anteriormente, los atacantes pueden enviarle JS incorrectos al comprometer el transporte. Además, la verificación de javascript no ayudará, debido al modelo de ejecución de código en el navegador: podríamos agregar fácilmente otro <SCRIPT> , que se superpondrá a algunas de las funciones, en lugar de reemplazarlo.
  2. Suponiendo que el atacante no puede controlar el navegador es una suposición errónea que realmente no puedes hacer. Todo en su página está controlado por contenido: cualquier parte del árbol DOM puede afectar a cualquier otra parte del árbol DOM. Cualquier recurso externo inseguro en su página también está sujeto a MitM. ¿Incluyes activos a través de conexiones HTTP? El atacante ni siquiera tiene que atacar a su conexión.
respondido por el pFarb 09.02.2017 - 08:42
fuente

Lea otras preguntas en las etiquetas