hacktricks/pentesting-web/hacking-with-cookies/README.md

# Hackeo de Cookies

<details>

<summary><strong>Aprende a hackear AWS de cero a héroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Experto en Equipos Rojos de AWS de HackTricks)</strong></a><strong>!</strong></summary>

Otras formas de apoyar a HackTricks:

* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hackeo enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) en GitHub.

</details>

<figure><img src="/.gitbook/assets/image (675).png" alt=""><figcaption></figcaption></figure>

Encuentra vulnerabilidades que importan más para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, ejecuta exploraciones proactivas de amenazas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. [**¡Pruébalo gratis**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoy.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

***

## Atributos de las Cookies

Las cookies vienen con varios atributos que controlan su comportamiento en el navegador del usuario. Aquí tienes una descripción de estos atributos en una voz más pasiva:

### Caduca y Max-Age

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

### Dominio

Los hosts que reciben una cookie están especificados por el atributo `Domain`. Por defecto, esto se establece en el host que emitió la cookie, sin incluir sus subdominios. Sin embargo, cuando se establece explícitamente el atributo `Domain`, también abarca subdominios. Esto hace que la especificación del atributo `Domain` sea una opción menos restrictiva, útil para escenarios donde es necesaria la compartición de cookies entre subdominios. Por ejemplo, al establecer `Domain=mozilla.org` se hacen accesibles las cookies en sus subdominios como `developer.mozilla.org`.

### Ruta

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

### Reglas de Orden

Cuando dos cookies tienen el mismo nombre, la elección de cuál 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` dicta 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.

Recuerda que al configurar cookies, comprender 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   |
| Precarga        | \<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](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) y ligeramente modificada.\
Una cookie con el atributo _**SameSite**_ ayudará a **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á laxo** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](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 se tratarán como **None** durante los **primeros 2 minutos y luego como Lax para solicitudes POST entre sitios cruzados de nivel superior.**

## Banderas de las Cookies

### HttpOnly

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

#### **Bypasses**

* Si la página está **enviando las cookies como respuesta** de una solicitud (por ejemplo, en una página de **PHPinfo**), es posible abusar del XSS para enviar una solicitud a esta página y **robar las cookies** de la respuesta (consulta un ejemplo en [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/).
* Esto podría ser evitado 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 **Seguimiento entre Sitios**.
* 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 algunos bypasses a esto 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 de los navegadores.
* Es posible **sobrescribir cookies HttpOnly** realizando un ataque de desbordamiento de Cookie Jar:

{% content-ref url="cookie-jar-overflow.md" %}
[cookie-jar-overflow.md](cookie-jar-overflow.md)
{% endcontent-ref %}

* Es posible utilizar un ataque de [**Cookie Smuggling**](./#cookie-smuggling) para extraer estas cookies

### Secure

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

## Prefijos de las Cookies

Las cookies con prefijo `__Secure-` deben ser establecidas junto con la bandera `secure` en páginas que están aseguradas por HTTPS.

Para las cookies con prefijo `__Host-`, se deben cumplir varias condiciones:
- Deben ser establecidas con la bandera `secure`.
- Deben originarse desde una página asegurada por HTTPS.
- Se prohíbe especificar un dominio para estas cookies, evitando su transmisión a subdominios.
- La ruta para estas cookies debe establecerse en `/`.

Es importante tener en cuenta 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.

## Ataques a las 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 u otros 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 vuelta 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 utilizar 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 suministrada por el atacante.

Si encuentras un **XSS en un subdominio** o **controlas un subdominio**, lee:

{% content-ref url="cookie-tossing.md" %}
[cookie-tossing.md](cookie-tossing.md)
{% endcontent-ref %}

### 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á inadvertidamente acciones en el contexto de la cuenta del atacante.

Si encuentras un **XSS en un subdominio** o **controlas un subdominio**, lee:

{% content-ref url="cookie-tossing.md" %}
[cookie-tossing.md](cookie-tossing.md)
{% endcontent-ref %}

### [Cookies JWT](../hacking-jwt-json-web-tokens.md)

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

Los Tokens Web JSON (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 hackeo de JWT.

### Falsificación de Petición entre Sitios (CSRF)

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

### Cookies Vacías

(Consulta más detalles en la [investigación original](https://blog.ankursundara.com/cookie-bugs/))
Los navegadores permiten la creación de cookies sin nombre, lo cual se puede demostrar a través de JavaScript de la siguiente manera:
```js
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; valor de prueba; b=v2;`. Curiosamente, 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 en un valor específico:
```js
function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value
```
Esto lleva al navegador enviando una cabecera de cookie interpretada por cada servidor web como una cookie llamada `a` con un valor `b`.

#### Bug de Chrome: Problema de Punto de Código de Sustitución Unicode

En Chrome, si un punto de código de sustitución Unicode es parte de una cookie establecida, `document.cookie` se corrompe, devolviendo posteriormente una cadena vacía:
```js
document.cookie = "\ud800=meep";
```
Esto resulta en que `document.cookie` produzca una cadena vacía, lo que indica una corrupción permanente.

#### Contrabando de Cookies Debido a Problemas de Análisis

(Consulte más detalles en la [investigación original](https://blog.ankursundara.com/cookie-bugs/))
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 desactualizado de RFC2965. Leen un valor de cookie entre comillas dobles como un único 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

(Consulte más detalles en la [investigación original](https://blog.ankursundara.com/cookie-bugs/))
El análisis incorrecto de cookies por parte de 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 correctamente el inicio de nuevas cookies, lo que permite a los atacantes falsificar cookies:

- Undertow espera una nueva cookie inmediatamente después de un valor entre comillas sin punto y coma.
- Zope busca una coma para comenzar a analizar la siguiente cookie.
- Las clases de cookies de Python comienzan el análisis 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 tokens CSRF falsificados, 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 elusiones de autorización cuando las cookies se envían a servidores backend susceptibles a falsificaciones.


### Comprobaciones Extra de Cookies Vulnerables

#### **Comprobaciones básicas**

* La **cookie** es la **misma** cada vez que **inicias sesión**.
* Cierra la 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 iguales y verifica si puedes ver similitudes.
* Verifica la opción de "**recordarme**" si existe para ver cómo funciona. Si existe y podría ser vulnerable, siempre utiliza la cookie de **recordarme** sin ninguna otra cookie.
* Comprueba si la cookie anterior sigue funcionando incluso después de cambiar la contraseña.

#### **Ataques avanzados a cookies**

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

* Intenta crear muchas **cuentas** con nombres de usuario muy **similares** e intenta **adivinar** cómo funciona el algoritmo.
* Intenta **bruteforce 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 **bruteforce** cada **bit** de tu cookie porque una de las cookies que intentarás será la que pertenece a "**admin**".
* Prueba el **Padding Oracle** (puedes descifrar el contenido de la cookie). Usa **padbuster**.

**Padding Oracle - Ejemplos de Padbuster**
```bash
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 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 **cifrar** **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 encriptada y codificada con la cadena **user=administrator** en su interior.

**CBC-MAC**

Tal vez una cookie podría tener algún valor y estar firmada usando CBC. Entonces, la integridad del valor es la firma creada usando CBC con el mismo valor. Como se recomienda usar un vector IV 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á encriptada usando ECB podría ser vulnerable.\
Cuando inicias sesión, la cookie que recibes siempre debe ser la misma.

**Cómo detectar y atacar:**

Crear 2 usuarios con datos casi idénticos (nombre de usuario, contraseña, correo electrónico, etc.) e intentar descubrir algún patrón dentro de la cookie proporcionada.

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

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

## Referencias

* [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)

<figure><img src="/.gitbook/assets/image (675).png" alt=""><figcaption></figcaption></figure>

Encuentra vulnerabilidades que importan más para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, ejecuta escaneos proactivos de amenazas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. [**Pruébalo gratis**](https://www.intruder.io/?utm_source=referral\&utm_campaign=hacktricks) hoy.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}


<details>

<summary><strong>Aprende a hackear AWS desde cero hasta convertirte en un experto con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Otras formas de apoyar a HackTricks:

* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén la [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>