Session Hijacking e Controle de Sessão
Gabarito: Certo (C). A afirmação está correta: mesmo com HTTPS, se a aplicação não gerencia adequadamente a expiração e invalidação de tokens de sessão, ela permanece vulnerável a sequestro de sessão (session hijacking). HTTPS protege apenas o canal contra interceptação, mas não impede que um token roubado por outras vias (XSS, engenharia social, vazamento no cliente) seja reutilizado enquanto for válido.
O que a banca testa
A questão cobra a diferença entre segurança de transporte (HTTPS) e segurança da lógica de sessão. É uma armadilha clássica: o aluno pode achar que HTTPS resolve todos os problemas de sessão, mas a realidade é que a proteção deve ser em camadas. O controle de sessão inclui expiração de tokens, invalidação no logout e após inatividade, e renovação de tokens sensíveis.
Análise detalhada
HTTPS impede que um atacante capture o token durante a transmissão (ataque man-in-the-middle). No entanto, o token pode ser obtido por outros meios:
Cross-site scripting (XSS): código malicioso injetado na página lê o cookie de sessão.
Session fixation: o atacante força o usuário a usar um token conhecido.
Vazamento no cliente: token armazenado em local inseguro (ex.: localStorage sem proteção).
Se a sessão não expira nem invalida, o token roubado permite acesso persistente. Por isso, mesmo com HTTPS, é indispensável implementar:
Tempo de expiração (curto para sessões sensíveis).
Invalidação no logout e após inatividade.
Rotação de tokens (regenerar token em ações críticas).
A afirmação do enunciado reflete exatamente essa necessidade. Portanto, está Certa.
MNEMÔNICOCID
CConfidencialidade (dados acessíveis só a quem é autorizado)IIntegridade (dados exatos, consistentes e não alterados indevidamente)DDisponibilidade (informação/sistemas acessíveis quando necessário)
✅ CERTO