mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-19 01:24:50 +00:00
95 lines
6.8 KiB
Markdown
95 lines
6.8 KiB
Markdown
# Cookie Tossing
|
|
|
|
{% hint style="success" %}
|
|
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
|
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
### Description
|
|
|
|
Se um atacante puder **controlar um subdomínio ou o domínio de uma empresa ou encontrar um XSS em um subdomínio**, ele será capaz de realizar este ataque.
|
|
|
|
Como foi indicado na seção de Cookies Hacking, 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 configurado 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.
|
|
|
|
### Cookie Order
|
|
|
|
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 %}
|
|
|
|
### Protection Bypass
|
|
|
|
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 **cookie overflow** 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](cookie-jar-overflow.md)
|
|
{% endcontent-ref %}
|
|
|
|
Outro **bypass** útil poderia ser **URL codificar o 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](cookie-bomb.md)
|
|
{% endcontent-ref %}
|
|
|
|
### Defense**s**
|
|
|
|
#### **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"**
|
|
|
|
### References
|
|
|
|
* [**@blueminimal**](https://twitter.com/blueminimal)
|
|
* [**https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers**](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers)
|
|
* [**https://github.blog/2013-04-09-yummy-cookies-across-domains/**](https://github.blog/2013-04-09-yummy-cookies-across-domains/)
|
|
* [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F\_wAzF4a7Xg)
|
|
|
|
{% hint style="success" %}
|
|
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
|
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
{% endhint %}
|