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.8 KiB
Raw Blame History

Cookie Tossing

{% hint style="success" %} Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Descrição

Se um atacante pode controlar um subdomínio ou o domínio de uma empresa ou encontra um XSS em um subdomínio, ele será capaz de realizar este 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 ser capaz de:

  • Fixar o cookie da vítima na conta do atacante, então 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 (ver o histórico de buscas do usuário na plataforma, a vítima pode ter seu cartão de crédito na conta...)
  • Se o cookie não mudar após o login, o atacante pode apenas fixar um cookie (session-fixation), 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 usa o anterior e também 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 a vítima fazer login), o atacante pode definir esse valor conhecido e então abusar dele (nesse cenário, o atacante pode então 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á 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 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 antes. {% endhint %}

Bypass de Proteção

Uma possível proteção contra este 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 onde o atacante está definindo um cookie após a vítima já ter recebido o cookie, o atacante poderia causar um overflow de cookie e então, uma vez que o cookie legítimo é deletado, definir o malicioso.

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

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

Cookie Bomb

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 em uma diretiva Set-Cookie apenas se estiver marcado como Seguro, foi enviado de uma origem segura, não incluir um atributo Domain e tiver o atributo Path definido como /
  • Isso impede que subdomínios forcem um cookie para o domínio principal, uma vez que esses cookies podem ser vistos como "bloqueados por domínio"

Referências

{% hint style="success" %} Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}