Fijación de sesión en Java

5

En el proceso de desarrollo de una aplicación vulnerable basada en jsp / servlet, intenté introducir la vulnerabilidad de la fijación de sesión.

Refiriéndose a la documentación Vine con el siguiente código que, cuando se utiliza en el servlet para crear una nueva sesión, debe devolver la sesión HTTP existente si existe y, de lo contrario, debe devolver un valor nulo. En cualquier caso, no se debe crear una nueva sesión.

if(obj.checkLogin(username, password))//if credentials are valid
    {
    HttpSession session = request.getSession(false);//return the existing session

    if(session != null)
            response.sendRedirect("LoginSuccess.jsp");
        else
            response.sendRedirect("error.jsp");
    }

Para probar el código, lo implementé con Tomcat 7 y probé la fijación de sesión:

  1. Observe la cookie ( c1 ) cuando se cargue la página de inicio de sesión (usando un proxy interceptor)
  2. Introduzca las credenciales correctas en el formulario de inicio de sesión. La autenticación fue exitosa y fui redirigido a LoginSuccess.jsp
  3. Observe la cookie ( c2 ) después de la autenticación.

Encontré que las cookies c1 y c2 son diferentes. Lo que implica que el código no es vulnerable a la fijación de sesión. Estoy teniendo problemas para entender este comportamiento. ¿Por qué es que la cookie original c1 no persiste después de la autenticación?

    
pregunta Shurmajee 11.11.2014 - 12:58
fuente

1 respuesta

-1

El motor de servlet que está utilizando de manera segura maneja las cookies de sesión cuando llama a request.getSession (), y no es vulnerable a la fijación.

(como se explica en los comentarios) Este comportamiento es a la vez intencional y correcto. Si se llama a getSession (), getSession (true) o getSession (false), el servidor se basa en su propia memoria para determinar si hay una sesión válida que coincida con el valor recibido del cliente. Si no hay tal sesión en la memoria del servidor, entonces el motor del servlet ignora el ID de sesión del cliente. Esto evita la fijación de la sesión, ya que el servidor nunca permite que el cliente defina el id de sesión de una nueva sesión (nuevo desde la perspectiva del servidor que no tiene ese id de sesión en la memoria).

Debe encontrar un motor de servlet roto anterior que sea vulnerable a la reparación de la sesión o reemplazar el código de administración de la sesión. Si opta por lo último, deberá determinar si puede reemplazar la generación de la sesión en su lugar o si escribirá su propio código de administración de sesión.

El enfoque que adoptes debe reflejar lo que estás tratando de enseñar. Si quieres que la gente enseñe ...

  • mantén tus cosas parcheadas, luego ve con el viejo motor roto
  • para no escribir su propio mecanismo de administración de sesión, escriba su propio
  • no modificar un mecanismo de administración de sesión existente, luego modificar el existente
respondido por el atk 11.11.2014 - 15:21
fuente

Lea otras preguntas en las etiquetas