Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-25 20:43:29 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/README.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

222 lines
16 KiB
Markdown
Raw Blame History

# Hacking de Cookies
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
</details>
## Atributos de Cookies
### Expires & Max-Age
* `Expires` define uma data de expiração para quando um cookie será excluído
* `Max-age` define o tempo em segundos para quando um cookie será excluído **(use isso, não é mais 2009)**
### **Domain**
O atributo `Domain` especifica **quais hosts podem receber um cookie**. Se não especificado, o atributo **padrão** é o **mesmo host** que definiu o cookie, _**excluindo subdomínios**_. **Se `Domain` for especificado**, então **subdomínios são sempre incluídos**. Portanto, especificar `Domain` é menos restritivo do que omiti-lo. No entanto, pode ser útil quando subdomínios precisam compartilhar informações sobre um usuário.
Por exemplo, se você definir `Domain=mozilla.org`, os cookies estarão disponíveis em subdomínios como `developer.mozilla.org`. Mas se você não definir, o cookie não será enviado para subdomínios.
Se um **subdomínio** `sub.example.com` **definir um cookie** com o atributo _domain_ de **`.example.com`**, ele será **enviado** em solicitações para o **domínio pai.**
### **Path**
O atributo `Path` indica um **caminho de URL que deve existir no URL solicitado para enviar o cabeçalho `Cookie`**. O caractere `%x2F` ("/") é considerado um separador de diretório, e subdiretórios também correspondem.
#### Ordem
Quando 2 cookies têm o **mesmo nome**, aquele que é enviado é:
* Aquele com o **caminho mais longo** correspondente ao caminho do URL
* O **mais recente** se ambos tiverem o mesmo caminho
### SameSite
Isso indicará ao navegador se o **cookie** pode ser enviado **de outros domínios**. Tem 3 valores possíveis:
* **Estrito**: o cookie não será enviado junto com uma solicitação por sites de terceiros.
* **Lax**: o cookie será enviado junto com a solicitação GET iniciada por sites de terceiros.
* **Nenhum**: o cookie é enviado de qualquer domínio de terceiros
| **Tipo de solicitação** | **Código de exemplo** | **Cookies enviados quando** |
| ----------------------- | ---------------------------------- | --------------------------- |
| Link | \<a href="...">\</a> | Não definido\*, Lax, Nenhum |
| Prerender | \<link rel="prerender" href=".."/> | Não definido\*, Lax, Nenhum |
| Formulário GET | \<form method="GET" action="..."> | Não definido\*, Lax, Nenhum |
| Formulário POST | \<form method="POST" action="..."> | Não definido\*, Nenhum |
| iframe | \<iframe src="...">\</iframe> | Não definido\*, Nenhum |
| AJAX | $.get("...") | Não definido\*, Nenhum |
| Imagem | \<img src="..."> | NetSet\*, Nenhum |
Tabela de [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) e ligeiramente modificada.\
Um cookie com o atributo _**SameSite**_ irá **mitigar ataques CSRF** onde é necessária uma sessão iniciada.
**\*Observe que a partir do Chrome80 (fev/2019) o comportamento padrão de um cookie sem um atributo samesite de cookie será lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
Observe que temporariamente, após a aplicação dessa alteração, os **cookies sem uma política SameSite** no Chrome serão **tratados como Nenhum** durante os **primeiros 2 minutos e depois como Lax para solicitações POST entre sites de nível superior.**
## Flags de Cookies
### HttpOnly
Isso evita que o **cliente** acesse o cookie (por exemplo, via **Javascript**: `document.cookie`)
#### **Bypasses**
* Se a página estiver **enviando os cookies como resposta** de uma solicitação (por exemplo, em uma página **PHPinfo**), é possível abusar do XSS para enviar uma solicitação para esta página e **roubar os cookies** da resposta (verifique um exemplo em [https://hackcommander.github.io/pentesting-article-1/)](https://hackcommander.github.io/pentesting-article-1/)
* Isso pode ser contornado com solicitações **HTTP TRACE** **se a resposta do servidor refletir os cookies enviados** (se este método HTTP estiver disponível). Essa técnica é chamada de **Cross-Site Tracking**.
* Essa técnica é evitada por **navegadores modernos por não permitir o envio de uma solicitação TRACE** de JS. No entanto, alguns contornos para isso foram encontrados em software específico, como o envio de `\
```js
document.cookie = "a=v1"
document.cookie = "=test value;" // empty name
document.cookie = "b=v2"
```
Isso resulta no cabeçalho de cookie enviado:
```
a=v1; test value; b=v2;
```
Mais interessante ainda, se você tiver um vetor que de alguma forma permita **definir o cookie vazio**, você pode **controlar qualquer outro cookie**:
```js
function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}
setCookie("", "a=b"); // this sets the empty cookie to a=b
```
Embora internamente no navegador, isso seja definido como o cookie nomeado vazio, resultará no **cabeçalho do cookie enviado:**
```
a=b;
```
Significando que todo servidor web irá interpretá-lo como o cookie `a` sendo definido com o valor `b`.
### Bug do Chrome - corrupção do document.cookie <a href="#chrome-bugdocumentcookie-corruption" id="chrome-bugdocumentcookie-corruption"></a>
Se um ponto de código de substituto Unicode estiver em um cookie definido, `document.cookie` será permanentemente corrompido e retornará uma string vazia.
```js
document.cookie
// "a=b;"
document.cookie = "\ud800=meep";
document.cookie
// ""
```
### Contrabando de Cookies
Vários servidores web, incluindo os servidores Java Jetty, TomCat, Undertow e o framework web Python Zope, bem como servidores/frameworks web Python como cherrypy, web.py, aiohttp server, bottle e webob, são encontrados para **analisar incorretamente as strings de cookie** devido ao suporte restante para RFC2965, um mecanismo de citação de cookie desatualizado que usa RFC2616 para uma definição de string citada.
Especificamente, **esses servidores continuam lendo uma string de cookie quando encontram um valor de cookie entre aspas duplas (dquoted), mesmo que um ponto e vírgula seja encontrado**. Isso é problemático porque **pontos e vírgulas devem separar pares chave-valor** na string de cookie.
Por exemplo, se um **navegador envia três cookies, RENDER\_TEXT, JSESSIONID** e **ASDF:**
```basic
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
```
esses servidores os interpretam como parte de um **único valor de cookie** em vez de três cookies separados.
Isso leva a um risco de segurança: se um invasor ganhar acesso de script entre sites (XSS), ele pode usar esse bug para **extrair cookies sensíveis como cookies HttpOnly**.
### Injeção de Cookie
Muitos servidores da web, incluindo o Undertow do Java, o Zope do Python e aqueles que usam o http.cookie.SimpleCookie e http.cookie.BaseCookie do stdlib do Python, foram encontrados para **analisar incorretamente cookies, usando delimitadores errados para iniciar o próximo par de nome/valor do cookie**. Isso permite que um invasor **falsifique vários cookies enquanto controla apenas um valor de cookie**.
No caso do **Undertow**, ele começa a analisar o próximo cookie imediatamente após o **final de um valor de cookie entre aspas**, sem esperar por um ponto e vírgula:
```bash
LANGUAGE="en-us" CSRF_TOKEN="SPOOFED_VALUE"
```
**Zope** começa a analisar o próximo cookie em uma **vírgula**:
```bash
LANGUAGE=en-us,CSRF_TOKEN=SPOOFED_VALUE
```
E o **SimpleCookie** e o **BaseCookie** do Python imediatamente começam a analisar o próximo cookie em um caractere **espaço**.
```
LANGUAGE=en-us CSRF_TOKEN=SPOOFED_VALUE
```
Como resultado, servidores como **cherrypy**, **web.py**, servidor **aiohttp**, **bottle** e **webob** (Pyramid, TurboGears) são todos vulneráveis a esse tipo de ataque.
Esse problema apresenta implicações significativas de **segurança**. Por exemplo, se um aplicativo da web usa **proteção CSRF baseada em cookie**, um invasor pode **injetar** um **cookie de token CSRF falsificado** para contornar essa proteção. Além disso, o último nome de cookie duplicado nos pacotes http.cookie do Python substitui todos os anteriores, tornando esse tipo de ataque especialmente fácil.
Além disso, a **falsificação** de cookies **`__Secure-`** e **`__Host-`** pode ser explorada em um contexto inseguro. Além disso, em uma configuração em que os cookies são passados para um servidor backend, a **injeção de cookie pode levar a bypasses de autorização** se o servidor backend for suscetível a falsificação, mas o servidor frontend não for.
### Verificações extras de vulnerabilidade de cookies
#### **Verificações básicas**
* O **cookie** é o **mesmo** toda vez que você **faz login**.
* Faça logout e tente usar o mesmo cookie.
* Tente fazer login com 2 dispositivos (ou navegadores) na mesma conta usando o mesmo cookie.
* Verifique se o cookie tem alguma informação nele e tente modificá-lo.
* Tente criar várias contas com nomes de usuário quase iguais e verifique se você pode ver semelhanças.
* Verifique a opção "**lembrar-me**" se ela existir para ver como funciona. Se existir e puder ser vulnerável, sempre use o cookie de **lembrar-me** sem nenhum outro cookie.
* Verifique se o cookie anterior funciona mesmo depois de você alterar a senha.
#### **Ataques avançados de cookies**
Se o cookie permanecer o mesmo (ou quase o mesmo) quando você fizer login, isso provavelmente significa que o cookie está relacionado a algum campo da sua conta (provavelmente o nome de usuário). Então você pode:
* Tente criar muitas **contas** com nomes de usuário muito **semelhantes** e tente **adivinhar** como o algoritmo está funcionando.
* Tente **forçar o nome de usuário**. Se o cookie salvar apenas como um método de autenticação para o seu nome de usuário, você pode criar uma conta com o nome de usuário "**Bmin**" e **forçar** cada **bit** do seu cookie porque um dos cookies que você tentará será o que pertence a "**admin**".
* Tente o **Padding** **Oracle** (você pode descriptografar o conteúdo do cookie). Use o **padbuster**.
**Padding Oracle - Exemplos do Padbuster**
```bash
padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf
# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2
```
O Padbuster fará várias tentativas e perguntará qual é a condição de erro (aquela que não é válida).
Em seguida, ele começará a descriptografar o cookie (isso pode levar vários minutos).
Se o ataque for bem-sucedido, você poderá tentar criptografar uma string de sua escolha. Por exemplo, se você quiser **criptografar** **user=administrador**.
```
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
```
Essa execução irá fornecer o cookie corretamente criptografado e codificado com a string **user=administrator** dentro.
**CBC-MAC**
Talvez um cookie possa ter algum valor e ser assinado usando CBC. Então, a integridade do valor é a assinatura criada usando CBC com o mesmo valor. Como é recomendado usar um vetor nulo como IV, esse tipo de verificação de integridade pode ser vulnerável.
**O ataque**
1. Obter a assinatura do nome de usuário **administ** = **t**
2. Obter a assinatura do nome de usuário **rator\x00\x00\x00 XOR t** = **t'**
3. Definir no cookie o valor **administrator+t'** (**t'** será uma assinatura válida de **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00**
**ECB**
Se o cookie for criptografado usando ECB, ele pode ser vulnerável.\
Quando você faz login, o cookie que você recebe tem que ser sempre o mesmo.
**Como detectar e atacar:**
Crie 2 usuários com dados quase iguais (nome de usuário, senha, e-mail, etc.) e tente descobrir algum padrão dentro do cookie fornecido.
Crie um usuário chamado, por exemplo, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" e verifique se há algum padrão no cookie (como ECB criptografa com a mesma chave a cada bloco, os mesmos bytes criptografados podem aparecer se o nome de usuário for criptografado).
Deve haver um padrão (com o tamanho de um bloco usado). Então, sabendo como um monte de "a" é criptografado, você pode criar um nome de usuário: "a"\*(tamanho do bloco)+"admin". Então, você pode excluir o padrão criptografado de um bloco de "a" do cookie. E você terá o cookie do nome de usuário "admin".
## Referências
* [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
Reference in a new issue View git blame Copy permalink