hacktricks/pentesting-web/hacking-with-cookies/cookie-tossing.md

6.5 KiB

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Descrição

Se um atacante pode controlar um subdomínio ou o domínio de uma empresa ou encontrar um XSS em um subdomínio, ele poderá realizar esse ataque.

Como foi indicado na seção de Hacking de Cookies, quando um cookie é definido para um domínio (especificando-o), ele será usado no domínio e subdomínios.

{% hint style="danger" %} Portanto, um atacante poderá definir para o domínio e subdomínios um cookie específico fazendo algo como document.cookie="session=1234; Path=/app/login; domain=.example.com" {% endhint %}

Isso pode ser perigoso, pois o atacante pode:

  • Fixar o cookie da vítima na conta do atacante para que, se o usuário não perceber, ele realizará as ações na conta do atacante e o atacante poderá obter algumas informações interessantes (verificar o histórico de buscas do usuário na plataforma, a vítima pode cadastrar seu cartão de crédito na conta...)
  • Se o cookie não mudar após o login, o atacante pode simplesmente fixar um cookie, esperar até que a vítima faça login e então usar esse cookie para entrar como a vítima.
  • Se o cookie estiver definindo algum valor inicial (como no flask onde o cookie pode definir o token CSRF da sessão e esse valor será mantido após o login da vítima), o atacante pode definir esse valor conhecido e então abusar dele (nesse cenário, o atacante pode fazer o usuário realizar uma solicitação CSRF, pois ele conhece o token CSRF).

Ordem dos Cookies

Quando um navegador recebe dois cookies com o mesmo nome afetando parcialmente o mesmo escopo (domínio, subdomínios e caminho), o navegador enviará ambos os valores do cookie quando ambos forem válidos para a solicitação.

Dependendo de quem tem o caminho mais específico ou qual é o mais antigo, o navegador definirá o valor do cookie primeiro e depois o valor do outro, como em: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;

A maioria dos sites usará apenas o primeiro valor. Então, se um atacante quiser definir um cookie, é melhor definir antes que outro seja definido ou definir com um caminho mais específico.

{% hint style="warning" %} Além disso, a capacidade de definir um cookie em um caminho mais específico é muito interessante, pois você poderá fazer a vítima trabalhar com seu cookie, exceto no caminho específico onde o cookie malicioso definido será enviado antes. {% endhint %}

Proteção Bypass

Uma possível proteção contra esse ataque seria que o servidor web não aceitasse solicitações com dois cookies com o mesmo nome, mas com dois valores diferentes.

Para contornar o cenário em que o atacante está definindo um cookie depois que a vítima já recebeu o cookie, o atacante poderia causar um overflow de cookie e então, uma vez que o cookie legítimo seja excluído, definir o malicioso.

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

Outro bypass útil poderia ser codificar o nome do cookie na URL já que algumas proteções verificam se há 2 cookies com o mesmo nome em uma solicitação e então o servidor decodificará os nomes dos cookies.

Um ataque de Cookie Tossing também pode ser usado para realizar um ataque de Cookie Bomb:

{% content-ref url="cookie-bomb.md" %} cookie-bomb.md {% endcontent-ref %}

Defesas

  • Se um nome de cookie tiver esse prefixo, ele será aceito apenas em uma diretiva Set-Cookie se estiver marcado como Seguro, foi enviado de uma origem segura, não incluir um atributo de Domínio e tiver o atributo de Caminho definido para /
  • Isso impede que subdomínios forcem um cookie para o domínio principal, já que esses cookies podem ser vistos como "bloqueados por domínio"

Referências

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: