¿La "Autorización: portador" en el encabezado de solicitud solucionará los ataques CSRF? [duplicar]

  

¿Este enfoque realmente funcionaría para prevenir los ataques CSRF?

Sí. Un atacante no puede hacer que un navegador envíe una solicitud que incluya el encabezado de autorización con el token de portador correcto. Esto es por dos razones:

• El atacante no puede establecer el encabezado de autenticación.
• El atacante no conoce el valor correcto del token, por lo que no sabría a qué configurarlo.

Sin embargo, esto podría ser sensible a los cambios en su aplicación. Por ejemplo, si alguien un día decide cambiar el sistema de autenticación a algo basado en una cookie, es posible que no se den cuenta de que están desactivando su protección CSRF al hacerlo.

Además, en el caso de que el valor de encabezado requerido sea predecible, una política CORS que permita establecer ese encabezado podría causar problemas.

En cuanto a la pregunta de SO vinculada, no estoy seguro de entender la respuesta aceptada. Pero si observa la segunda respuesta , su situación es del tipo # 2 y no del tipo # 1.

  

Sé que si soy vulnerable a los ataques XSS, se pueden leer mis cookies y se pueden robar los tokens del portador. Pero, ¿puede el XSS inyectado crear el encabezado Autorización: portador y agregar el valor robado de la cookie?

Sí, puedes hacerlo si puedes inyectar un código.

Si tiene una vulnerabilidad XSS, permitirá que el atacante omita cualquier protección CSRF que haya implementado. Por lo tanto, las preocupaciones por el XSS no se pueden utilizar para favorecer una forma de protección CSRF sobre otra: frente a XSS, todos son nulos.

Una pequeña diferencia aquí es que su token no se puede marcar como solo HTTP, ya que necesita acceder a él desde JS para ponerlo en el encabezado. En consecuencia, un atacante XSS puede robarlo y luego enviar solicitudes convenientemente desde su propia computadora. Si el token de autenticación es HTTP, solo el atacante debe hacer que el código inyectado envíe las solicitudes, lo que es un poco complicado pero no imposible.

Puede funcionar, pero XSS comprometerá la sesión completamente.

La intención de las mitigaciones de CSRF es limitar el alcance de quién puede enviar datos desde el navegador de un usuario al servidor y provocar que algo suceda. Los ataques CSRF funcionan basándose en las propiedades especiales de los navegadores web, ya que generalmente incluyen cookies en todas las solicitudes y el atacante solo necesita que el navegador envíe una solicitud a la URL de destino . Para mitigar esto, haga que la solicitud incluya datos que no forman parte de la solicitud normalmente enviada por el navegador; p.ej. un encabezado personalizado o campo de formulario, inyectado por JavaScript.

Un token de portador en el encabezado de Autorización requiere necesariamente ser agregado por JavaScript porque el navegador nunca lo incluirá (salvo NTLM / Nego / etc, pero ese es otro tema). Así que eso se ajusta razonablemente bien al requisito expuesto anteriormente.

El problema es que cualquier JavaScript ejecutado en esa página puede hacer exactamente lo mismo que su código al agregar el encabezado porque aquí no hay límites de seguridad. Eso significa que está sujeto a cualquier forma de XSS que permita la ejecución de código arbitrario. Y, de hecho, lo coloca en una posición más débil porque solo pueden robar su token y hacer lo que quieran con él fuera de los límites de un navegador, mientras que una cookie protegida no puede ser robada porque JavaScript no puede acceder a ella.

Entonces ... estás a salvo si puedes prevenir XSS completamente, pero esa es una tarea difícil en las mejores circunstancias. Dicho esto, agregar una cookie en la mezcla no necesariamente ayuda porque XSS puede generar solicitudes que agreguen el token, y el navegador aún incluirá la cookie.