Aprenda e pratique Hacking AWS:<imgsrc="../../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../../.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="../../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
{% endhint %}
## Cookie Attributes
Os cookies vêm com vários atributos que controlam seu comportamento no navegador do usuário. Aqui está um resumo desses atributos em uma voz mais passiva:
### Expires e Max-Age
A data de expiração de um cookie é determinada pelo atributo `Expires`. Por outro lado, o atributo `Max-age` define o tempo em segundos até que um cookie seja excluído. **Opte por `Max-age`, pois reflete práticas mais modernas.**
### Domain
Os hosts que recebem um cookie são especificados pelo atributo `Domain`. Por padrão, isso é definido para o host que emitiu o cookie, não incluindo seus subdomínios. No entanto, quando o atributo `Domain` é explicitamente definido, ele abrange subdomínios também. Isso torna a especificação do atributo `Domain` uma opção menos restritiva, útil para cenários onde o compartilhamento de cookies entre subdomínios é necessário. Por exemplo, definir `Domain=mozilla.org` torna os cookies acessíveis em seus subdomínios como `developer.mozilla.org`.
### Path
Um caminho de URL específico que deve estar presente na URL solicitada para que o cabeçalho `Cookie` seja enviado é indicado pelo atributo `Path`. Este atributo considera o caractere `/` como um separador de diretório, permitindo correspondências em subdiretórios também.
### Ordering Rules
Quando dois cookies têm o mesmo nome, o escolhido para envio é baseado em:
* O cookie que corresponde ao caminho mais longo na URL solicitada.
* O cookie definido mais recentemente se os caminhos forem idênticos.
### SameSite
* O atributo `SameSite` dita se os cookies são enviados em solicitações originadas de domínios de terceiros. Ele oferece três configurações:
* **Strict**: Restringe o cookie de ser enviado em solicitações de terceiros.
* **Lax**: Permite que o cookie seja enviado com solicitações GET iniciadas por sites de terceiros.
* **None**: Permite que o cookie seja enviado de qualquer domínio de terceiros.
Lembre-se, ao configurar cookies, entender esses atributos pode ajudar a garantir que eles se comportem como esperado em diferentes cenários.
| **Tipo de Solicitação** | **Código de Exemplo** | **Cookies Enviados Quando** |
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**_**mitigará ataques CSRF** onde uma sessão logada é necessária.
**\*Observe que a partir do Chrome80 (fev/2019) o comportamento padrão de um cookie sem um atributo samesite** **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 aplicar essa mudança, os **cookies sem uma política SameSite****no Chrome serão****tratados como None** durante os **primeiros 2 minutos e depois como Lax para solicitações POST de nível superior entre sites.**
Isso evita que o **cliente** acesse o cookie (via **Javascript**, por exemplo: `document.cookie`)
#### **Bypasses**
* Se a página **estiver enviando os cookies como resposta** a uma solicitação (por exemplo, em uma página **PHPinfo**), é possível abusar do XSS para enviar uma solicitação a essa página e **roubar os cookies** da resposta (ver um exemplo em [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/).
* Isso pode ser contornado com solicitações **TRACE****HTTP**, pois a resposta do servidor (se esse método HTTP estiver disponível) refletirá os cookies enviados. Essa técnica é chamada de **Cross-Site Tracking**.
* Essa técnica é evitada por **navegadores modernos ao não permitir o envio de uma solicitação TRACE** a partir do JS. No entanto, alguns contornos para isso foram encontrados em softwares específicos, como enviar `\r\nTRACE` em vez de `TRACE` para IE6.0 SP2.
* Outra maneira é a exploração de vulnerabilidades zero-day dos navegadores.
* É possível **sobrescrever cookies HttpOnly** realizando um ataque de transbordamento de Cookie Jar:
{% content-ref url="cookie-jar-overflow.md" %}
[cookie-jar-overflow.md](cookie-jar-overflow.md)
{% endcontent-ref %}
* É possível usar o ataque de [**Cookie Smuggling**](./#cookie-smuggling) para exfiltrar esses cookies.
### Secure
A solicitação **somente** enviará o cookie em uma solicitação HTTP se a solicitação for transmitida por um canal seguro (tipicamente **HTTPS**).
* Eles são proibidos de especificar um domínio, impedindo sua transmissão para subdomínios.
* O caminho para esses cookies deve ser definido como `/`.
É importante notar que cookies prefixados com `__Host-` não podem ser enviados para superdomínios ou subdomínios. Essa restrição ajuda a isolar cookies de aplicação. Assim, empregar o prefixo `__Host-` para todos os cookies de aplicação pode ser considerado uma boa prática para aumentar a segurança e a isolação.
Assim, uma das proteções dos cookies prefixados com `__Host-` é impedir que eles sejam sobrescritos a partir de subdomínios. Prevenindo, por exemplo, [**ataques de Cookie Tossing**](cookie-tossing.md). Na palestra [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) é apresentado que foi possível definir cookies prefixados com \_\_HOST- a partir de subdomínios, enganando o parser, por exemplo, adicionando "=" no início ou no final...:
Ou em PHP, foi possível adicionar **outros caracteres no início** do nome do cookie que seriam **substituídos por caracteres de sublinhado**, permitindo sobrescrever cookies `__HOST-`:
Se um cookie personalizado contém dados sensíveis, verifique-o (especialmente se você estiver participando de um CTF), pois pode ser vulnerável.
### Decoding and Manipulating Cookies
Dados sensíveis incorporados em cookies devem sempre ser examinados. Cookies codificados em Base64 ou formatos semelhantes podem frequentemente ser decodificados. Essa vulnerabilidade permite que atacantes alterem o conteúdo do cookie e se façam passar por outros usuários, codificando seus dados modificados de volta no cookie.
Esse ataque envolve roubar o cookie de um usuário para obter acesso não autorizado à sua conta dentro de uma aplicação. Usando o cookie roubado, um atacante pode se passar pelo usuário legítimo.
Nesse cenário, um atacante engana uma vítima para usar um cookie específico para fazer login. Se a aplicação não atribuir um novo cookie ao fazer login, o atacante, possuindo o cookie original, pode se passar pela vítima. Essa técnica depende da vítima fazer login com um cookie fornecido pelo atacante.
Se você encontrou um **XSS em um subdomínio** ou **controla um subdomínio**, leia:
{% content-ref url="cookie-tossing.md" %}
[cookie-tossing.md](cookie-tossing.md)
{% endcontent-ref %}
### Session Donation
Aqui, o atacante convence a vítima a usar o cookie de sessão do atacante. A vítima, acreditando que está logada em sua própria conta, realizará inadvertidamente ações no contexto da conta do atacante.
Se você encontrou um **XSS em um subdomínio** ou **controla um subdomínio**, leia:
Clique no link anterior para acessar uma página explicando possíveis falhas em JWT.
Tokens Web JSON (JWT) usados em cookies também podem apresentar vulnerabilidades. Para informações detalhadas sobre possíveis falhas e como explorá-las, recomenda-se acessar o documento vinculado sobre hacking JWT.
### Cross-Site Request Forgery (CSRF)
Esse ataque força um usuário logado a executar ações indesejadas em uma aplicação web na qual está atualmente autenticado. Atacantes podem explorar cookies que são automaticamente enviados com cada solicitação para o site vulnerável.
### Empty Cookies
(Verifique mais detalhes na [pesquisa original](https://blog.ankursundara.com/cookie-bugs/)) Os navegadores permitem a criação de cookies sem um nome, o que pode ser demonstrado através do JavaScript da seguinte forma:
```js
document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"
```
O resultado no cabeçalho de cookie enviado é `a=v1; test value; b=v2;`. Intrigantemente, isso permite a manipulação de cookies se um cookie com nome vazio for definido, potencialmente controlando outros cookies ao definir o cookie vazio para um valor específico:
```js
function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}
setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value
```
Isso leva o navegador a enviar um cabeçalho de cookie interpretado por cada servidor web como um cookie chamado `a` com um valor `b`.
#### Bug do Chrome: Problema de Código de Substituição Unicode
No Chrome, se um código de substituição Unicode fizer parte de um cookie definido, `document.cookie` fica corrompido, retornando uma string vazia posteriormente:
```js
document.cookie = "\ud800=meep";
```
Isso resulta em `document.cookie` retornando uma string vazia, indicando corrupção permanente.
#### Cookie Smuggling Devido a Problemas de Análise
(Consulte mais detalhes na [pesquisa original](https://blog.ankursundara.com/cookie-bugs/)) Vários servidores web, incluindo os de Java (Jetty, TomCat, Undertow) e Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), manipulam incorretamente strings de cookies devido ao suporte desatualizado do RFC2965. Eles leem um valor de cookie entre aspas duplas como um único valor, mesmo que inclua ponto e vírgulas, que normalmente deveriam separar pares chave-valor:
(Consulte mais detalhes na [pesquisa original](https://blog.ankursundara.com/cookie-bugs/)) A análise incorreta de cookies pelos servidores, notavelmente Undertow, Zope e aqueles que usam `http.cookie.SimpleCookie` e `http.cookie.BaseCookie` do Python, cria oportunidades para ataques de injeção de cookies. Esses servidores falham em delimitar corretamente o início de novos cookies, permitindo que atacantes falsifiquem cookies:
* Undertow espera um novo cookie imediatamente após um valor entre aspas sem um ponto e vírgula.
* Zope procura uma vírgula para começar a analisar o próximo cookie.
* As classes de cookies do Python começam a analisar em um caractere de espaço.
Essa vulnerabilidade é particularmente perigosa em aplicações web que dependem de proteção CSRF baseada em cookies, pois permite que atacantes injetem cookies de token CSRF falsificados, potencialmente contornando medidas de segurança. O problema é agravado pelo tratamento de nomes de cookies duplicados pelo Python, onde a última ocorrência substitui as anteriores. Também levanta preocupações para cookies `__Secure-` e `__Host-` em contextos inseguros e pode levar a contornos de autorização quando cookies são passados para servidores de back-end suscetíveis a falsificação.
De acordo com [**este blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), pode ser possível usar o atributo de cookie **`$Version=1`** para fazer o back-end usar uma lógica antiga para analisar o cookie devido ao **RFC2109**. Além disso, outros valores como **`$Domain`** e **`$Path`** podem ser usados para modificar o comportamento do back-end com o cookie.
#### Análise de contorno de valor com codificação de string entre aspas
Essa análise indica desescapar valores escapados dentro dos cookies, então "\a" se torna "a". Isso pode ser útil para contornar WAFS, como:
No RFC2109, é indicado que uma **vírgula pode ser usada como um separador entre valores de cookies**. E também é possível adicionar **espaços e tabulações antes e depois do sinal de igual**. Portanto, um cookie como `$Version=1; foo=bar, abc = qux` não gera o cookie `"foo":"bar, admin = qux"` mas os cookies `foo":"bar"` e `"admin":"qux"`. Note como 2 cookies são gerados e como o admin teve o espaço removido antes e depois do sinal de igual.
* Verifique a opção "**lembrar-me**" se 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 após você mudar a senha.
Se o cookie permanecer o mesmo (ou quase) quando você faz 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:
* Tentar criar muitas **contas** com nomes de usuário muito **semelhantes** e tentar **adivinhar** como o algoritmo está funcionando.
* Tentar **forçar o nome de usuário**. Se o cookie é salvo apenas como um método de autenticação para o seu nome de usuário, então você pode criar uma conta com o nome de usuário "**Bmin**" e **forçar** cada único **bit** do seu cookie porque um dos cookies que você tentará será o pertencente a "**admin**".
* Tente **Padding****Oracle** (você pode descriptografar o conteúdo do cookie). Use **padbuster**.
Padbuster fará várias tentativas e perguntará qual condição é a condição de erro (a que não é válida).
Em seguida, começará a descriptografar o cookie (pode levar vários minutos)
Se o ataque for realizado com sucesso, você poderá tentar criptografar uma string de sua escolha. Por exemplo, se você quiser **encrypt****user=administrator**
Esta execução lhe dará o cookie corretamente criptografado e codificado com a string **user=administrator** dentro.
**CBC-MAC**
Talvez um cookie possa ter algum valor e pode ser assinado usando CBC. Então, a integridade do valor é a assinatura criada usando CBC com o mesmo valor. Como é recomendado usar como IV um vetor nulo, esse tipo de verificação de integridade pode ser vulnerável.
**O ataque**
1. Obtenha a assinatura do nome de usuário **administ** = **t**
2. Obtenha a assinatura do nome de usuário **rator\x00\x00\x00 XOR t** = **t'**
3. Defina 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 deve ser sempre o mesmo.
**Como detectar e atacar:**
Crie 2 usuários com dados quase idênticos (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 o ECB criptografa com a mesma chave 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). Assim, sabendo como um monte de "a" é criptografado, você pode criar um nome de usuário: "a"\*(tamanho do bloco)+"admin". Então, você poderia deletar o padrão criptografado de um bloco de "a" do cookie. E você terá o cookie do nome de usuário "admin".
Aprenda e pratique Hacking AWS:<imgsrc="../../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../../.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="../../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
