# Hacking de Cookies
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * 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) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
**Try Hard Security Group**
{% embed url="https://discord.gg/tryhardsecurity" %} *** ## Atributos de Cookies Os cookies vêm com vários atributos que controlam seu comportamento no navegador do usuário. Aqui está uma visão geral desses atributos em uma voz mais passiva: ### Expira 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.** ### Domínio Os hosts que recebem um cookie são especificados pelo atributo `Domain`. Por padrão, isso é definido como o host que emitiu o cookie, sem incluir seus subdomínios. No entanto, quando o atributo `Domain` é definido explicitamente, ele abrange também os subdomínios. 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`. ### Caminho 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. ### Regras de Ordenação 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 mais recentemente definido 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 conforme o esperado em diferentes cenários. | **Tipo de Solicitação** | **Código de Exemplo** | **Cookies Enviados Quando** | | ---------------- | ---------------------------------- | --------------------- | | Link | \\ | NotSet\*, Lax, None | | Pré-renderização | \ | 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 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 evita que o **cliente** acesse o cookie (via **Javascript** por exemplo: `document.cookie`) #### **Burlas** * 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 (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 poderia ser Burlado com solicitações **HTTP TRACE** como a resposta do servidor (se este 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, algumas formas de burlar isso foram encontradas em software específico, como enviar `\r\nTRACE` em vez de `TRACE` para o IE6.0 SP2. * Outra maneira é a exploração de vulnerabilidades zero/day 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 um ataque de [**Cookie Smuggling**](./#cookie-smuggling) para extrair esses cookies ### Seguro A solicitação enviará o cookie **apenas** em uma solicitação HTTP se a solicitação for transmitida por um canal seguro (tipicamente **HTTPS**). ## Prefixos de Cookies Cookies prefixados com `__Secure-` devem ser definidos juntamente com a flag `secure` em páginas que são protegidas por HTTPS. Para cookies prefixados com `__Host-`, várias condições devem ser atendidas: * Eles devem ser definidos com a flag `secure`. * Eles devem originar de uma página protegida por HTTPS. * É proibido especificar um domínio para eles, impedindo sua transmissão para subdomínios. * O caminho para esses cookies deve ser definido como `/`. É importante observar que cookies prefixados com `__Host-` não podem ser enviados para superdomínios ou subdomínios. Essa restrição ajuda a isolar os cookies da aplicação. Assim, empregar o prefixo `__Host-` para todos os cookies da aplicação pode ser considerado uma boa prática para melhorar a segurança e a isolamento. ## Ataques de Cookies Se um cookie personalizado contiver dados sensíveis, verifique-o (especialmente se estiver participando de um CTF), pois ele pode ser vulnerável. ### Decodificação e Manipulação de Cookies Dados sensíveis incorporados em cookies devem sempre ser examinados. Cookies codificados em Base64 ou formatos semelhantes muitas vezes podem ser decodificados. Essa vulnerabilidade permite que os atacantes alterem o conteúdo do cookie e se façam passar por outros usuários codificando seus dados modificados de volta no cookie. ### Sequestro de Sessão Esse ataque envolve roubar o cookie de um usuário para obter acesso não autorizado à sua conta dentro de um aplicativo. Ao usar o cookie roubado, um atacante pode se passar pelo usuário legítimo. ### Fixação de Sessão Neste cenário, um atacante engana a vítima para usar um cookie específico para fazer login. Se o aplicativo 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 %} ### Doação de Sessão Aqui, o atacante convence a vítima a usar o cookie de sessão do atacante. A vítima, acreditando estar logada em sua própria conta, inadvertidamente realizará ações no contexto 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 %} ### [Cookies JWT](../hacking-jwt-json-web-tokens.md) 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 obter informações detalhadas sobre possíveis falhas e como explorá-las, é recomendado acessar o documento vinculado sobre hacking JWT. ### Falsificação de Solicitação entre Sites (CSRF) Esse ataque força um usuário logado a executar ações indesejadas em um aplicativo da web no qual ele está autenticado no momento. Os atacantes podem explorar cookies que são enviados automaticamente com cada solicitação ao site vulnerável. ### Cookies Vazios (Verifique mais detalhes na [pesquisa original](https://blog.ankursundara.com/cookie-bugs/)) Navegadores permitem a criação de cookies sem um nome, o que pode ser demonstrado por meio de 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 do cookie enviado é `a=v1; valor de teste; b=v2;`. Curiosamente, 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 todos os servidores da web como um cookie chamado `a` com um valor `b`. #### Bug no Chrome: Problema com Ponto de Código de Substituto Unicode No Chrome, se um ponto de código de substituto Unicode fizer parte de um cookie definido, `document.cookie` fica corrompido, retornando subsequentemente uma string vazia: ```js document.cookie = "\ud800=meep"; ``` Isso resulta em `document.cookie` produzindo uma string vazia, indicando corrupção permanente. #### Contrabando de Cookies Devido a Problemas de Análise (Verifique 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 interpretam um valor de cookie entre aspas duplas como um único valor, mesmo que inclua ponto e vírgula, que normalmente deveria separar pares chave-valor: ``` RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; ``` #### Vulnerabilidades de Injeção de Cookies (Consulte mais detalhes na [pesquisa original](https://blog.ankursundara.com/cookie-bugs/)) A análise incorreta de cookies por servidores, especialmente 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 ponto e vírgula. - Zope procura por uma vírgula para iniciar a análise do próximo cookie. - As classes de cookies do Python começam a análise 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 bypass de autorização quando cookies são enviados para servidores back-end suscetíveis a falsificação. ### 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 usernames quase iguais e verifique se consegue ver semelhanças. - Verifique a opção de "**lembrar-me**", se existir, para ver como funciona. Se existir e for vulnerável, sempre use o cookie de **lembrar-me** sem nenhum outro cookie. - Verifique se o cookie anterior funciona mesmo depois de alterar a senha. #### **Ataques avançados de cookies** Se o cookie permanecer o mesmo (ou quase) ao fazer 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 usernames muito **semelhantes** e tente **adivinhar** como o algoritmo está funcionando. - Tente **bruteforce no username**. Se o cookie salvar apenas como um método de autenticação para seu nome de usuário, então você pode criar uma conta com o nome de usuário "**Bmin**" e **bruteforce** cada **bit** do seu cookie porque um dos cookies que você tentará será o pertencente ao "**admin**". - Tente **Padding Oracle** (você pode descriptografar o conteúdo do cookie). Use **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 ``` Padbuster fará várias tentativas e perguntará qual condição é 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 realizado com sucesso, então você poderia tentar criptografar uma string de sua escolha. Por exemplo, se você quisesse **criptografar** **user=administrador**. ``` padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext 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 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, 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 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). Assim, 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/) * [https://www.linkedin.com/posts/rickey-martin-24533653\_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](https://www.linkedin.com/posts/rickey-martin-24533653\_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd) **Try Hard Security Group**
{% embed url="https://discord.gg/tryhardsecurity" %}
Aprenda hacking AWS 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**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * 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) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).