Intercambio de recursos de origen cruzado (CORS): Explicación y PoC

    El intercambio de recursos de origen cruzado, conocido como CORS, es una medida que restringe el acceso a recursos desde diferentes lugares, como dominios o protocolos distintos. Su propósito es proteger la privacidad y seguridad de los usuarios al evitar accesos no autorizados a información sensible desde otros sitios web. Es utilizado con frecuencia por las API web en particular, pero en un sitio web complejo moderno puede aparecer en cualquier lugar. Se entiende ampliamente que ciertas configuraciones CORS son peligrosas, pero algunas sutilezas e implicaciones asociadas se malinterpretan fácilmente.

    Por ejemplo, si tenemos una aplicación web en "curiosidadesdehackers.com" que utiliza una API en "api.curiosidadesdehackers.com", CORS asegura que solo las solicitudes desde "curiosidadesdehackers.com" sean permitidas hacia "api.curiosidadesdehackers.com". Cualquier intento de acceso desde un dominio no autorizado, como "atacante.com", será bloqueado por el navegador.

    Sin embargo, si la aplicación no tiene una configuración CORS adecuada, un atacante podría explotar esta vulnerabilidad para acceder a datos sensibles. Por ejemplo, podría inyectar código malicioso en una página web para realizar solicitudes a la API en "api.example.com".

    El atacante podría utilizar herramientas automatizadas para probar distintos encabezados CORS y encontrar una configuración incorrecta que permita la solicitud desde otro dominio. Si logra hacerlo, podría acceder a información confidencial, como datos de inicio de sesión o modificar datos de la aplicación.

    Para prevenir este tipo de ataques, es esencial configurar correctamente CORS en la aplicación web y permitir únicamente solicitudes de dominios confiables.

    Los sitios web permiten CORS enviando el siguiente encabezado de respuesta HTTP:

    Access-Control-Allow-Origin: https://example.com

Esto permite que el origen listado (dominio) haga que los visitantes emitan solicitudes entre dominios al servidor y lean las respuestas. De forma predeterminada, esta solicitud se emitirá sin cookies u otras credenciales, por lo que puede usarse para robar información confidencial. El servidor puede habilitar la transmisión de credenciales utilizando el siguiente encabezado:

Access-Control-Allow-Credentials: true


PoC


Para este laboratorio usaremos Sfk-Labs

    Es importante buscar configuraciones inseguras, como el uso de un comdín "*" como valor del encabezado Access-Control-Allow-Origin, lo que significa que se permite el acceso desde cualquier dominio.

Procedemos a iniciar sesión en la aplicación de destino como admin:admin para autenticarnos.


Ahora que hemos iniciado sesión como usuario objetivo, veamos parte del tráfico interceptado con burpsuite


    Como vemos la aplicacitiene CORS habilitado y ha establecido un comodín para el encabezado de respuesta "Access-Control-Allow-Origin".

   Ahora, si agregamos un encabezado de solicitud "Origin", encontramos que el valor del encabezado Origin agregado se asigna dinámicamente al encabezado "Access-Control-Allow-Origin".


    El resto del ataque se asemejará a un ataque CSRF (Cross-Site Request Forgery). Sin embargo, en lugar de efectuar un cambio en el estado en nombre del usuario objetivo, llevaremos a cabo una solicitud GET desde nuestro dominio para extraer información.

    Esto es posible debido a que se permite la carga de recursos desde cualquier lugar, por lo que crearemos un script que nos permita obtener dicha información.

    Primero configuraremos un servidor que permita hacer peticiones


    Ahora nos 
creamos un script malicioso para que cuándo la victima ingrese en nuestra pagina, almacene todo lo que ve en la web y nos lo mande 


    Interceptamos la solicitud desde el servidor que hemos creado hacia la web objetivo. En esta solicitud, encontramos el encabezado "Origin" adjunto a la solicitud desde la fuente "http://127.0.0.1:1337", como era de esperarse. Es importante señalar que al eliminar este encabezado de la solicitud, el ataque deja de funcionar.


    Y si accedemos a nuestro servidor podremos ver toda la información confidencial. 


    Cabe destacar que cada vez que el navegador descubra el mismo encabezado apuntara hacia nuestro servidor.

2 comentarios: