mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00

History

Translator e553394b9f Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu		2024-01-01 18:32:14 +00:00
..
cookie-bomb.md	Translated to Portuguese	2023-06-06 18:56:34 +00:00
cookie-jar-overflow.md	Translated to Portuguese	2023-06-06 18:56:34 +00:00
cookie-tossing.md	Translated to Portuguese	2023-06-06 18:56:34 +00:00
README.md	Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu	2024-01-01 18:32:14 +00:00

README.md

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!
Adquira o material oficial PEASS & HackTricks
Descubra A Família PEASS, nossa coleção de NFTs exclusivos
Junte-se ao grupo 💬 Discord ou ao grupo telegram ou siga me no Twitter 🐦 @carlospolopm.
Compartilhe suas técnicas de hacking enviando PRs para os repositórios do GitHub HackTricks e 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 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	<a href="..."></a>	NotSet*, Lax, None
Prerender	<link rel="prerender" href=".."/>	NotSet*, Lax, None
Form GET	<form method="GET" action="...">	NotSet*, Lax, None
Form POST	<form method="POST" action="...">	NotSet*, None
iframe	<iframe src="..."></iframe>	NotSet*, None
AJAX	$.get("...")	NotSet*, None
Image	<img src="...">	NetSet*, None

Tabela da Invicti 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/).
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/.
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 {% endcontent-ref %}

É possível usar o ataque de 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

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 {% 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 {% endcontent-ref %}

Clique no link anterior para acessar uma página explicando possíveis falhas em JWT.

Navegadores permitem um cookie com um nome vazio

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:

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.

Se um ponto de código substituto unicode estiver em um cookie definido, document.cookie será permanentemente corrompido e retornará uma string vazia.

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:

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.

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:

LANGUAGE="en-us" CSRF_TOKEN="SPOOFED_VALUE"

Zope começa a analisar o próximo cookie em uma vírgula:

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

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# 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

Obter a assinatura do nome de usuário administ = t
Obter a assinatura do nome de usuário rator\x00\x00\x00 XOR t = t'
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/