¿Cómo se protege el origen en nulo en una solicitud CORS redirigida contra un ataque de agente confuso?

Ese párrafo está escrito tersamente, y el uso de "redirecciones a otro recurso en un nuevo origen" en la primera oración no es del todo correcto.

Aquí hay un simple ejemplo artificial. Digamos que es malicioso, y hay una aplicación web que utiliza los servicios de una API privilegiada a través de CORS, por lo que la API privilegiada confía en el origen de la aplicación web. Y digamos que desea obtener acceso a los datos detrás de esa API privilegiada, pero su Origen, por supuesto, no es confiable.

Usted crea un servicio simple y útil que ofrece a través de CORS y obtiene la aplicación web para incluir su servicio en una página, cualquier página, bajo su Origen de confianza. Esa página no necesita acceder a la API privilegiada.

(Por supuesto, una vez que estés en la página de tu víctima, puedes hacer lo que quieras, pero ten paciencia.)

Si decide cambiar su servicio CORS de emitir un 200 con algunos datos para emitir un 3xx a los dominios de recursos de cruce de API privilegiados, esto crea un problema de confianza.

La API privilegiada confiará en el origen real, la página que incrustó su recurso. Pero no emitió la solicitud, y puede que no quiera estar hablando con la API privilegiada en este momento en particular.

En su lugar, emitió el redireccionamiento y, aunque en parte es confiado por el Origen, la API privilegiada no lo confía. Si el navegador sigue su 3xx y lo envía a lo largo del Origen, tiene la certeza de que cuenta con la confianza otorgada por la API privilegiada al Origen.

¿Qué es el navegador para hacer? Una respuesta razonable es no seguir el 3xx en absoluto, pero eso no permitiría los casos de uso para los cuales la confianza no es una preocupación. La emisión de la solicitud con un Origen "nulo" permite esos casos de uso, pero evita la explotación de la confianza que permitiría el envío a lo largo del encabezado de Origen original.

Mira el encabezado de Origen en términos de defensa CSRF.

Digamos a.com hosts ...

• un servicio que utiliza el Encabezado de origen para bloquear los ataques CSRF ,
• y una página web que realiza solicitudes CORS a b.com .

Si se retuviera el Origen después de las redirecciones de origen cruzado, sería posible el siguiente ataque CSRF:

1. Un usuario inicia sesión en el sitio web a.com .
2. El usuario visita una página que realiza una solicitud CORS a b.com con Origin: https://a.com .
3. b.com responde con una redirección a un punto final protegido por CSRF en a.com .
4. El navegador del usuario sigue la redirección y solicita la URL con Origin: https://a.com .

5. El servidor a.com procesa la solicitud porque cree que se originó en a.com , lo cual no es completamente preciso porque ...

   • b.com tenía control total sobre la URL solicitada, incluidos los parámetros de consulta.
   • cualquier dato en el cuerpo de la solicitud hubiera sido pensado originalmente para b.com , no a.com , y la carga de datos puede haber sido cuidadosamente diseñada para ser dañina cuando se envía al punto final a.com . (Digamos que fue un POST con una redirección 307).

El hecho de que a.com realice solicitudes de CORS a b.com no implica que confíe en b.com por completo.

Esto se trata en un error de Chrome relacionado: enlace

Si el encabezado de Origen contenía una lista de todos los orígenes en la cadena de redireccionamiento, podría ser posible crear aplicaciones que toleren los redireccionamientos de origen cruzado de manera segura. Desafortunadamente los proveedores de navegadores nunca implementaron eso. Del mismo CORS for Developers document citado en la pregunta:

  

Aunque la especificación CORS implica que puede enumerar múltiples   orígenes en el encabezado de Access-Control-Allow-Origin, en la práctica solo un   valor único es permitido por todos los navegadores modernos. El valor multiple   la sintaxis estaba destinada a permitir que todos los orígenes en una cadena de redireccionamiento sean   enumerados, según lo permitido por RFC6454, pero esto nunca se implementó.