<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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)!
* 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).
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 de forma mais passiva:
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.**
Os hosts para receber 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 em que 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`.
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.
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 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 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 poderia ser Bypassed 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** de JS. No entanto, alguns bypasses para isso foram encontrados em software específico, como enviar `\r\nTRACE` em vez de `TRACE` para IE6.0 SP2.
É 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 de aplicativos. Assim, empregar o prefixo `__Host-` para todos os cookies de aplicativos pode ser considerado uma boa prática para melhorar a segurança e a isolamento.
Portanto, uma das proteções dos cookies prefixados com `__Host-` é impedir que sejam sobrescritos por 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) ([**artigo**](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 analisador, por exemplo, adicionando "=" no início ou no início e no final...:
Ou no PHP foi possível adicionar **outros caracteres no início** do nome do cookie que seriam **substituídos por caracteres de sublinhado**, permitindo a sobrescrita de cookies `__HOST-`:
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.
Esse ataque envolve roubar o cookie de um usuário para obter acesso não autorizado à sua conta em um aplicativo. Ao usar o cookie roubado, um atacante pode se passar pelo usuário legítimo.
Neste cenário, um atacante engana uma 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.
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.
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.
(Consulte mais detalhes na [pesquisa original](https://blog.ankursundara.com/cookie-bugs/)) Os navegadores permitem a criação de cookies sem nome, o que pode ser demonstrado por meio de JavaScript da seguinte forma:
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:
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:
(Verifique mais detalhes na [pesquisa original](https://blog.ankursundara.com/cookie-bugs/)) Vários servidores web, incluindo aqueles de Java (Jetty, TomCat, Undertow) e Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), lidam incorretamente com strings de cookies devido ao suporte desatualizado ao RFC2965. Eles leem 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:
(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:
Essa vulnerabilidade é particularmente perigosa em aplicações web que dependem de proteção CSRF baseada em cookies, pois permite que os 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.
- Verifique a opção de "**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.
Se o cookie permanecer o mesmo (ou quase) quando você fizer login, isso provavelmente significa que o cookie está relacionado a algum campo de sua conta (provavelmente o nome de usuário). Então você pode:
- Tente **bruteforce no nome de usuário**. 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**.
Se o ataque for realizado com sucesso, então 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 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".
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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)!
* Obtenha 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 nos siga 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).
