Recordarme versus sesión persistente para aplicaciones web

El principal riesgo de una sesión persistente es una mayor exposición a las vulnerabilidades existentes en el lado del cliente (por ejemplo, XSS, CSRF, reparación de sesión, etc.).

Es decir, cualquier sitio malicioso dirigido a sus usuarios a través de exploits para lo anterior tendrá más probabilidades de éxito porque el usuario se ha dejado conectado.

Con recordarme, lo anterior también podría aplicarse. Supongamos que el token recordatorio a largo plazo se intercambia por un token de sesión automáticamente por solicitud.

por ejemplo

en la solicitud que envía el navegador

Cookie: remember-me=32132213312132

y el servidor emite automáticamente un token de sesión para esta solicitud porque el token se valida. También responde con su nuevo token de sesión para que las solicitudes posteriores se utilicen en esta sesión:

Set-Cookie: session=asdkalkjdjsaddsajdsal

Esto muestra que, aunque se usa una cookie separada para el acceso a largo plazo, porque se intercambia automáticamente, también ayudará a explotaciones de dominios cruzados en las sesiones de los usuarios atacantes.

Puedes mitigar esto utilizando tokens de actualización de estilo OAuth2. Luego, si el atacante intenta un ataque CSRF como

<img src="https://example.com/transfer_money?to_acc=2321321&amount=1000000"/>

noseejecutaríaautomáticamenteporqueeltokendeactualizaciónporsísolonoessuficienteparaautenticarlasolicitud(remember-me);debeintercambiarseporuntokendeacceso(session).

porejemploSielusuariovisitasusitio,podríahaberotropasoexplícitoparaobtenereltokensessionpararepresentaraunusuarioactivoyregistrado:

<formmethod="post">
  <input type="hidden" name="anti-csrf" value="asddadaddasa242421fsas" />
</form>

El token anti-csrf se adjunta al token de actualización en la base de datos del lado del servidor, lo que evita que se utilice un exploit CSRF para obtener el token antes del ataque. Lo anterior debe ser enviado manualmente por el usuario para evitar que un atacante abra la página en una ventana emergente o dentro de un IFrame.

Solo después de todas las validaciones anteriores, el servidor responde con un token de acceso ( session ):

Set-Cookie: session=asdkalkjdjsaddsajdsal

Por supuesto, su sitio ya debería mitigar contra XSS, CSRF y similares, sin embargo, este es un enfoque de defensa en profundidad para protegerse contra el establecimiento de tokens a largo plazo que tienen una mayor probabilidad de comprometer a un usuario porque su inicio de sesión es más Es probable que estén activos en caso de ser atacados.

(Ya tenía algunos pensamientos sobre el tema, pero estaba buscando más opiniones. Como parece que causé cierta confusión, su explicación aquí puede ayudar a comprender el problema que estoy tratando de resolver).

Hay impactos funcionales muy definidos, especialmente si el desarrollador elige usar el sustrato de la sesión para almacenar información transaccional, pero eso también tiene otras complicaciones. El impacto funcional está fuera de tema aquí.

El primer argumento a favor de una función de recordar-me es que impone una actualización del estado de autenticación. Aunque no es un requisito esencial de la implementación (ni una exclusión esencial de la sesión persistente complementaria) significa que la cuenta debe volver a validarse cuando un usuario reanude la interacción después de una pausa.

De acuerdo con los comentarios anteriores, Limit ya ha notado que el consentimiento del usuario es crítico. Dejar una terminal de acceso público conectado a una cuenta no sería una buena idea. Por lo tanto, esto significa que simplemente extender la vida útil de la sesión no es una opción, el sistema debe implementar la elección del usuario. Arquitectónicamente, la opción "recordar-me" está menos vinculada a la administración de la sesión, lo que facilita su implementación y, por lo tanto, es más segura.

Una consideración adicional es que, en el caso de las sesiones de larga duración, la información necesaria para hacerse cargo de esas sesiones se almacena en las copias de seguridad. Esto también es cierto cuando la cookie "recordarme" contiene una referencia a los datos del lado del servidor.

Si el contenido "recordatorio" es información autocontenida, adecuadamente protegida por medios criptográficos, entonces cualquier persona con acceso a una copia de los datos del servidor todavía tiene un aro adicional para acceder a una sesión, es decir, Necesidad de reproducir el crypto utilizado para crear los datos del lado del cliente. Por supuesto, si también tienen acceso al código, es probable que tengan acceso a cualquier clave, pero esto tendrá un valor limitado si la clave se deriva de otros datos restringidos, como la dirección IP del cliente. Por otro lado, podría decirse que las mismas protecciones podrían aplicarse a la ID de sesión en una sesión persistente.

La siguiente consideración es el contenido de los datos de la sesión. Si hay más que la identidad de la cuenta y el estado de autenticación (por ejemplo, datos integrados de otros servicios), puede tener algún valor intrínseco para un atacante. En este escenario, reducir el rendimiento al eliminar los datos de los usuarios inactivos (es decir, la opción "Recordarme") tiene algún beneficio.

En general, estoy luchando para ver cualquier argumento positivo para el enfoque de sesión persistente desde un punto de vista de seguridad.