FixVibe
Covered by FixVibehigh

CORS Configuración incorrecta: riesgos de políticas demasiado permisivas

El intercambio de recursos entre orígenes (CORS) es un mecanismo del navegador diseñado para relajar la política del mismo origen (SOP). Si bien es necesaria para las aplicaciones web modernas, una implementación inadecuada (como hacer eco del encabezado Origen del solicitante o incluir en la lista blanca el origen "nulo") puede permitir que sitios maliciosos filtren datos privados del usuario.

CWE-942

Impacto

Un atacante puede robar datos confidenciales autenticados de los usuarios de una aplicación vulnerable [S2]. Si un usuario visita un sitio web malicioso mientras está conectado a la aplicación vulnerable, el sitio malicioso puede realizar solicitudes de origen cruzado al API de la aplicación y leer las respuestas [S1][S2]. Esto puede provocar el robo de información privada, incluidos perfiles de usuario, tokens CSRF o mensajes privados [S2].

Causa raíz

CORS es un mecanismo basado en encabezado HTTP que permite a los servidores especificar qué orígenes (dominio, esquema o puerto) pueden cargar recursos [S1]. Las vulnerabilidades generalmente surgen cuando la política CORS de un servidor es demasiado flexible o está mal implementada [S2]:

  • Encabezado de origen reflejado: Algunos servidores leen el encabezado Origin de una solicitud de cliente y lo repiten en el encabezado de respuesta Access-Control-Allow-Origin (ACAO) [S2]. Esto permite efectivamente que cualquier sitio web acceda al recurso [S2].
  • Comodines mal configurados: Si bien el comodín * permite que cualquier origen acceda a un recurso, no se puede utilizar para solicitudes que requieren credenciales (como cookies o encabezados de autorización) [S3]. Los desarrolladores a menudo intentan evitar esto generando dinámicamente el encabezado ACAO según la solicitud [S2].
  • Inclusión en lista blanca 'nula': Algunas aplicaciones incluyen en la lista blanca el origen null, que puede activarse mediante solicitudes redirigidas o archivos locales, lo que permite que sitios maliciosos se hagan pasar por un origen null para obtener acceso a [S2][S3].
  • Errores de análisis: Los errores en la expresión regular o la coincidencia de cadenas al validar el encabezado Origin pueden permitir a los atacantes usar dominios como trusted-domain.com.attacker.com [S2].

Es importante tener en cuenta que CORS no es una protección contra la falsificación de solicitudes entre sitios (CSRF) [S2].

Arreglos concretos

  • Utilice una lista blanca estática: Evite generar dinámicamente el encabezado Access-Control-Allow-Origin a partir del encabezado Origin de la solicitud [S2]. En su lugar, compare el origen de la solicitud con una lista codificada de dominios confiables [S3].
  • Evite el origen 'nulo': Nunca incluya null en su lista blanca de orígenes permitidos [S2].
  • Restringir credenciales: Configure Access-Control-Allow-Credentials: true solo si es absolutamente necesario para la interacción específica entre orígenes [S3].
  • Utilice la validación adecuada: Si debe admitir varios orígenes, asegúrese de que la lógica de validación para el encabezado Origin sea sólida y no pueda ser omitida por subdominios o dominios de apariencia similar [S2].

Cómo lo prueba FixVibe

FixVibe ahora incluye esto como una verificación activa cerrada. Después de la verificación del dominio, active.cors envía solicitudes API del mismo origen con un origen sintético del atacante y revisa los encabezados de respuesta CORS. Los informes reflejaban orígenes arbitrarios, CORS con credenciales comodín y CORS completamente abiertos en puntos finales API no públicos y al mismo tiempo evitaban el ruido de los activos públicos.