Protección CSRF para AJAX cuando se usan varias pestañas del navegador

9

Digamos que tengo esa aplicación web que tiene una protección CSRF de acuerdo con Patrón del token del sincronizador . El servidor espera un token CSRF válido en cada solicitud POST cuando el usuario está autenticado. Ahora imagine el siguiente escenario:

  1. El usuario abre una pestaña del navegador (pestaña anonymous ) e inicia alguna funcionalidad AJAX que lee periódicamente desde el servidor (por ejemplo, una marca de hora). El usuario está no autenticado en esta pestaña.

  2. El usuario abre una nueva pestaña del navegador (pestaña authenticated ) y realiza un inicio de sesión allí. Si ahora carga el marco AJAX, el token CSRF se escribe en el código fuente del marco AJAX por parte del servidor y se almacena en la variable token .

  3. Si la siguiente encuesta automática se realiza desde la pestaña anonymous , la cookie de la sesión se envía para indicar que el usuario ha iniciado sesión, pero esta pestaña nunca recibió un token CSRF desde que se cargó el marco AJAX antes de realizando el inicio de sesión en la pestaña authenticated .
    Esto provocará un error lanzado por el servidor porque recibió un token de sesión válido sin el token de protección CSRF.

¿Cómo puedo superar esto?

Editar:
Las cosas se ponen aún peor si el usuario

  • hace un inicio de sesión en la pestaña 1 ( user1 )
  • abre la pestaña 2
  • hace un cierre de sesión en la pestaña 2
  • realiza un nuevo inicio de sesión en la pestaña 2 (usuario diferente, user2 )

En ese caso, la primera pestaña proporciona el token CSRF anteriormente válido de user1 pero la cookie de la sesión enviada pertenece a user2 conectado en la pestaña 2. Esto debe conducir a un error emitido por la protección CSRF (por cierto, en términos de códigos de error HTTP: ¿qué usar? 403 parece como si pudiera usarse, pero no estoy seguro).

Sentirse como si todo el CSRF pudiera resolverse muy bien en teoría pero podría ser útil en tiempos de AJAX.

¿Hay alguna solución canónica para el problema descrito anteriormente? ¿O los usuarios simplemente aceptan que tienen que volver a cargar una página debido a cosas de seguridad que no coinciden?

    
pregunta eckes 12.11.2012 - 09:04
fuente

2 respuestas

4

Puede tener una marca en sus solicitudes anónimas para informarles que siempre se las trata como anónimas, a pesar de la presencia de la cookie de autenticación.

por ejemplo { "Anon" : "true" }

Esto siempre hará que los resultados públicos de la solicitud se devuelvan y no se considerará en la lógica ninguna cookie de autenticación o token de solicitud CSRF.

    
respondido por el SilverlightFox 12.11.2012 - 10:21
fuente
0

Por lo que he visto, todas las pestañas de los navegadores y las ventanas abiertas del mismo sitio web comparten los mismos datos de cookies. Un conjunto de cookies en una pestaña es visible en todas las demás pestañas.

Con respecto a la protección CSRF en una acción POST de HTTP, hay un valor incrustado en la salida HTML. Podría incluir un valor en HTML que se devuelva al POST y que le indique al back-end que ignore cualquier token de autenticación que pueda estar presente.

Tendría que agregar este token HTML a todas y cada una de las páginas web que usan protección CSRF y actualizar cada POST de Javascript para enviar este valor cuando se trate de solicitudes de servicio.

Es un poco peludo, dependiendo de lo complejo que sea su sitio, pero se puede hacer.

    
respondido por el random65537 13.11.2012 - 00:01
fuente

Lea otras preguntas en las etiquetas