Cookie Tossing

Reading time: 5 minutes

tip

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

Apoya a HackTricks

Descripción

Si un atacante puede controlar un subdominio o el dominio de una empresa o encuentra un XSS en un subdominio, podrá realizar este ataque.

Como se indicó en la sección de Hacking de Cookies, cuando una cookie se establece en un dominio (especificándolo) se utilizará en el dominio y subdominios.

caution

Por lo tanto, un atacante podrá establecer en el dominio y subdominios una cookie específica haciendo algo como document.cookie="session=1234; Path=/app/login; domain=.example.com"

Esto puede ser peligroso ya que el atacante podría:

  • Fijar la cookie de la víctima a la cuenta del atacante para que si el usuario no se da cuenta, realice las acciones en la cuenta del atacante y el atacante pueda obtener información interesante (ver el historial de búsquedas del usuario en la plataforma, la víctima puede configurar su tarjeta de crédito en la cuenta...)
  • Un ejemplo de esto se puede encontrar aquí donde el atacante establece su cookie en secciones específicas que una víctima usará para autorizar acceso a sus repositorios de git pero desde la cuenta del atacante ya que estará configurando sus cookies en los endpoints necesarios.
  • Si la cookie no cambia después del inicio de sesión, el atacante puede simplemente fijar una cookie (session-fixation), esperar a que la víctima inicie sesión y luego usar esa cookie para iniciar sesión como la víctima.
  • A veces, incluso si las cookies de sesión cambian, el atacante usa la anterior y también recibirá la nueva.
  • Si la cookie está configurando algún valor inicial (como en flask donde la cookie puede configurar el token CSRF de la sesión y este valor se mantendrá después de que la víctima inicie sesión), el atacante puede establecer este valor conocido y luego abusar de él (en ese escenario, el atacante puede hacer que el usuario realice una solicitud CSRF ya que conoce el token CSRF).
  • Al igual que establecer el valor, el atacante también podría obtener una cookie no autenticada generada por el servidor, obtener el token CSRF de ella y usarlo.

Orden de Cookies

Cuando un navegador recibe dos cookies con el mismo nombre afectando parcialmente el mismo alcance (dominio, subdominios y ruta), el navegador enviará ambos valores de la cookie cuando ambos sean válidos para la solicitud.

Dependiendo de quién tenga la ruta más específica o cuál sea la más antigua, el navegador establecerá primero el valor de la cookie y luego el valor de la otra como en: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;

La mayoría de los sitios web solo usarán el primer valor. Entonces, si un atacante quiere establecer una cookie, es mejor configurarla antes de que se establezca otra o configurarla con una ruta más específica.

warning

Además, la capacidad de establecer una cookie en una ruta más específica es muy interesante ya que podrás hacer que la víctima trabaje con su cookie excepto en la ruta específica donde la cookie maliciosa establecida será enviada primero.

Bypass de Protección

Una posible protección contra este ataque sería que el servidor web no acepte solicitudes con dos cookies con el mismo nombre pero dos valores diferentes.

Para eludir el escenario donde el atacante está configurando una cookie después de que la víctima ya recibió la cookie, el atacante podría causar un desbordamiento de cookies y luego, una vez que la cookie legítima sea eliminada, establecer la maliciosa.

Cookie Jar Overflow

Otro bypass útil podría ser codificar en URL el nombre de la cookie ya que algunas protecciones verifican 2 cookies con el mismo nombre en una solicitud y luego el servidor decodificará los nombres de las cookies.

Un ataque de Cookie Tossing también puede ser utilizado para realizar un Cookie Bomb ataque:

Cookie Bomb

Defensas

Usar el prefijo __Host en el nombre de la cookie

  • Si un nombre de cookie tiene este prefijo, solo será aceptado en una directiva Set-Cookie si está marcado como Seguro, fue enviado desde un origen seguro, no incluye un atributo de Dominio y tiene el atributo de Ruta establecido en /
  • Esto previene que los subdominios fuerzan una cookie al dominio principal ya que estas cookies pueden ser vistas como "bloqueadas por dominio"

Referencias

tip

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

Apoya a HackTricks