¿Es seguro establecer el valor del encabezado "Access Control Allow Origin" en el valor del encabezado "Origin" que está configurado implícitamente por el navegador?

Si el servidor simplemente copia el Origen provisto por el cliente en el encabezado de Access-Control-Allow-Origin de la respuesta sin más comprobaciones, entonces esencialmente permite que cualquier tercero acceda al origen del recurso, es decir, sería un problema de seguridad si el acceso de origen cruzado debería estar restringido.

Pero, si esta duplicación solo se realiza después de verificaciones adicionales, por ejemplo, solo si el cliente está autorizado, entonces esto no es un problema. Aunque también puede haber casos en los que puede ser un problema también en este caso.

En resumen: si esto es un problema o no, depende de la información que no se proporciona en la pregunta.

La vulnerabilidad que ha observado se llama CORS configuración incorrecta. Hay una buena publicación de blog por PortSwigger (Guys behind Burp suite) que habla sobre el mismo tema.

Antes de seguir adelante e intentar responder a esta pregunta, creo que es necesario conectar algunos puntos.

Lo básico

La política del mismo origen (SOP) es un control de seguridad a nivel de navegador que dicta cómo un documento o script que pertenece a un origen puede interactuar con un recurso de otro origen. Básicamente, SOP evita que los scripts se ejecuten bajo un origen desde datos de lectura desde otro origen. Puede haber casos en que una aplicación necesite permitir otros orígenes para el acceso a los recursos. Esto se logra mediante el uso compartido de recursos de origen cruzado. Puede haber problemas de seguridad potenciales debido a las configuraciones erróneas de CORS.

El problema

Ahora, entendemos que CORS se puede usar para permitir el acceso a datos de origen cruzado de una manera controlada mediante el uso de encabezados de control de acceso. Sin embargo hay un problema. los El encabezado Access-Control-Allow-Origin funciona bien si necesita confiar en solo un dominio de terceros con acceso a datos. Sin embargo, puede haber casos en los que se deba proporcionar una lista blanca de dominios de acceso a varios dominios. Aquí es donde radica el problema. Ninguno de los navegadores admite la especificación de múltiples orígenes en el encabezado de Access-Control. Ni siquiera puede cubrir subdominios usando comodines, por ejemplo.

  

Access-Control-Allow-Origin: abc.com xyz.com (NO SE APOYA)

     

Access-Control-Allow-Origin: * .example.com (NO COMPATIBLE)

Esto ha obligado a muchos desarrolladores a usar el valor del encabezado de origen de la solicitud HTTP y generar dinámicamente el encabezado Access-Control-Allow-Origin para proporcionar el acceso requerido. Básicamente, el valor del encabezado de Origen enviado en la solicitud se refleja en el encabezado Access-Control-Allow-Origin reponse (Para obtener una explicación detallada, consulte la publicación del blog anterior)

Este comportamiento viola uno de los principios básicos de seguridad:

All data coming from the client should be treated as untrusted until validated.

La vulnerabilidad

Este comportamiento básicamente anula el propósito de la misma política de origen. Como el encabezado de Access-Control-Allow-Origin puede ser controlado por el cliente, cualquier dominio malicioso ahora puede solicitar datos de la aplicación web de destino y leer la respuesta. La única condición es que el usuario objetivo debe tener el sitio de destino y el sitio malicioso abiertos en el mismo navegador al mismo tiempo, junto con una sesión autenticada con el sitio de destino. Esto proporciona acceso ilimitado al sitio malicioso que le permite realizar todo tipo de acciones de usuario y capturar datos de usuario.

Esta es una vulnerabilidad difícil de solucionar y, a menos que los navegadores comiencen a brindar un mejor soporte a las opciones de la lista blanca de CORS, debemos validar mediante programación el dominio que solicita antes de permitir el acceso de origen cruzado.