Acabo de descubrir que un sitio web de un banco polaco obliga a los usuarios a abrirlo solo en una pestaña del navegador. Por ejemplo, no puede verificar su historial de transferencias mientras busca un número de cuenta al que desea enviar dinero. No puedo pensar en ninguna buena razón para hacer esto, excepto en posibles razones de seguridad. ¿Existen ventajas de seguridad al limitar un sitio a un solo sitio? Si es así, ¿qué son?
En general, no, no es razonable obligar a los usuarios a una sola pestaña. No hay razones técnicas de seguridad para hacer que un sitio web esté disponible solo para una sola pestaña. Esto generalmente es común solo debido a un mal diseño del sistema.
Forzar una sola pestaña también significa que cuando cierre la sesión, no dejará su información confidencial en otras veinte pestañas. Sin embargo, esta es una mala razón, ya que un sitio que está preocupado por esto puede usar localStorage o websocket para borrar simultáneamente todas las pestañas al cerrar sesión en una pestaña.
El factor humano de la seguridad es una razón marginal por la que algunos sitios pueden restringirse deliberadamente a una sola pestaña. Al forzar una sola pestaña, obliga a las personas a enfocarse en una cosa a la vez, y esto hace que sea menos probable que olvide algo. En mi opinión, esta es una mala razón, ya que los inconvenientes superan las ventajas.
Esta limitación no es causada por medidas de seguridad, sino simplemente por medidas económicas.
Este comportamiento que observa se puede encontrar en muchas aplicaciones web corporativas internas, y lo encontrará mucho vinculado al servidor de aplicaciones web J2EE de Java (IBM WebSphere Application Server es el más extendido).
Aunque se basan en un cliente ligero (un navegador web de uso general), estas aplicaciones a menudo están (mal) diseñadas de la misma manera que las que usan un cliente pesado (software que se ejecuta desde un archivo ejecutable instalado en su máquina).
Los sitios web generalmente se diseñan con un modelo de solicitud - respuesta en mente. El diseñador decide qué solicitudes se permiten al usuario y cuál debe ser el procesamiento y la respuesta adecuados del servidor. Esto le permite abrir tantas pestañas como desee, ya que cada vez que su navegador simplemente envía una solicitud al servidor.
Pero las aplicaciones web como la que está enfrentando están diseñadas con un modelo de transición de estado en mente.
Con un software de cliente pesado, está limitado a un flujo de trabajo muy preciso: cuando hace clic en un elemento, se le propondrán algunas opciones y se verá obligado a elegir uno de ellos o haga clic en Cancelar si está disponible, es posible que no pueda abrir directamente alguna ventana sin pasar primero por otras ventanas o menús, es posible que algunas opciones no estén siempre accesibles o habilitadas, dependiendo de su acción en curso, etc.
En cualquier momento se encuentra en un estado definido, y dependiendo de su acción con los controles de la aplicación, cambiará de su estado actual a otro, y así sucesivamente. Cada posible transición de estado está bien definida por el diseñador de la aplicación.
Dicha aplicación web simplemente toma este modelo de desarrollo inicialmente diseñado para aplicaciones de cliente pesado y lo aplica a las aplicaciones web. Obviamente, esto no se adapta bien ya que, al abrir varias pestañas, confunde la aplicación que no puede determinar cuál es su estado actual: ¿está consultando el saldo de su cuenta o ingresando una nueva transferencia bancaria? Ambos no son aceptables, ¡solo puedes estar en un estado en ese momento! Y ni siquiera menciono las características específicas del navegador, como el botón de retroceso o el marcado de una página específica que a menudo no son compatibles con dichas aplicaciones web.
Esta no es una opción de seguridad, solo es económica, ya que hace que la programación de aplicaciones sea más fácil, más rápida y, por lo tanto, más barata.
Habiendo trabajado con 8 bancos que implementaron esto de una forma u otra, estoy convencido de que es una característica de seguridad importante. Ser una pestaña es irrelevante, pero restringirse a una instancia es muy útil para reducir muchas rutas de ataque.
Si permite más de una instancia, los atacantes pueden potencialmente atacar desde otra máquina durante una sesión válida. Si solo permite uno, se eliminarán la mayoría de las variantes.
La forma general en que los bancos lo implementaron fue verificar los tokens / cookies y cerrar cualquier sesión que exista tan pronto como se negocie una nueva sesión, sin importar si se trata de una nueva pestaña, navegador o lo que sea.
Hay un banco sueco haciendo esto. Pasan un token de uso único en cada solicitud, de modo que ninguna solicitud se puede hacer dos veces. Esto significa que si alguien logra robar su cookie de sesión, no puede usarla sin que nadie se dé cuenta.
Es una pequeña adición en seguridad (que podría no ser una adición en estos días, ya que SSL / TLS ha mejorado) para un éxito bastante grande en la experiencia del usuario.
Otros bancos, como Klarna, utilizan una solución de pago de un solo clic para aumentar enormemente la experiencia del usuario, pero con un trabajo mucho más difícil de asegurarla.
En última instancia, el banco es responsable de hacer esta compensación, y limitar al usuario a una sola pestaña podría ayudarlo en cierta medida, como reducir el riesgo de filtrar datos confidenciales si un usuario se olvida de cerrar todos el pestañas.
Si se trata de una aplicación con estado, la apertura de pestañas separadas confunde al usuario porque los datos que se muestran en una pestaña no incluirán ninguna acción realizada desde otra pestaña.
Este no es un problema de seguridad, sino una opción de diseño común en las aplicaciones web porque permite operaciones más complejas sin el trabajo adicional para dejarlas sin estado.
Sí, aunque evita que la aplicación funcione en pestañas diferentes en forma incidental.
Hay una clase de vulnerabilidades de aplicaciones web llamada "fallas en la lógica de negocios" . Estos son particularmente frecuentes cuando hay un proceso de varios pasos a seguir. Al dar a un usuario un token, que se pasa página a página, y se cambia en cada paso, se garantiza que los usuarios sigan procesos de varios pasos en el orden establecido. Esto reduce el riesgo de que un desarrollador asuma que, debido a que se ha alcanzado una determinada página, todos los pasos anteriores se han seguido legítimamente.
Debido a que el token se pasa de una página a otra en los parámetros GET o POST, abrir otra página en otra pestaña hace que se cambie el token y, por lo tanto, el token en la pestaña original ya no será válido para la navegación.
Este método de pasar un token que puede validarse en el lado del servidor de la sesión también protege inherentemente contra CSRF. La protección de todo el sitio mediante este método también garantiza que no se pierda nada porque, para cada solicitud, la validación del token nunca se omite. Esto también puede proteger contra un usuario haciendo doble clic, por ejemplo. un botón de transferencia de dinero, porque el token solo será válido para la primera solicitud y garantizará que tales acciones no se envíen accidentalmente dos veces.
Ayuda. Es posible que desee ver la sugerencia de douglas crockford de una Internet más segura mediante el uso de un motor de renderizado basado en QT separado. Tiene algunos méritos.
Los méritos son: la naturaleza del dom y la zona de arena de un navegador web se anula mediante el uso de un motor de renderización separado para cada página (suponiendo que lo haya leído correctamente), por lo que no hay ninguna dom o caja de arena con la que romper. , en el caso de robo de cookies, que puede ocurrir con múltiples pestañas.
Aquí hay un enlace: enlace
Lea otras preguntas en las etiquetas web-application usability