Access-control-allow-origin: * con un token de portador

Hay algunas cosas que harán que la explotación sea improbable.

Para empezar con

access-control-allow-credentials: true
access-control-allow-origin: *

es una combinación no válida :

  

Nota importante: al responder a una solicitud con credenciales, el servidor   debe especificar un dominio, y no puede usar comodín. El ejemplo anterior   fallaría si el encabezado fuera comodín como:   Acceso-Control-Permitir-Origen: *. Desde el Access-Control-Allow-Origin   menciona explícitamente http://foo.example , el conocedor de credenciales   el contenido se devuelve al contenido web que invoca.

Otra cosa es que the el encabezado de autorización no es un encabezado simple , por lo que requeriría una verificación previa que resulte en un Access-Control-Allow-Headers respondiendo ese encabezado. El servidor que no devuelva esto también evitaría cualquier ataque CSRF, porque el pre-vuelo lo bloqueará.

A menos que permita el encabezado, generalmente no es posible agregar un dominio cruzado de encabezado personalizado a menos que usted intente un exploit con Flash que solía funcionar en ciertos navegadores.

  

¿Cuáles son los riesgos con este modelo? ¿Es esta una forma sensata de hacerlo?   cosas?

Como no es válido especificar esta combinación de encabezados, de hecho, esta no es una forma sensata de hacer las cosas. Puede haber algún navegador extraño por ahí que lo permita y el sitio sería vulnerable (en caso de que alguna víctima potencial lo esté usando). Permitir que todos los orígenes, pero no las solicitudes con credenciales, permitan que el navegador de la víctima se use como una especie de proxy para poder acceder de otro modo recursos inaccesibles. Sin embargo, como el encabezado del portador no se puede adjuntar (sin un exploit Flash) y se permite a través de Access-Control-Allow-Headers , no diría que esto es un alto riesgo. Además, como el atacante no tiene el token de portador de su víctima, cualquier solicitud de dominio cruzado que se realizaría estaría bajo la sesión del atacante en lugar de la de su víctima.

Probablemente lo señalaría como un elemento de aviso que deberían revisar para que sus encabezados CORS coincidan con su intención.

El token de la OMI + el CORS permisivo compone dos decisiones erróneas en una que es potencialmente desastrosa.

El enfoque del token de portador aumenta considerablemente la exposición del token a través de (1) las comunicaciones de red, confiando así en que TLS se configurará correctamente, y (2) en el extremo del agente de usuario (navegador, dispositivo móvil) donde el token deberá estar protegido y cuidadosamente manejado.

Lamentablemente, la configuración permisiva de CORS agrava aún más sus problemas de seguridad del lado del cliente. Dado que el agente de usuario tiene permiso para conectarse a cualquier otro dominio para descargar bibliotecas JS, es mejor que se aseguren de que estos otros sitios no solo sean confiables, sino que también tengan una excelente seguridad, por lo que no se pueden comprometer fácilmente. No desea que el token que reside en el agente de usuario sea robado por algún script malicioso descargado de otro sitio, ese es el riesgo que se presenta cuando combina estas dos opciones.

Recomendaciones para mitigar el robo de tokens:

• Si el token de portador es absolutamente necesario, restrinja CORS para evitar el acceso a varios dominios.
• Por otra parte, si es necesario el dominio cruzado, use la concesión de código de autorización donde el token reside completamente en el lado del servidor y nunca se expone al agente de usuario.