# Cookies Hacking
Aprenda AWS hacking do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras formas de apoiar o HackTricks: * Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos * **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga** me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.** * **Compartilhe suas técnicas de hacking enviando PRs para os repositórios do GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Encontre vulnerabilidades que importam mais para que você possa corrigi-las mais rápido. Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha tecnológica, de APIs a aplicativos web e sistemas em nuvem. [**Experimente grátis**](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 é deletado * `Max-age` define o tempo em segundos para quando um cookie será deletado **(use isso, não estamos mais em 2009)** ### **Domain** O atributo `Domain` especifica **quais hosts podem receber um cookie**. Se não especificado, o atributo **assume por padrão** o **mesmo host** que definiu o cookie, _**excluindo subdomínios**_. **Se `Domain` é** **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`, 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 atributo _domain_ de **`.example.com`**, ele será **enviado** em solicitações para o **domínio pai.** ### **Path** O atributo `Path` indica um **caminho 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**, o que é enviado é: * Aquele com o **caminho mais longo** correspondente ao caminho da URL * O **mais novo** 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: * **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** | **Código de Exemplo** | **Cookies Enviados Quando** | | ---------------- | ---------------------------------- | --------------------- | | Link | \\ | NotSet\*, Lax, None | | Prerender | \ | NotSet\*, Lax, None | | Form GET | \
| NotSet\*, Lax, None | | Form POST | \ | NotSet\*, None | | iframe | \ | NotSet\*, None | | AJAX | $.get("...") | NotSet\*, None | | Image | \ | NetSet\*, None | Tabela da [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) e ligeiramente modificada.\ Um cookie com 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ção POST cross-site de nível superior.** ## Bandeiras de Cookies ### HttpOnly Isso impede que o **cliente** acesse o cookie (Via **Javascript**, por exemplo: `document.cookie`) #### **Bypasses** * Se a página está **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 a esta página e **roubar os cookies** da resposta (confira 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 poderia ser contornado com solicitações **TRACE** **HTTP** já que a resposta do servidor (se este método HTTP estiver disponível) refletirá os cookies enviados. Esta técnica é chamada de **Cross-Site Tracking**. * Esta técnica é evitada por **navegadores modernos por não permitirem o envio de uma solicitação TRACE** a partir do JS. No entanto, alguns bypasses para isso foram encontrados em softwares específicos, como enviar `\r\nTRACE` em vez de `TRACE` para o IE6.0 SP2. * Outra forma é a exploração de vulnerabilidades zero/day dos navegadores. * É possível **sobrescrever cookies HttpOnly** realizando um ataque de estouro 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 **apenas** enviará o cookie em uma solicitação HTTP se a solicitação for transmitida por um canal seguro (tipicamente **HTTPS**). ## Prefixos de Cookies **`__Secure-` prefixo**: deve ser definido com a bandeira `secure` a partir de uma página segura (HTTPS). **`__Host-` prefixo**: deve ser definido com a bandeira `secure`, deve ser de uma página segura (HTTPS), não deve ter um domínio especificado (e, portanto, não são enviados 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ê quiser isolar os cookies da sua aplicação, prefixar tudo com `__Host-` não é uma má ideia. ## Ataques de Cookies Se você encontrar algum tipo de cookie personalizado contendo dados sensíveis (sessionID, nome de usuário, emails, etc.) você definitivamente deve tentar explorá-lo ### Decodificando o cookie Se o **cookie** estiver usando algum **Base encoding** (como Base64) ou similar, você pode ser capaz de **decodificá-lo**, **alterar** o **conteúdo** e **impersonar** usuários arbitrários. ### Session Hijacking Roubar um cookie e usá-lo para se passar pelo usuário dentro de uma aplicação ### Session fixation O atacante obtém um cookie de uma página web e envia um link para a vítima para **entrar usando exatamente o mesmo cookie**. Se o cookie não for alterado quando um usuário faz login, isso pode ser útil porque o atacante poderia ser capaz de se passar pelo usuário através de um cookie. Se você encontrou um **XSS em um subdomínio** ou você **controla um subdomínio**, leia: {% content-ref url="cookie-tossing.md" %} [cookie-tossing.md](cookie-tossing.md) {% endcontent-ref %} ### Session donation O atacante envia sua própria sessão para a vítima. A vítima verá que já está logada 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 você **controla um subdomínio**, leia: {% content-ref url="cookie-tossing.md" %} [cookie-tossing.md](cookie-tossing.md) {% endcontent-ref %} ### [JWT Cookie](../hacking-jwt-json-web-tokens.md) Clique no link anterior para acessar uma página explicando possíveis falhas em JWT. ### Cookie Vazio 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 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 de nome vazio, isso resultará no **cabeçalho do cookie enviado:** ``` a=b; ``` Significa que todo servidor web o interpretará como o cookie `a` sendo definido com o valor `b`. ### Bug do Chrome - corrupção de document.cookie Se um ponto de código 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 servidores Java como 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 strings de cookies** devido ao suporte remanescente para RFC2965, um mecanismo de cotação de cookies desatualizado que usa RFC2616 para uma definição de 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 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 **valor único de cookie** em vez de três cookies separados. Isso leva a um risco de segurança: se um atacante obtiver acesso a cross-site scripting (XSS), ele pode usar esse bug para **exfiltrar cookies sensíveis como cookies HttpOnly**. ### Injeção de Cookie Muitos servidores web, incluindo o Undertow do Java, o Zope do Python e aqueles que usam o http.cookie.SimpleCookie e o http.cookie.BaseCookie da stdlib do Python, foram encontrados **interpretando incorretamente os cookies, usando delimitadores errados para iniciar o próximo par nome/valor do cookie**. Isso permite que um atacante **simule múltiplos cookies enquanto controla apenas o valor de um cookie**. No caso do **Undertow**, ele começa a interpretar 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 **Python's SimpleCookie** e o **BaseCookie** começam imediatamente a analisar o próximo cookie em um caractere de **espaço**: ``` LANGUAGE=en-us CSRF_TOKEN=SPOOFED_VALUE ``` Como resultado, servidores como **cherrypy**, **web.py**, **aiohttp** server, **bottle** e **webob** (Pyramid, TurboGears) são todos vulneráveis a esse tipo de ataque. Essa questão apresenta significativas **implicações de segurança**. Por exemplo, se uma aplicação web usa **proteção CSRF baseada em cookie**, um atacante pode **injetar** um **cookie de token CSRF** falsificado para burlar essa proteção. Além disso, o último nome de cookie duplicado nos pacotes http.cookie do Python sobrescreve quaisquer anteriores, tornando esse tipo de ataque especialmente fácil. Além disso, o **spoofing** de cookies **`__Secure-`** e **`__Host-`** pode ser abusado em um contexto inseguro. Também, em uma configuração onde cookies são passados para um servidor backend, **injeção de cookie pode levar a bypasses de autorização** se o servidor backend for suscetível a spoofing, 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 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 de mim**" se ela existir para ver como funciona. Se existir e puder ser vulnerável, sempre use o cookie de **lembrar de mim** sem nenhum outro cookie. * Verifique se o cookie anterior funciona mesmo após você mudar a senha. #### **Ataques avançados com cookies** Se o cookie permanece 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 várias **contas** com nomes de usuário muito **semelhantes** e tentar **adivinhar** como o algoritmo está funcionando. * Tentar **força bruta no nome de usuário**. Se o cookie salva 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 a bruta** em cada **bit** do seu cookie porque um dos cookies que você tentar será o pertencente a "**admin**". * Tentar **Padding Oracle** (você pode descriptografar o conteúdo do cookie). Use **padbuster**. **Padding Oracle - Exemplos de 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 ``` 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 foi realizado com sucesso, então você poderia tentar criptografar uma string de sua escolha. Por exemplo, se você quisesse **criptografar** **user=administrator** ``` padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator ``` Esta 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 possa 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. 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 é 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, email, etc.) e tente descobrir algum padrão dentro do cookie dado Crie um usuário chamado, por exemplo, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" e verifique se há algum padrão no cookie (como 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). 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ê poderia deletar 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 importam mais para que você possa corrigi-las mais rápido. Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha tecnológica, de APIs a aplicativos 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" %}
Aprenda AWS hacking do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.** * **Compartilhe suas dicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).