Cibersegurança e segurança da informação

Segurança de Sessão: Cookies, Tokens e Fixação de Sessão

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre testes de Segurança de Sessão na área de Web e API PT

Resposta rápida

O teste de Segurança de Sessão é realizado apenas em laboratório ou num sistema autorizado. São verificados o Request/Response, o comportamento do servidor, os Roles, o State e o Impacto, utilizando testes mínimos que não danificam os dados.

Os testes de segurança Web e API devem examinar os limites de confiança, permissões, entrada, estado e lógica de negócio. Cada teste neste artigo destina-se a um laboratório, CTF ou sistema para o qual foi concedida permissão explícita. Este artigo foca-se na Segurança de Sessão e destina-se a estudantes de Web PT. O objetivo é fornecer uma metodologia de trabalho que possa ser aplicada na prática, em entrevistas profissionais e em ambientes de trabalho, sem se limitar a uma definição de dicionário.

O principal desafio é que os dados são quase sempre parciais. Secure/HttpOnly/SameSite, rotação, expiração podem indicar uma direção, mas o seu significado depende do tempo, do recurso, do utilizador e da atividade esperada. Por isso, construiremos o teste em torno de uma questão de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático neste artigo é: Comparar a Sessão antes e depois do Login/Logout num laboratório. Todos os exemplos são dados de laboratório ou descrições de processos. No caso de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, Scope definido e capacidade de parar o teste.

Ciclo de Vida da Sessão

Na Segurança de Sessão, identidade e autorização são duas questões distintas: quem é o cliente e o que lhe é permitido fazer no recurso. São verificados Roles, Claims, Sessão, propriedade do Objeto e alterações ao longo do ciclo de vida, não se contentando com o facto de o utilizador estar 'conectado'.

Uma matriz de teste inclui um utilizador anónimo, um utilizador regular, um proprietário de objeto, outro utilizador e um administrador. Para cada ação, o Response e o impacto no lado do servidor são comparados. A alteração de um identificador ou Header é apenas um meio de teste; a evidência é que o servidor aprovou ou rejeitou uma ação contrariamente à política.

Rotação e Fixação

O tópico 'Rotação e Fixação' é uma parte central do trabalho em Segurança de Sessão. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se deseja tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de ferramentas sem compreender o propósito.

Na prática, registe Secure/HttpOnly/SameSite, rotação, expiração, revogação, fixação, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Timeout e Logout

O tópico 'Timeout e Logout' é uma parte central do trabalho em Segurança de Sessão. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se deseja tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de ferramentas sem compreender o propósito.

Tokens, Armazenamento e Reteste

Um teste profissional de Segurança de Sessão começa com condições de sucesso e falha. São definidos um Caso positivo, um Caso negativo, um Caso limite e uma atividade legítima similar. Isso permite identificar tanto Falsos Negativos quanto Falsos Positivos.

Num ambiente autorizado, utiliza-se a ação mínima que prova a afirmação sem causar danos. São guardados Input, Output, tempo e versão, e após a correção, realiza-se um Retest no mesmo cenário e verifica-se também a Regressão em funções adjacentes.

Focos de Teste Únicos

Neste tópico, é recomendável construir um mapa de evidências focado antecipadamente. Os principais focos de teste são: Secure/HttpOnly/SameSite, rotação, expiração, revogação, fixação, contexto CSRF. A lista não é uma Lista de Verificação automática; cada item é escolhido porque pode ligar uma entidade, uma ação e o tempo, ou explicar um comportamento legítimo.

Secure/HttpOnly/SameSite: Defina qual o valor esperado, o que será considerado uma anomalia e que outra fonte verificará a descoberta.
rotação: Defina qual o valor esperado, o que será considerado uma anomalia e que outra fonte verificará a descoberta.
expiração: Defina qual o valor esperado, o que será considerado uma anomalia e que outra fonte verificará a descoberta.
revogação: Defina qual o valor esperado, o que será considerado uma anomalia e que outra fonte verificará a descoberta.
fixação: Defina qual o valor esperado, o que será considerado uma anomalia e que outra fonte verificará a descoberta.
CSRF context: Defina qual o valor esperado, o que será considerado uma anomalia e que outra fonte verificará a descoberta.

Quando um dos focos não está disponível, a lacuna deve ser documentada e uma alternativa escolhida. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload for encriptado, usam-se Metadados, volume, frequência e contexto TLS/DNS.

Processo de Trabalho Recomendado

Defina um Scope e uma questão de trabalho sobre a Segurança de Sessão.
Registe as fontes de dados e as evidências necessárias: Secure/HttpOnly/SameSite, rotação, expiração, revogação.
Crie um Baseline curto de comportamento correto ou resultado esperado.
Realize o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
Construa uma Timeline ou tabela de comparação e separe o facto da interpretação.
Faça um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
Conclua uma decisão, limitações, ação recomendada e critério de Reteste.

Cenário Prático

O cenário escolhido é a comparação da Sessão antes e depois do Login/Logout num laboratório. O objetivo do exercício não é provar a capacidade de ataque, mas praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, são definidos dados fictícios, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser apresentado um produto que outro analista ou testador possa rever: uma captura de ecrã ou exportação da evidência, uma Timeline curta, uma suposição inicial, evidência de confirmação, limitação e recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Etapa	O que fazer	Produto
Preparação	Defina Scope, tempo e objetivo. Registe quais campos ou evidências de Secure/HttpOnly/SameSite, rotação, expiração se espera que apareçam.	Plano de teste curto
Criação de Dados	Realize uma ação segura e fictícia relacionada com a Segurança de Sessão, sem informações reais ou impacto num sistema de produção.	Evento/Request/Flow controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o fuso horário, identificadores e integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual é a possível explicação legítima.	Conclusão provisória
Conclusão	Escolha um encerramento, escalada, Finding ou Tuning; adicione uma recomendação e Reteste.	Produto documentado

Lista de Verificação Prática

Verifique e documente: Role e sessão.
Verifique e documente: Endpoint e method.
Verifique e documente: Request/Response.
Verifique e documente: Object identifier.
Verifique e documente: Server-side effect.
Verifique e documente: Control expected e remediation.
Indique fuso horário, versão da ferramenta e hora de recolha.
Guarde os dados brutos antes da filtragem ou alteração.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina proprietário e próxima ação com prazo.

Erros Comuns

Verificar apenas o Status code.
Depender de alteração Client-side.
Usar Payload perigoso.
Não verificar diferentes Roles.
Ignorar a lógica de negócio.
Reportar sem Request/Response limpos.

Resumo e CTA

Segurança de Sessão: Cookies, Tokens e Fixação de Sessão é um tópico que conecta conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha contexto e tempo, e escolha uma ação que possa ser justificada e testada novamente.

No curso de Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. O próximo passo natural é consultar os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

É permitido testar a Segurança de Sessão num site público?

Não, sem autorização explícita do proprietário do sistema. Mesmo um teste que pareça simples pode alterar dados, ativar mecanismos de defesa ou ser considerado acesso não autorizado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não complete campos por suposição ou apresente 'Unknown' como correto.

Quanto tempo as evidências devem ser guardadas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir antecipadamente a Retenção, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem arriscar um sistema real?

Use máquinas virtuais, dados fictícios, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, as condições de Stop e faça um backup antes de iniciar o trabalho.