¿El almacenamiento de datos de sesión en la DMZ está bien en una aplicación web empresarial de n niveles?

3

Supongamos que tengo una aplicación web estándar de varios niveles con servidores web en la DMZ y varios servicios a los que solo se puede acceder desde una aplicación web autenticada. Supongamos también que la aplicación web utiliza sesiones del lado del servidor.

Estoy interesado en la opinión de la comunidad - ¿cree que estaría bien almacenar los datos de sesión de la aplicación web en algún tipo de base de datos aún en la DMZ, o si esos datos están en una base de datos de backend adecuada? ¿Encapsulado por un servicio ? (Por base de datos en la DMZ me refiero a cualquier tipo de base de datos, SQL, NoSQL o incluso el sistema de archivos del servidor web, por ejemplo, PHP lo hace de forma predeterminada).

Entiendo que todo se trata de contra qué quiero protegerlo.

  • Considerando que un atacante que solo tiene acceso a la interfaz de usuario de la aplicación, casi no importa (vea en la parte inferior) siempre que no haya una vulnerabilidad relacionada con la sesión en la aplicación, pero si hay uno, los datos de la sesión se infringen de todos modos.

  • Teniendo en cuenta que un atacante que ya tiene acceso al servidor web con el usuario ejecutando la aplicación web (por ejemplo, inyección de comandos del sistema operativo en la aplicación web), podría leer la base de datos en la DMZ o conectarse a el servicio de sesión utilizando las credenciales de la aplicación.

  • para un atacante que ya sea root / admin en el servidor web, también es el mismo.

  • Desde una perspectiva de administración, las operaciones de TI para DMZ y una zona segura normalmente serían las mismas personas.

  • Considerando que un atacante ha logrado cierto nivel de acceso a otra cosa (no a la aplicación web) en la DMZ, podría ser más fácil acceder a otros servidores, como el que contiene los datos de sesión para esta aplicación web. Esto sería aún más preocupante con un almacén de sesiones como Redis donde la autenticación no es un punto fuerte. Pero, ¿qué pasa si no hay nada más en esta infraestructura aparte de esta aplicación en cuestión?

Entonces, ¿cuál sería el beneficio de poner datos de sesión detrás de un servicio? ¿Qué justificaría el costo adicional, la complejidad y la penalización de rendimiento?

Por ejemplo, al tener la base de datos de la sesión en la DMZ, podría pensar en la amenaza de una mala configuración de la infraestructura que permite que alguien de un nivel externo tenga acceso a la base de datos de la sesión.

También algunas vulnerabilidades no relacionadas en la aplicación web pueden resultar en la violación de los datos de la sesión, especialmente si está en el propio servidor web, como, por ejemplo, una simple inclusión de archivos locales podría ser suficiente. Pero este riesgo se puede mitigar de otras maneras en algunos entornos (el proceso de la aplicación en sí no necesariamente tiene que tener acceso a los archivos de la base de datos de la sesión directamente, o simplemente podría ser una base de datos independiente, no en la aplicación web). p>

Entonces, ¿aceptaría una aplicación de este tipo como adecuada para n niveles y razonablemente segura a este respecto, o cree que esta idea es errónea y que los datos de la sesión deberían manejarse de la misma manera que cualquier otro dato de la aplicación?

    
pregunta Gabor Lengyel 18.12.2016 - 15:41
fuente

1 respuesta

2

En última instancia, esto se reduce al nivel de riesgo que está preparado para asumir. Para evaluar eso, debe comprender el impacto de cada riesgo que se realiza.

En este caso, si hay un impacto relativamente pequeño si se infringen los datos de la sesión, es decir, un atacante no podría utilizar los datos de la sesión para filtrar de forma masiva los datos de identificación personal o crear errores costosos, es probable que esté bien. para mantenerlo en la DMZ con la aplicación.

Si los datos de la sesión le dieran acceso a la tarjeta de crédito u otra información financiera, direcciones, datos médicos, ... - especialmente para usuarios múltiples, entonces diría que ese fue un riesgo significativo y me gustaría verlo mejor asegurado.

    
respondido por el Julian Knight 18.12.2016 - 21:32
fuente

Lea otras preguntas en las etiquetas