<summary><strong>Aprende a hackear AWS desde cero hasta convertirte en un experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta 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** 🐦 [**@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).
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:
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.**
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 convierte la especificación del atributo `Domain` en una opción menos restrictiva, útil para 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`.
Una ruta 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.
Tabla de [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) y ligeramente modificada.\
**\*Ten en cuenta que a partir de 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.**
* 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 **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 algunos bypasses a esto en software específico como enviar `\r\nTRACE` en lugar de `TRACE` a IE6.0 SP2.
Es importante tener en cuenta que las cookies con el 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.
Entonces, 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**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) se presentó que era posible establecer cookies con prefijo `__HOST-` desde subdominios, engañando al analizador, por ejemplo, agregando "=" al principio o al principio y al final...:
O en PHP era posible agregar **otros caracteres al principio** del nombre de la cookie que iban a ser **reemplazados por caracteres de guion bajo**, permitiendo sobrescribir cookies `__HOST-`:
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.
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.
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.
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.
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 hacking de JWT.
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.
(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:
El resultado en el encabezado de la cookie enviada es `a=v1; test value; 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:
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:
(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:
(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:
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.
- 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.
- Verifica si la cookie anterior sigue funcionando incluso después de cambiar la contraseña.
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 **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**".
- Intenta **Padding Oracle** (puedes descifrar el contenido de la cookie). Usa **padbuster**.
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**.
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.
Crear 2 usuarios con datos casi iguales (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 un montón 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".
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta 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** 🐦 [**@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).
