# Hacking de Cookies
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique 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 Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo 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).
Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. [**Experimente gratuitamente**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoje. {% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %} *** ## 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 **os subdomínios são sempre incluídos**. Portanto, especificar `Domain` é menos restritivo do que omiti-lo. No entanto, pode ser útil quando os 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 na URL solicitada para enviar o cabeçalho `Cookie`**. O caractere `%x2F` ("/") é considerado um separador de diretório, e subdiretórios também são correspondidos. #### Ordem Quando 2 cookies têm o **mesmo nome**, aquele que é enviado é: * Aquele com o **caminho mais longo** que corresponde ao caminho da 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**. Ele tem 3 valores possíveis: * **Strict**: 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. * **None**: O cookie é enviado de qualquer domínio de terceiros | **Tipo de Solicitação** | **Exemplo de Código** | **Cookies Enviados Quando** | | ---------------------- | ---------------------------------- | --------------------------- | | Link | \\ | NotSet\*, Lax, None | | Prerender | \ | NotSet\*, Lax, None | | Formulário GET | \
| NotSet\*, Lax, None | | Formulário POST | \ | NotSet\*, None | | iframe | \ | NotSet\*, None | | AJAX | $.get("...") | NotSet\*, None | | Imagem | \ | NetSet\*, None | 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 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 alteração, 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 entre sites de alto nível**. ## Flags de Cookies ### HttpOnly Isso impede 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 essa 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 burlado com solicitações **TRACE** **HTTP** como resposta do servidor (se esse método HTTP estiver disponível), os cookies enviados serão refletidos. Essa técnica é chamada de **Cross-Site Tracking**. * Essa técnica é evitada por **navegadores modernos que não permitem o envio de uma solicitação TRACE** a partir do JS. No entanto, foram encontradas algumas formas de burlar isso em software específico, como enviar `\r\nTRACE` em vez de `TRACE` para o IE6.0 SP2. * Outra forma é a exploração de vulnerabilidades zero/dia dos navegadores. * É possível **sobrescrever cookies HttpOnly** realizando um ataque de overflow do 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 extrair esses cookies ### Secure A solicitação enviará o cookie **apenas** em uma solicitação HTTP se a solicitação for transmitida por um canal seguro (geralmente **HTTPS**). ## Prefixos de Cookies Prefixo **`__Secure-`**: deve ser definido com a flag `secure` de uma página segura (HTTPS). Prefixo **`__Host-`**: deve ser definido com a flag `secure`, deve ser de uma página segura (HTTPS), não deve ter um domínio especificado (e, portanto, não é enviado para subdomínios) e o caminho deve ser `/`. Cookies com prefixo `__Host-` não podem ser enviados para superdomínios (cookies de subdomínios para domínios) ou subdomínios (cookies de domínios para subdomínios), então, se você deseja isolar os cookies de sua aplicação, prefixar tudo com `__Host-` não é uma má ideia. ## Ataques a Cookies Se você encontrar algum tipo de cookie personalizado contendo dados sensíveis (sessionID, nome de usuário, e-mails, etc.), definitivamente deve tentar explorá-lo. ### Decodificando o cookie Se o **cookie** estiver usando alguma **codificação base** (como Base64) ou similar, você pode ser capaz de **decodificá-lo**, **alterar** o **conteúdo** e **se passar** por usuários arbitrários. ### Sequestro de sessão Roubar um cookie e usá-lo para se passar pelo usuário dentro de um aplicativo. ### Fixação de sessão O atacante obtém um cookie de uma página da web e envia um link para a vítima **fazer login usando o mesmo cookie**. Se o cookie não for alterado quando um usuário faz login, isso pode ser útil porque o atacante pode se passar pelo usuário por meio de um cookie. 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 %} ### Doação de sessão O atacante envia sua própria sessão para a vítima. A vítima verá que já está conectada e suporá que está dentro de sua conta, mas **as ações serão realizadas dentro da conta do 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 %} ### [Cookie JWT](../hacking-jwt-json-web-tokens.md) Clique no link anterior para acessar uma página explicando possíveis falhas no JWT. ### Cookie vazio Os navegadores permitem um cookie com um nome vazio. ```js document.cookie = "a=v1" document.cookie = "=test value;" // empty name document.cookie = "b=v2" ``` Isso resulta no cabeçalho do 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 sem nome vazio, resultará no **cabeçalho do cookie enviado:** ``` a=b; ``` Significado, todo servidor web irá interpretá-lo como o cookie `a` sendo definido com o valor `b`. ### Bug do Chrome - corrupção do document.cookie Se um ponto de código de substituto unicode estiver em um cookie definido, o `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 da 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 **interpretar incorretamente as strings de cookies** devido ao suporte remanescente para o RFC2965, um mecanismo de citação de cookies desatualizado que usa o RFC2616 para a definição de uma string entre aspas. Especificamente, **esses servidores continuam lendo uma string de cookie quando encontram um valor de cookie entre aspas duplas (dquoted), mesmo se um ponto e vírgula for encontrado**. Isso é problemático porque **pontos e vírgulas devem separar pares chave-valor** na string de cookie. Por exemplo, se um **navegador enviar três cookies, RENDER\_TEXT, JSESSIONID** e **ASDF:** ```basic RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; ``` Esses servidores interpretam esses valores 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 obtiver 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 http.cookie.SimpleCookie e http.cookie.BaseCookie da biblioteca padrão do Python, foram encontrados **analisando incorretamente os 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 **Python's SimpleCookie** e **BaseCookie** 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 para a **segurança**. Por exemplo, se um aplicativo da web usa **proteção CSRF baseada em cookies**, um invasor pode **injetar** um cookie falsificado de **CSRF-token** para contornar essa proteção. Além disso, o último cookie com o mesmo nome nos pacotes http.cookie do Python substitui os anteriores, tornando esse tipo de ataque especialmente fácil. Além disso, a **falsificação** dos 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 cookies 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 cookies vulneráveis #### **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 contém alguma informação 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 se a opção "**lembrar-me**" existe e veja como ela funciona. Se existir e puder ser vulnerável, sempre use o cookie de **lembrar-me** sem nenhum outro cookie. * Verifique se o cookie anterior continua funcionando mesmo depois de 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, então 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 pertencente ao "**admin**". * Tente o **Padding** **Oracle** (você pode descriptografar o conteúdo do cookie). Use o **padbuster**. **Padding Oracle - Exemplos do Padbuster** ```bash padbuster # 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 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. Nesse caso, a integridade do valor é a assinatura criada usando CBC com o mesmo valor. Como é recomendado usar um vetor IV 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 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 o ECB criptografa com a mesma chave em 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). Portanto, sabendo como um monte de "a" é criptografado, você pode criar um nome de usuário: "a"\*(tamanho do bloco)+"admin". Em seguida, 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/)
Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. [**Experimente gratuitamente**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) hoje. {% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Descubra [**The PEASS Family**](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 Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo 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 seus truques 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).