search

CORS vulnerability with trusted insecure protocols

hashtag
Exploiting XSS via CORS trust relationships

Incluso un CORS configurado «correctamente» establece una relación de confianza entre dos orígenes. Si un sitio web confía en un origen vulnerable al cross-site scripting (XSS), un atacante podría aprovechar el XSS para inyectar código JavaScript que utilice CORS para recuperar información confidencial del sitio que confía en la aplicación vulnerable.

Dada la siguiente solicitud:

GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: https://subdomain.vulnerable-website.com
Cookie: sessionid=...

Si el servidor responde con:

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

Entonces, un atacante que encuentre una vulnerabilidad XSS en subdominio.sitio-web-vulnerable.com podría utilizarla para recuperar la clave API, utilizando una URL como:

https://subdomain.vulnerable-website.com/?xss=<script>cors-stuff-here</script>

hashtag
Breaking TLS with poorly configured CORS

Supongamos que una aplicación que utiliza rigurosamente HTTPS también incluye en la lista blanca un subdominio de confianza que utiliza HTTP sin cifrar. Por ejemplo, cuando la aplicación recibe la siguiente solicitud:

GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: http://trusted-subdomain.vulnerable-website.com
Cookie: sessionid=...

La aplicación responde con:

hashtag
Lab: CORS vulnerability with trusted insecure protocols

20250922180347.png

Al iniciar el laboratorio observamos una lista de articulos.

20250922180512.png

Luego iniciaremos sesion con las credenciales proporcionadas

20250922180619.png

Al iniciar session y interceptando el trafico encontraremos que hace una petición a /accountDetals

20250922180639.png

En esta ruta vemos que al hacer una petición GET obtendremos información del usuario

20250922180852.png

al agregar Origin: https://evil.com el servidor no nos refleja. Entonces al probar el dominio del sitio web, este si nos devuelve y refleja, por lo que en este sitio web solo esta permitido las peticion desde la mismo dominio.

20250922180926.png

Para poder obtener la información (apikey, session..) del usuario administrador tendremos que explotar antes un xss

20250922182417.png

En el subdominio http://stock.0a5400e203221b24816d8a2f009600e9.web-security-academy.net/?productId=%3Cscript%3Ealert(1)%3C/script%3E&storeId=2 podemos explotar del parámetro productId

20250922182611.png

Una vez encontrada la vulnerabilidad de xss, podremos enviar nuestro codigo malicioso y entregar a la victima.

al guardar y entregar a la victima, podremos ver la información del usuario administrator.

hashtag
Intranets and CORS without credentials

La mayoría de los ataques CORS se basan en la presencia del encabezado de respuesta:

Sin ese encabezado, el navegador del usuario víctima se negará a enviar sus cookies, lo que significa que el atacante solo obtendrá acceso a contenido no autenticado, al que podría acceder fácilmente navegando directamente al sitio web de destino.

Sin embargo, hay una situación habitual en la que un atacante no puede acceder directamente a un sitio web: cuando forma parte de la intranet de una organización y se encuentra dentro del espacio de direcciones IP privadas. Los sitios web internos suelen tener un nivel de seguridad inferior al de los sitios externos, lo que permite a los atacantes encontrar vulnerabilidades y obtener un mayor acceso. Por ejemplo, una solicitud de origen cruzado dentro de una red privada puede ser la siguiente:

Y el servidor responde con:

PreviousCORS vulnerability with trusted null originNextClickjacking

Last updated