Gestión de sesión: ¿Son suficientes las características del servidor de aplicaciones?

Question

Gestión de sesión: ¿Son suficientes las características del servidor de aplicaciones?

#1 de D.W. (4 votos)
#2 de rook (2 votos)

1

HTTP es un protocolo sin estado. Sin embargo, cuando el usuario inicia sesión en una aplicación web, le gusta que se conserve cierta información de la sesión, de modo que no tenga que iniciar sesión nuevamente cuando quiera ir y venir entre las páginas web de la misma aplicación.

Asociado a cada sesión es una vida útil. Además, algunas sesiones son "transitorias", lo que significa que se cierran tan pronto como el usuario cierra la página web (incluso si la sesión aún no ha finalizado).

Muchos servidores de aplicaciones proporcionan la noción de sesión. Por ejemplo, la documentación de WebLogic (con la que estamos trabajando actualmente) trata sobre "Uso de sesiones y persistencia de sesión" (consulte el Capítulo 10 de Desarrollo de aplicaciones web, servlets y JSP para Oracle WebLogic Server 11g versión 1 ).

La pregunta es:

Dada la variedad de posibles ataques en las sesiones (secuestro de sesión, fijación de sesión, etc.), ¿es suficiente confiar en las funciones de administración de sesión del servidor de aplicaciones? En otras palabras, ¿puede la aplicación ser "independiente de la sesión" y todo puede manejarse con la configuración adecuada del servidor de aplicaciones? (También se puede suponer que las conexiones se realizan a través de una conexión HTTPS implementada correctamente).

Creo que la respuesta es NO, pero necesito una justificación concreta en cuanto a lo que podemos y lo que no podemos esperar del servidor de aplicaciones.

Es altamente apreciado el apuntar a las mejores prácticas y posibles amenazas / ataques en la administración de sesiones.

Editar (en relación con el comentario de Andrew): En su respuesta, suponga que todo lo demás (firewall, sistema de archivos, base de datos, etc.) está configurado correctamente. Ahora, ¿se puede configurar el servidor de aplicaciones de tal manera que la aplicación en sí no necesite administrar las sesiones? Es decir, ¿podemos escribir una aplicación totalmente "independiente de la sesión" y colocarla en un entorno que (mediante el uso adecuado del servidor de aplicaciones, el firewall, etc.) evite el secuestro de la sesión, la reparación de la sesión y otros ataques relacionados con la sesión?

web-application appsec session-management session-fixation

pregunta M.S. Dousti 25.07.2012 - 14:56

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application appsec session-management session-fixation

¿Qué tan confiable / seguro es QCaptcha? ¿Por qué son similares los primeros caracteres de una clave privada DSA?

score 4 · Answer 1

No. No es suficiente usar las funciones de administración de sesión del marco de la aplicación y no hacer nada más. Es definitivamente una buena idea utilizar la administración de sesiones del marco de la aplicación (no haga no su propia administración de sesiones), pero también deberá tomar algunos pasos adicionales.

La división exacta de responsabilidad entre el desarrollador y la capa de administración de la sesión dependerá de la capa de administración de la sesión en particular, pero aquí hay algunos problemas que normalmente son responsabilidad del desarrollador y no son manejados por la capa de administración de la sesión:

Debe implementar o habilitar la defensa CSRF (tokens CSRF). Normalmente, la capa de administración de la sesión no lo hará por usted.
Si desea usar https, debe establecer el atributo secure en todas las cookies. Si está utilizando https en todo el sitio, es su responsabilidad habilitar HSTS.
Debe configurar la capa de administración de sesión para que no acepte los ID de sesión en un parámetro GET. Esto es importante para evitar las vulnerabilidades de la fijación de sesión.
Es probable que deba indicar al sistema que genere un nuevo token CSRF inmediatamente después de iniciar sesión, para defenderse contra el inicio de sesión CSRF.
Si desea utilizar el atributo de cookie HTTPOnly, es su responsabilidad establecerlo. Es discutible si este atributo de cookie proporciona un aumento medible en la seguridad frente a un atacante sofisticado, pero algunas personas lo recomiendan como una práctica de seguridad "no puede dañar".

Recomiendo leer los recursos que OWASP pone a disposición. Esto le ayudará a comprender lo que debe hacer para proteger su aplicación web.

score 2 · Answer 2

En general, el error más grave que puede cometer al desarrollar una aplicación es intentar "rodar la suya", cuando la plataforma ya proporciona dicha funcionalidad (como intentar reimplementar ssl). Las vulnerabilidades son inevitables. Al confiar en su plataforma, está adquiriendo la fuerza de la comunidad para auditar su seguridad para GRATIS , el mantenedor de su plataforma luego parcheará su sistema para FREE .

Dicho esto, hay algunos ataques a tener en cuenta. Es posible que, de forma predeterminada, el controlador de sesión no sea tan fuerte como podría ser. Querrá habilitar tanto la cookie "segura" como la cookie de HTTPOnly . El atributo "seguro" de la cookie obliga a que la cookie se transmita a través de https, que es una buena forma de manejar el potencial owasp a9 violaciones. Otra dificultad que debe tener en cuenta es que todos los identificadores de sesión solo deben transmitirse como una cookie y no como una variable GET. Transmitir su ID de sesión como una variable GET abre la puerta para la fijación de sesión .

También tenga en cuenta que CSRF también se conoce como "Session Riding", pero este ataque es algo tiene que defenderse contra y no es responsabilidad de su manejador de sesión.