<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)!
* 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.
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 los 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, 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 de nivel superior.**
* Si la página está **enviando las cookies como respuesta** de una solicitud (por ejemplo, en una página **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 algunas formas de evadir 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 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, utilizar 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**](cookie-tossing.md). En la charla [**Cookie Crumbles: Revelando Vulnerabilidades de Integridad de Sesión Web**](https://www.youtube.com/watch?v=F\_wAzF4a7Xg) ([**documento**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) se presenta 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 depende de 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 actualmente está autenticado. 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 un nombre, lo cual se puede demostrar a través de JavaScript de la siguiente manera:
El resultado en la cabecera 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:
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.
- La **cookie** es la **misma** cada vez que te **conectas**.
- 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.
Si la cookie permanece igual (o casi igual) 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:
- 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**".
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 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 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).
