Ataque de reparación de sesión, sesiones basadas en cookies a través de https

Para cada vulnerabilidad de reparación de sesión, el atacante debe conocer el identificador de sesión. Existen dos formas de obtenerlo: robándola de la PC de la víctima y mediante un ataque de fuerza bruta.

El atributo Httponly protege su cookie contra ataques XSS usando la política del mismo origen del navegador, pero hay muchas otras formas de acceder a la PC de la víctima y robar la cookie, incluida la explotación de vulnerabilidades en el navegador de la víctima.

Lamentablemente, no estoy familiarizado con CAS y ahora sé por cuánto tiempo no se modifica el ID de sesión. Si su servidor sigue utilizando el mismo identificador de sesión durante un período de tiempo significativo, entonces es posible forzarlo / predecirlo. Aquí es donde la fijación de la sesión se vuelve peligrosa.

Mi consejo es generar un nuevo token de sesión cada 15-20 minutos para las sesiones activas también. De esta manera, será extremadamente difícil forzarlo brutalmente y su aplicación estará protegida contra ataques de fijación de sesión.

Por lo que puedo ver, CAS es una forma de autenticación OAuth2, aunque no usan ese término en su sistema.

Para que OAuth2 sea seguro, el servicio que lo usa debe tener un conjunto de claves (es más como tener un nombre de usuario y una contraseña secretos). Sin tales claves, sería muy fácil enviar el el usuario directamente al servidor de CAS con una ID para que el atacante sepa exactamente qué ID va a utilizar.

+------------------+                   +----------------------+
|                  |                   |                      |
|  Your Server     +-------+---------->|  CAS Server          |
|                  |       |           |                      |
+------------------+       |           +--------+-------------+
                           |                    |
+------------------+       |                    |
|                  |       |                    |
|  Hacker Server   +-------+                    |
|                  |                            v
+---------+--------+                   +----------------------+
          .                            |                      |
          +...........................>|  Back to Your Server |
                                       |                      |
                                       +----------------------+

Sin algunos secretos de su computadora, tenemos una forma muy sencilla de saber cuál es el identificador de la sesión como hacker. Simplemente generamos dicha ID y lo enviamos al servidor CAS. Espere un poco y luego acceda al servidor en cuestión.

Me imagino que CAS tiene los secretos necesarios para que esto no funcione.

Ahora, si puedo crear un ataque XSS que establezca una cookie con el ID de sesión, también puedo obtener los conocimientos necesarios para conectarme al servidor una vez que el usuario haya iniciado sesión.

Con el XSS probablemente estarían explotando un problema en sus sistemas. Así que el pirata informático tiene un enlace a su servidor que hace algo malo y ejecuta el código del pirata informático (JavaScript o una etiqueta meta). Ese código establece la ID de sesión o verifica la ID de sesión existente y la envía a una de las computadoras del pirata informático.

+------------------+                   +----------------------+
|                  |                   |                      |
|  Your Server     +------------------>|  CAS Server          |
|                  |                   |                      |
+------------+-----+                   +--------+-------------+
         ^   |                                  |
         |   |                                  |
         |   v                                  v
+--------+---------+                   +----------------------+
|                  |                   |                      |
|  Hacker Server   +..................>|  Back to Your Server |
|                  |                   |                      |
+------------------+                   +----------------------+

En este caso, ya que la ID de la sesión no cambiará, tendrán acceso a su servidor durante 15 a 20 minutos una vez que el usuario haya iniciado sesión. Un ataque XSS es bastante fácil de evitar, pero he oído hablar de muchos de estos ataques (trabajé en Drupal por un tiempo y descubrí algunos de programadores que no piensan fuera de la caja y usan datos posiblemente contaminados como están).

Un ejemplo de esto es llegar a una página 404 utilizando el código en el URI:

http://example.com/<script>document.cookie = "JSESSIONID=123";</script>

Un programador que crea una página 404 y muestra la etiqueta <script> tal como está (es decir, sin reemplazar el < con < y > con > ) permite una El ataque entre sitios ya que el JavaScript malicioso se ejecutará en su sitio.

Tenga en cuenta que con un ataque Man In The Middle (MITM), ni siquiera necesita un XSS o una mala implementación tipo OAuth2. Pero es más difícil ejecutar un MITM y en la mayoría de los casos requiere un lugar público para que las personas en el trabajo tengan menos probabilidades de tener un colega pirata informático que sepa cómo ser un MITM.

O no has entendido al asesor de seguridad o no saben de qué están hablando.

Necesitas profundizar un poco más para descubrir la verdad.

Pedirle al consultor de seguridad que demuestre que la vulnerabilidad puede probar lo primero, pero una falla no lo es.

cookies de sesión deben deben configurarse con el indicador de seguridad. Si la identificación de la sesión no se resuelve cuando la presenta un cliente, el servidor debe genera una nueva identificación de sesión. Es una buena práctica generar un nuevo identificador de sesión (y configurarlo en el cliente) cuando cambie el estado de autenticación (en su escenario, cuando su aplicación valida el token con el servicio de autenticación y cuando el usuario cierra la sesión, después de destruir los datos a los que se hace referencia por la antigua identificación).

Suponiendo que sus cookies están configuradas con la marca de seguridad ...

Para que su implementación sea vulnerable, debe aceptar un ID de sesión relacionado con una sesión inexistente. Si ese no es el caso, entonces el consultor está equivocado, sin embargo, aún debe aplicar la tercera recomendación anterior.

Considere: está navegando enlace . Un atacante puede inyectar un encabezado en una respuesta del servidor configurando el ID de sesión en un valor conocido. Si posteriormente inicia sesión en enlace , su navegador enviará la identificación de sesión establecida por el atacante (la parte de SSO es irrelevante). Si su servidor no cambió el ID de sesión cuando se presentó por primera vez (y, por lo tanto, hace referencia a datos de sesión nulos), ahora es el elegido por su atacante.

Usar hsts ayudaría, pero lo importante son los tres pasos anteriores.

Supongo que su aplicación web no genera un nuevo ID de sesión después de que el cliente es redirigido nuevamente a su aplicación en el flujo de trabajo de CAS. Por lo tanto, un atacante puede obtener un ID de sesión válido sin iniciar sesión e intentar engañar a otro cliente para que lo siga utilizando después de un inicio de sesión exitoso.

La mejor práctica es generar un nuevo ID de sesión después de cada inicio de sesión.

Vea también: OWASP - Fijación de sesión