A autenticação é o portão da aplicação — e quando o portão é fraco, tudo atrás dele fica exposto. As falhas de identificação e autenticação (categoria própria no OWASP Top 10) englobam tudo que dá errado no controle de quem você é e na manutenção dessa identidade ao longo da sessão. Esta aula reúne as falhas de login, de gestão de sessão e dos tokens modernos (JWT), conectando muito do que você já viu — os ataques de senha do Bloco VII, as sessões da aula Arquitetura web e HTTP: entendendo o terreno — no contexto de aplicações web. Pratique no Juice Shop e nos labs do PortSwigger.

As falhas no processo de login

Comece pelas falhas no processo de login. Muitas se conectam diretamente ao Bloco VII: permitir senhas fracas (sem política de complexidade), não mitigar força bruta (sem rate limiting ou lockout — o Hydra da aula Brute force online com Hydra: atacando serviços vivos contra o login), e ser vulnerável a credential stuffing (usar credenciais vazadas de outros serviços, explorando a reutilização de senhas). Some-se a enumeração de usuários: quando a aplicação responde de forma diferente para "usuário não existe" vs. "senha incorreta", ela vaza quais contas existem (a mesma lógica do VRFY no SMTP, aula Enumeração SMTP, POP3 e IMAP: minerando os serviços de e-mail) — dando ao atacante metade da credencial. E a ausência de MFA, que deixa a senha como ponto único de falha. Essas falhas transformam o login numa porta arrombável, e reforçam por que as defesas de senha do Bloco VII (MFA, rate limiting, senhas fortes) são tão centrais.

A gestão de sessão e suas falhas sutis

Em seguida, a gestão de sessão, que é onde muitas falhas sutis vivem. Lembre da aula Arquitetura web e HTTP: entendendo o terreno: após o login, sua identidade é mantida pelo cookie de sessão. As falhas aqui incluem: identificadores de sessão previsíveis (se o token de sessão é adivinhável ou sequencial, o atacante forja o de outro usuário); session fixation (o atacante força a vítima a usar um identificador de sessão que ele conhece, e após o login da vítima, usa esse mesmo identificador para entrar); sessões que não expiram adequadamente (um token roubado vale para sempre); logout que não invalida a sessão de fato no servidor (o token continua válido após o "sair"); e a transmissão insegura do cookie (sem HTTPS, capturável por sniffing — Bloco IV). O sequestro de sessão — obter o cookie de outro usuário, por XSS (aula Cross-Site Scripting (XSS): injetando no navegador da vítima), por sniffing, ou por previsibilidade — é a exploração central dessas falhas, e permite assumir a identidade da vítima sem jamais conhecer sua senha.

O que é um JWT

Agora os JWT (JSON Web Tokens), onipresentes em aplicações e APIs modernas, e que merecem atenção própria. Um JWT é um token que a aplicação entrega ao usuário autenticado e que carrega, dentro de si, informação sobre a identidade e permissões do usuário — de forma stateless (o servidor não precisa guardar a sessão; toda a informação está no token, protegida por uma assinatura). O JWT tem três partes: um cabeçalho (que indica o algoritmo de assinatura), um payload (os dados: quem é o usuário, seu papel, validade) e uma assinatura (que garante a integridade — que o token não foi adulterado). A segurança do JWT repousa inteiramente sobre essa assinatura, e é aí que moram as falhas.

O algoritmo none e a chave fraca

As falhas clássicas de JWT ilustram como criptografia mal aplicada (Bloco IV) quebra a autenticação. A mais notória é o algoritmo "none": alguns JWTs mal implementados aceitam um token cujo cabeçalho declara o algoritmo de assinatura como "none" — ou seja, sem assinatura. Um atacante pega um token válido, altera o payload (muda seu papel de "usuário" para "admin"), define o algoritmo como "none", remove a assinatura, e a aplicação vulnerável aceita — porque foi instruída a não verificar. Outra falha é a chave de assinatura fraca: se o JWT é assinado com uma chave secreta fraca, o atacante pode crackeá-la offline (aula Cracking offline com John e Hashcat: quebrando hashes em escala) e então forjar tokens válidos com qualquer conteúdo. Há também confusões de algoritmo (fazer a aplicação verificar um token com o algoritmo errado). O tema comum: se a verificação da assinatura pode ser burlada ou a chave descoberta, o atacante forja sua própria identidade e permissões — quebrando a autenticação e frequentemente a autorização de uma vez.

As falhas atacam os três A's

O ponto conceitual: essas falhas atacam os três A's (aula A tríade CIA e o modelo AAA: o vocabulário da defesa) no coração. Falhas de login e sessão atacam a autenticação (provar quem você é); a manipulação de JWT frequentemente ataca a autorização (o token diz o que você pode fazer, e forjá-lo eleva privilégios); e a fragilidade da sessão atacam a integridade da identidade. Quebrar o controle de identidade é particularmente grave porque ele é a base sobre a qual toda a segurança da aplicação se apoia — se o atacante pode se passar por outro usuário ou por um administrador, as demais defesas se tornam irrelevantes.

MFA, sessão robusta e JWT bem validado

Do lado defensivo, as contramedidas reúnem lições de todo o curso. Para login: senhas fortes, rate limiting/lockout, MFA (a defesa mais impactante), respostas genéricas que não vazam existência de usuário, proteção contra credential stuffing. Para sessões: identificadores longos e aleatórios (imprevisíveis), regeneração do identificador após o login (contra fixation), expiração adequada, invalidação real no logout, cookies com HttpOnly (contra XSS) e Secure/SameSite. Para JWT: nunca aceitar o algoritmo "none", usar chaves de assinatura fortes, validar rigorosamente o algoritmo esperado, e definir expiração curta. A lição unificadora: o controle de identidade é o alicerce da segurança da aplicação, e deve ser tratado com o máximo rigor — porque, comprometido ele, todo o resto cai.

Fontes e leituras recomendadas

Exercícios

  1. Como a "enumeração de usuários" no login vaza informação, e a que ataque já visto ela se assemelha?

    ✓ Resposta:

    Quando a aplicação responde diferente para "usuário inexistente" vs. "senha incorreta", ela revela quais contas existem, entregando metade da credencial ao atacante. Assemelha-se à enumeração via VRFY no SMTP (aula Enumeração SMTP, POP3 e IMAP: minerando os serviços de e-mail), que também distingue usuários válidos de inválidos pela resposta.

  2. Explique o session fixation e o sequestro de sessão, e por que ambos permitem assumir a identidade da vítima sem a senha.

    ✓ Resposta:

    No session fixation, o atacante força a vítima a usar um identificador de sessão que ele conhece; após o login da vítima, ele usa esse mesmo identificador para entrar. No sequestro de sessão, o atacante obtém o cookie de sessão da vítima (por XSS, sniffing ou previsibilidade). Ambos permitem assumir a identidade porque o cookie/identificador de sessão é a prova de identidade — de posse dele, não é preciso a senha.

  3. O que é um JWT, quais suas três partes, e sobre o que repousa sua segurança?

    ✓ Resposta:

    Um JWT é um token stateless entregue ao usuário autenticado, que carrega sua identidade e permissões. Suas três partes são: cabeçalho (algoritmo de assinatura), payload (dados: usuário, papel, validade) e assinatura (garante a integridade). Sua segurança repousa inteiramente sobre a assinatura, que impede a adulteração do payload.

  4. Descreva a falha do algoritmo "none" em JWT e como um atacante a explora para se tornar admin.

    ✓ Resposta:

    Na falha do "none", a aplicação aceita um token cujo cabeçalho declara o algoritmo como "none" (sem assinatura). O atacante pega um token válido, altera o payload (muda seu papel para "admin"), define o algoritmo como "none" e remove a assinatura; a aplicação vulnerável aceita porque foi instruída a não verificar, elevando o atacante a administrador.

  5. Como as falhas desta aula atacam os "três A's", e por que comprometer o controle de identidade torna as demais defesas irrelevantes?

    ✓ Resposta:

    Falhas de login e sessão atacam a autenticação (provar quem se é); a manipulação de JWT frequentemente ataca a autorização (forjar o papel/permissões); a fragilidade da sessão ataca a integridade da identidade. Comprometer o controle de identidade torna as demais defesas irrelevantes porque, podendo se passar por outro usuário ou por um admin, o atacante contorna toda a segurança que depende de saber quem ele é.