6

Estoy utilizando los servicios RememberMe de Spring Security para mantener a un usuario autenticado.Servicios de RememberMe de seguridad de primavera con la cookie de sesión

Me gustaría encontrar una manera simple de tener la cookie RememberMe configurada como una cookie de sesión en lugar de con un tiempo de caducidad fijo. Para mi aplicación, la cookie debe persistir hasta que el usuario cierre el navegador.

¿Alguna sugerencia sobre cómo implementar mejor esto? ¿Alguna preocupación sobre este es un posible problema de seguridad?

La razón principal para hacerlo es que con un token basado en cookies, cualquiera de los servidores detrás de nuestro equilibrador de carga puede atender una solicitud protegida sin depender de que la Autenticación del usuario se almacene en una HttpSession. De hecho, le he dicho explícitamente a Spring Security que nunca cree sesiones usando el espacio de nombres. Además, estamos utilizando Elastic Load Balancing de Amazon, por lo que las sesiones fijas no son compatibles.

NB: Aunque soy consciente de que a partir del 08 de abril, Amazon ahora es compatible con las sesiones adhesivas, todavía no quiero usarlas por varias otras razones. A saber, que el fallecimiento intempestivo de un servidor aún causaría la pérdida de sesiones para todos los usuarios asociados con él. http://aws.amazon.com/about-aws/whats-new/2010/04/08/support-for-session-stickiness-in-elastic-load-balancing/

+0

Por qué ¿simplemente no implementa su propia implementación de RememberMe? Es bastante fácil. – lexicore

+0

¿Duplicado? http://stackoverflow.com/questions/2594960/best-practice-to-implement-secure-remember-me – rook

+0

@lexicore personas que implementan sus propias sesiones pueden traer verdadera devastación a su aplicación web. No reinventar la roncha. Lea mi publicación en el "duplicado?" pregunta arriba. – rook

Respuesta

3

Para que la sesión funcione correctamente con el equilibrio de carga, almacenaría los datos de la sesión en una base de datos sql.

La cookie siempre debe ser un valor aleatorio que caduque. Hay casos en los que puede almacenar el estado como un valor de cookie y no constituye un peligro grave, como el idioma preferido por los usuarios, pero esto debe evitarse tanto como sea posible. Activar HttpOnlyCookies, es una gran idea.

Lea A3: "Autenticación y gestión de sesión rotas" en el top 10 de OWASP para 2010. Un punto importante en esta sección es que se debe usar https para toda la sesión. Si la sesión dura mucho tiempo, esto es aún más importante.

También tenga en cuenta que "Recordarme" crea una gran ventana en la que un atacante puede "montar" en la sesión. Esto le da al atacante un tiempo muy largo (¿Meses?) En el cual puede lanzar un ataque CSRF. Incluso si tiene protección CSRF, un atacante aún puede viajar en una sesión con XSS y XmlHttpRequest (HttpOnlyCookies evitará un secuestro completo). "Remember Me" hace otras amenazas como xss, csrf, oler más serio. Mientras se hayan solucionado estas vulnerabilidades, no deberías tener un problema con los hackers del mundo real.

El enfoque más fácil (y seguro) para implementar la función "recordarme" sería modificar el tiempo de espera de la sesión para que sea muy grande (unos pocos meses). Si la casilla "recordarme" está desmarcada, guarde una variable de sesión con un nuevo tiempo de espera (1 día desde el inicio de sesión). Tenga en cuenta que incluso si el navegador borra la cookie cuando está cerrada, la sesión todavía está activa en el servidor. Si se roba la identificación de la sesión, aún se puede usar.

+0

¿Qué pasa con un filtro personalizado de RememberMe que crea un nuevo token en cada solicitud? El nuevo token puede tener una vida útil corta, p. 20 minutos. Si el usuario no hace nada, el token expira. Si el usuario realiza otra solicitud en la ventana de 20 minutos, se crea una nueva ventana de 20 minutos. Si la sesión del usuario es robada de alguna manera, cambiar la contraseña del usuario aún invalidará los tokens válidos en la naturaleza ... ¿pensamientos? –

+0

Recuerdo cuando oí esta idea antes ... requiere la persistencia de la ficha a una base de datos, pero no una HttpSession: http://jaspan.com/improved_persistent_login_cookie_best_practice Tal vez Voy a mirar en la subclasificación de la PersistentTokenBasedRememberMeService en la primavera Seguridad. –

5

Spring Security 3 no ofrece la configuración de cómo se genera la cookie.Usted tiene que anular el comportamiento por defecto:

import javax.servlet.http.Cookie; 
import javax.servlet.http.HttpServletRequest; 
import javax.servlet.http.HttpServletResponse; 
import org.springframework.security.web.authentication.rememberme.PersistentTokenBasedRememberMeServices; 

/** Cookie expires on session. */ 
public class PersistentTokenBasedRememberMeServicesCustom extends 
    PersistentTokenBasedRememberMeServices { 

    /** only needed because super throws exception. */ 
    public PersistentTokenBasedRememberMeServicesCustom() throws Exception { 
    super(); 
    } 

    /** Copy of code of inherited class + setting cookieExpiration, */ 
    @Override 
    protected void setCookie(String[] tokens, int maxAge, 
     HttpServletRequest request, HttpServletResponse response) { 
    String cookieValue = encodeCookie(tokens); 
    Cookie cookie = new Cookie(getCookieName(), cookieValue); 
    //cookie.setMaxAge(maxAge); 
    cookie.setPath("/"); 
    cookie.setSecure(false); // no getter available in super, so always false 

    response.addCookie(cookie); 
    } 
} 

Asegúrese, se utiliza esta medida PersistentTokenBasedRememberMeServices para que estés rememberMeService añadiendo el nombre de la clase a su configuración de frijol:

<beans:bean id="rememberMeServices" 
class="my.custom.spring.PersistentTokenBasedRememberMeServicesCustom"/> 
Cuestiones relacionadas