Español - Ht
HackTricks Training Twitter Linkedin Sponsor

Cookies Hacking

Support HackTricks

Atributos de Cookies

Las cookies vienen con varios atributos que controlan su comportamiento en el navegador del usuario. Aquí hay un resumen de estos atributos en una voz más pasiva:

Expires y Max-Age

La fecha de caducidad de una cookie se determina por el atributo Expires. Por el contrario, el atributo Max-age define el tiempo en segundos hasta que se elimina una cookie. Opta por Max-age ya que refleja prácticas más modernas.

Dominio

Los hosts que recibirán una cookie se especifican mediante el atributo Domain. Por defecto, esto se establece en el host que emitió la cookie, sin incluir sus subdominios. Sin embargo, cuando el atributo Domain se establece explícitamente, abarca también los subdominios. Esto hace que la especificación del atributo Domain sea una opción menos restrictiva, útil para escenarios donde compartir cookies entre subdominios es necesario. Por ejemplo, establecer Domain=mozilla.org hace que las cookies sean accesibles en sus subdominios como developer.mozilla.org.

Ruta

Un camino de URL específico que debe estar presente en la URL solicitada para que se envíe el encabezado Cookie se indica mediante el atributo Path. Este atributo considera el carácter / como un separador de directorios, permitiendo coincidencias en subdirectorios también.

Reglas de Ordenación

Cuando dos cookies tienen el mismo nombre, la que se elige para enviar se basa en:

  • La cookie que coincide con la ruta más larga en la URL solicitada.

  • La cookie establecida más recientemente si las rutas son idénticas.

SameSite

  • El atributo SameSite dicta si las cookies se envían en solicitudes que provienen de dominios de terceros. Ofrece tres configuraciones:

  • Strict: Restringe el envío de la cookie en solicitudes de terceros.

  • Lax: Permite que la cookie se envíe con solicitudes GET iniciadas por sitios web de terceros.

  • None: Permite que la cookie se envíe desde cualquier dominio de terceros.

Recuerda, al configurar cookies, entender estos atributos puede ayudar a garantizar que se comporten como se espera en diferentes escenarios.

Tipo de Solicitud

Código de Ejemplo

Cookies Enviadas Cuando

Enlace

<a href="..."></a>

NotSet*, Lax, None

Prerender

<link rel="prerender" href=".."/>

NotSet*, Lax, None

Formulario GET

<form method="GET" action="...">

NotSet*, Lax, None

Formulario POST

<form method="POST" action="...">

NotSet*, None

iframe

<iframe src="..."></iframe>

NotSet*, None

AJAX

$.get("...")

NotSet*, None

Imagen

<img src="...">

NetSet*, None

Tabla de Invicti y ligeramente modificada. Una cookie con el atributo SameSite mitigará ataques CSRF donde se necesita una sesión iniciada.

*Ten en cuenta que desde Chrome80 (feb/2019) el comportamiento predeterminado de una cookie sin un atributo SameSite será lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). Ten en cuenta que temporalmente, después de aplicar este cambio, las cookies sin una política SameSite en Chrome serán tratadas como None durante los primeros 2 minutos y luego como Lax para solicitudes POST de nivel superior entre sitios.

Banderas de Cookies

HttpOnly

Esto evita que el cliente acceda a la cookie (a través de Javascript, por ejemplo: document.cookie)

Evasiones

  • Si la página está enviando las cookies como respuesta a una solicitud (por ejemplo, en una página PHPinfo), es posible abusar de la XSS para enviar una solicitud a esta página y robar las cookies de la respuesta (ver un ejemplo en https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.

  • Esto podría ser evadido con solicitudes TRACE HTTP ya que la respuesta del servidor (si este método HTTP está disponible) reflejará las cookies enviadas. Esta técnica se llama Cross-Site Tracking.

  • Esta técnica es evitada por navegadores modernos al no permitir el envío de una solicitud TRACE desde JS. Sin embargo, se han encontrado algunas evasiones en software específico como enviar \r\nTRACE en lugar de TRACE a IE6.0 SP2.

  • Otra forma es la explotación de vulnerabilidades de día cero en los navegadores.

  • Es posible sobrescribir cookies HttpOnly realizando un ataque de desbordamiento de Cookie Jar:

Cookie Jar Overflow

Seguro

La solicitud solo enviará la cookie en una solicitud HTTP solo si la solicitud se transmite a través de un canal seguro (típicamente HTTPS).

Prefijos de Cookies

Las cookies con el prefijo __Secure- deben establecerse junto con la bandera secure de páginas que están aseguradas por HTTPS.

Para las cookies con el prefijo __Host-, se deben cumplir varias condiciones:

  • Deben establecerse con la bandera secure.

  • Deben originarse de una página asegurada por HTTPS.

  • Se les prohíbe especificar un dominio, lo que impide su transmisión a subdominios.

  • La ruta para estas cookies debe establecerse en /.

Es importante tener en cuenta que las cookies con el prefijo __Host- no pueden enviarse a superdominios o subdominios. Esta restricción ayuda a aislar las cookies de la aplicación. Por lo tanto, emplear el prefijo __Host- para todas las cookies de la aplicación puede considerarse una buena práctica para mejorar la seguridad y el aislamiento.

Sobrescribiendo cookies

Así, una de las protecciones de las cookies con prefijo __Host- es evitar que sean sobrescritas desde subdominios. Previniendo, por ejemplo, ataques de Cookie Tossing. En la charla Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) se presenta que era posible establecer cookies con prefijo __HOST- desde un subdominio, engañando al analizador, por ejemplo, añadiendo "=" al principio o al final...:

O en PHP era posible añadir otros caracteres al principio del nombre de la cookie que iban a ser reemplazados por caracteres de subrayado, permitiendo sobrescribir cookies __HOST-:

Ataques de Cookies

Si una cookie personalizada contiene datos sensibles, revísala (especialmente si estás participando en un CTF), ya que podría ser vulnerable.

Decodificación y Manipulación de Cookies

Los datos sensibles incrustados en las cookies siempre deben ser examinados. Las cookies codificadas en Base64 o formatos similares a menudo pueden ser decodificadas. Esta vulnerabilidad permite a los atacantes alterar el contenido de la cookie e impersonar a otros usuarios codificando sus datos modificados de nuevo en la cookie.

Secuestro de Sesión

Este ataque implica robar la cookie de un usuario para obtener acceso no autorizado a su cuenta dentro de una aplicación. Al usar la cookie robada, un atacante puede hacerse pasar por el usuario legítimo.

Fijación de Sesión

En este escenario, un atacante engaña a una víctima para que use una cookie específica para iniciar sesión. Si la aplicación no asigna una nueva cookie al iniciar sesión, el atacante, que posee la cookie original, puede hacerse pasar por la víctima. Esta técnica se basa en que la víctima inicie sesión con una cookie proporcionada por el atacante.

Si encontraste un XSS en un subdominio o controlas un subdominio, lee:

Cookie Tossing

Donación de Sesión

Aquí, el atacante convence a la víctima para que use la cookie de sesión del atacante. La víctima, creyendo que ha iniciado sesión en su propia cuenta, realizará inadvertidamente acciones en el contexto de la cuenta del atacante.

Si encontraste un XSS en un subdominio o controlas un subdominio, lee:

Cookie Tossing

Cookies JWT

Haz clic en el enlace anterior para acceder a una página que explica posibles fallas en JWT.

Los JSON Web Tokens (JWT) utilizados en cookies también pueden presentar vulnerabilidades. Para obtener información detallada sobre posibles fallas y cómo explotarlas, se recomienda acceder al documento vinculado sobre el hacking de JWT.

Cross-Site Request Forgery (CSRF)

Este ataque obliga a un usuario autenticado a ejecutar acciones no deseadas en una aplicación web en la que actualmente está autenticado. Los atacantes pueden explotar cookies que se envían automáticamente con cada solicitud al sitio vulnerable.

Cookies Vacías

(Revisa más detalles en la investigación original) Los navegadores permiten la creación de cookies sin un nombre, lo que se puede demostrar a través de JavaScript de la siguiente manera:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

El resultado en el encabezado de la cookie enviada es a=v1; test value; b=v2;. Intrigantemente, esto permite la manipulación de cookies si se establece una cookie con un nombre vacío, potencialmente controlando otras cookies al establecer la cookie vacía a un valor específico:

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

Esto lleva a que el navegador envíe un encabezado de cookie interpretado por cada servidor web como una cookie llamada a con un valor b.

Error de Chrome: Problema de Código de Sustitución Unicode

En Chrome, si un código de sustitución Unicode es parte de una cookie establecida, document.cookie se corrompe, devolviendo una cadena vacía posteriormente:

document.cookie = "\ud800=meep";

Esto resulta en que document.cookie devuelve una cadena vacía, lo que indica una corrupción permanente.

Cookie Smuggling Debido a Problemas de Análisis

(Revisa más detalles en la investigación original) Varios servidores web, incluidos los de Java (Jetty, TomCat, Undertow) y Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), manejan incorrectamente las cadenas de cookies debido al soporte obsoleto de RFC2965. Lee un valor de cookie entre comillas dobles como un solo valor, incluso si incluye puntos y comas, que normalmente deberían separar pares clave-valor:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Vulnerabilidades de Inyección de Cookies

(Revisa más detalles en la investigación original) El análisis incorrecto de cookies por parte de los servidores, notablemente Undertow, Zope y aquellos que utilizan http.cookie.SimpleCookie y http.cookie.BaseCookie de Python, crea oportunidades para ataques de inyección de cookies. Estos servidores no delimitan adecuadamente el inicio de nuevas cookies, permitiendo a los atacantes suplantar cookies:

  • Undertow espera una nueva cookie inmediatamente después de un valor entre comillas sin un punto y coma.

  • Zope busca una coma para comenzar a analizar la siguiente cookie.

  • Las clases de cookies de Python comienzan a analizar en un carácter de espacio.

Esta vulnerabilidad es particularmente peligrosa en aplicaciones web que dependen de la protección CSRF basada en cookies, ya que permite a los atacantes inyectar cookies de token CSRF suplantadas, potencialmente eludiendo medidas de seguridad. El problema se agrava por el manejo de nombres de cookies duplicados en Python, donde la última ocurrencia anula las anteriores. También plantea preocupaciones para las cookies __Secure- y __Host- en contextos inseguros y podría llevar a eludir autorizaciones cuando las cookies se envían a servidores de back-end susceptibles a suplantación.

Comprobaciones de Cookies Extra Vulnerables

Comprobaciones básicas

  • La cookie es la misma cada vez que inicias sesión.

  • Cierra sesión e intenta usar la misma cookie.

  • Intenta iniciar sesión con 2 dispositivos (o navegadores) en la misma cuenta usando la misma cookie.

  • Verifica si la cookie tiene alguna información y trata de modificarla.

  • Intenta crear varias cuentas con nombres de usuario casi idénticos y verifica si puedes ver similitudes.

  • Revisa la opción de "recordarme" si existe para ver cómo funciona. Si existe y podría ser vulnerable, siempre usa la cookie de recordarme sin ninguna otra cookie.

  • Verifica si la cookie anterior funciona incluso después de cambiar la contraseña.

Ataques avanzados a cookies

Si la cookie permanece igual (o casi) cuando inicias sesión, esto probablemente significa que la cookie está relacionada con algún campo de tu cuenta (probablemente el nombre de usuario). Entonces puedes:

  • Intentar crear muchas cuentas con nombres de usuario muy similares y tratar de adivinar cómo está funcionando el algoritmo.

  • Intentar fuerza bruta al nombre de usuario. Si la cookie se guarda solo como un método de autenticación para tu nombre de usuario, entonces puedes crear una cuenta con el nombre de usuario "Bmin" y fuerza bruta cada bit de tu cookie porque una de las cookies que intentarás será la que pertenece a "admin".

  • Intentar Padding Oracle (puedes descifrar el contenido de la cookie). Usa padbuster.

Padding Oracle - Ejemplos de Padbuster

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster hará varios intentos y te preguntará cuál es la condición de error (la que no es válida).

Luego comenzará a descifrar la cookie (puede tardar varios minutos)

Si el ataque se ha realizado con éxito, entonces podrías intentar cifrar una cadena de tu elección. Por ejemplo, si quisieras encrypt user=administrator

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Esta ejecución te dará la cookie correctamente cifrada y codificada con la cadena user=administrator dentro.

CBC-MAC

Tal vez una cookie podría tener algún valor y podría ser firmada usando CBC. Entonces, la integridad del valor es la firma creada utilizando CBC con el mismo valor. Como se recomienda usar como IV un vector nulo, este tipo de verificación de integridad podría ser vulnerable.

El ataque

  1. Obtener la firma del nombre de usuario administ = t

  2. Obtener la firma del nombre de usuario rator\x00\x00\x00 XOR t = t'

  3. Establecer en la cookie el valor administrator+t' (t' será una firma válida de (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Si la cookie está cifrada usando ECB podría ser vulnerable. Cuando inicias sesión, la cookie que recibes tiene que ser siempre la misma.

Cómo detectar y atacar:

Crea 2 usuarios con casi los mismos datos (nombre de usuario, contraseña, correo electrónico, etc.) y trata de descubrir algún patrón dentro de la cookie dada.

Crea un usuario llamado, por ejemplo, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" y verifica si hay algún patrón en la cookie (como ECB cifra con la misma clave cada bloque, los mismos bytes cifrados podrían aparecer si el nombre de usuario está cifrado).

Debería haber un patrón (con el tamaño de un bloque utilizado). Entonces, sabiendo cómo se cifran un montón de "a", puedes crear un nombre de usuario: "a"*(tamaño del bloque)+"admin". Luego, podrías eliminar el patrón cifrado de un bloque de "a" de la cookie. Y tendrás la cookie del nombre de usuario "admin".

Referencias

Support HackTricks
PreviousCSP bypass: self + 'unsafe-inline' with IframesNextCookie Tossing

Last updated