* 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).
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.**
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.
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.**
* 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 `\
Se um ponto de código de substituto Unicode estiver em um cookie definido, `document.cookie` será permanentemente corrompido e retornará uma string vazia.
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.
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**.
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:
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.
* 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.
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**.
Se o ataque for bem-sucedido, você poderá tentar criptografar uma string de sua escolha. Por exemplo, se você quiser **criptografar****user=administrador**.
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.
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".
* 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).
