Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-28 07:31:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/cookie-tossing.md

6.9 KiB
Raw Blame History

Cookie Tossing

Aprenda hacking 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 será capaz de 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 será capaz de 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 pode obter algumas informações interessantes (verificar o histórico de pesquisas do usuário na plataforma, a vítima pode inserir 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 (fixação de sessão), esperar até que a vítima faça login e então usar esse cookie para fazer login como a vítima.
  • Às vezes, mesmo que os cookies de sessão mudem, o atacante pode usar o anterior e ainda receber o novo.
  • 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 (neste cenário, o atacante pode fazer o usuário realizar uma solicitação CSRF, pois ele conhece o token CSRF).
  • Assim como definir o valor, o atacante também poderia obter um cookie não autenticado gerado pelo servidor, obter o token CSRF dele e usá-lo.

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á os dois 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=CookieMaisEspecíficoEMaisAntigo; iduser=MenosEspecífico;

A maioria dos sites usará apenas o primeiro valor. Portanto, se um atacante quiser definir um cookie, é melhor defini-lo antes que outro seja definido ou defini-lo 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 com que a vítima trabalhe com seu cookie, exceto no caminho específico onde o cookie malicioso definido será enviado primeiro. {% endhint %}

Bypass de Proteção

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, uma vez que o cookie legítimo for 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 pois 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.

Bomba de Cookie

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

Use o prefixo __Host no nome do cookie

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

Referências

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

Outras formas de apoiar o HackTricks: