He estado revisando la hoja de trucos para la gestión de sesiones de OWASP y no entiendo el razonamiento detrás del sugerencia para " Inhabilitar sesiones de tabla cruzada del navegador web ". ¿De qué manera el uso de la misma ID de sesión para varias pestañas del navegador presenta una vulnerabilidad de seguridad?
Es probable que esté bajo la idea de que si una pestaña del navegador se ve comprometida, es posible que la otra pestaña del navegador no esté comprometida.
Esto podría ayudar a reducir el impacto de los enlaces maliciosos enviados por correo electrónico. Por ejemplo, haga clic en el enlace en un correo electrónico para intentar ejecutar un XSS vuln reflejado y obtendrá una nueva pestaña sin una sesión, entonces el enlace no tiene efecto. También puede haber otras vulnerabilidades similares con las que esto podría estar diseñado para ayudar.
Sin embargo, esto parece ser una solución compleja para brindar defensa en profundidad solo para una parte de una falla de seguridad donde la solución real es una aplicación con arquitectura adecuada que utiliza los marcos de seguridad adecuados (como un marco de interfaz de usuario web seguro) para evitar la Cárguelo en primer lugar de una manera mucho menos complicada que no rompa la usabilidad normal de las aplicaciones web.
Supongo que, en principio, se debe a que es para evitar la posibilidad de que una Persona Mala pueda secuestrar tu sesión.
Si dicha persona estuviera tocando su sesión, entonces tendría su cookie (o, de manera menos trivial, el valor mágico en las páginas que identifican su sesión) y luego todo lo que tendrían que hacer es falsificar su dirección IP. / p>
Por supuesto, si su sesión estuviera encriptada, esto no debería ser posible, pero presumiblemente esta regla no supone que sea así, ni confíe en ella.
No es algo con lo que HTTP pueda lidiar, pero la regla en sí misma señala que:
Las aplicaciones web pueden usar el código JavaScript una vez que el usuario haya iniciado sesión y se ha establecido una sesión para obligar al usuario a volver a autenticar
Por lo tanto, no puede admitir a los usuarios que no desean utilizar JavaScript o cuyo navegador no lo admite. Su lógica de seguimiento de sesión entonces, implementada en JavaScript, digamos, conserva la información de la sesión local solamente en la sesión de la pestaña del navegador. Debe asegurarse de que esta implementación también sea portátil en todos los navegadores que desee admitir.
Recomendaría usar una implementación bien conocida para esto en lugar de rodar la suya propia. Me imagino que los marcos de JavaScript más conocidos son compatibles con esto.
Hay más información sobre lo que podría necesitar hacer específicamente aquí: enlace
Actualizar:
Hay otros pocos escenarios que vienen a la mente.
Un sitio de venta de entradas podría hacer algo como esto para evitar que sus clientes "jueguen" con un sistema de colas ejecutando varias pestañas. Pero este es realmente un problema de administración de sesión, porque el cliente está ejecutando efectivamente varias "sesiones de puesta en cola" dentro de su sesión real.
También puede simplificar el diseño del sitio si no necesita preocuparse por las condiciones de carrera entre las diferentes actividades del usuario, lo que obliga a hacer "una cosa a la vez", aunque esto es más un UX que un problema de seguridad.
Finalmente, esta regla también podría frustrar las actividades del software de raspado o bots (como los que podrían usarse en sitios de tickets, por ejemplo). Esto sería una contramedida eficaz contra el inicio de sesión de un atacante a través del navegador para capturar una sesión y luego continuar la sesión con el bot.
Lea otras preguntas en las etiquetas web-application web-browser session-management