Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — CESPE / CEBRASPE 2025
Segurança da Informação›Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.)
Código
ce418186
Banca
CESPE / CEBRASPE
Órgão
STM
Ano
2025
Cargo
AJ ( )
Julgue o seguinte item, relativos a CSRF (cross-site request forgery), testes de invasão e segurança de aplicativos web.
Aplicações web que não implementam corretamente mecanismos de controle de sessão, como expiração de tokens e invalidação de sessões inativas, tornam-se vulneráveis a sequestro de sessão (session hijacking), mesmo que utilizem HTTPS.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Sequestro de sessão (session hijacking) e HTTPS
✅ CERTO. A afirmação está correta: o uso de HTTPS protege o tráfego em trânsito, mas não elimina a vulnerabilidade ao sequestro de sessão quando há falhas no gerenciamento da sessão, como ausência de expiração de tokens e de invalidação de sessões inativas. O HTTPS garante a confidencialidade e a integridade dos dados transmitidos, mas a segurança da sessão depende de controles no lado do servidor e do navegador, como o gerenciamento adequado de cookies e tokens.
O sequestro de sessão (session hijacking) é um ataque em que o invasor obtém o identificador de sessão (session ID) de um usuário autenticado e o utiliza para assumir a sessão, realizando ações em nome da vítima. Esse identificador pode ser obtido por diversos meios, como interceptação de tráfego (mitigada pelo HTTPS), ataques de XSS, engenharia social ou, como no caso da questão, pela exploração de falhas no controle de sessão.
O HTTPS, ao criptografar a comunicação, protege o session ID durante a transmissão, impedindo que seja capturado por um atacante que esteja monitorando a rede. No entanto, o HTTPS não protege o session ID em outras situações, como quando ele é armazenado de forma insegura no navegador, quando é exposto por meio de vulnerabilidades na aplicação (ex.: XSS) ou quando a sessão não possui mecanismos de expiração e invalidação adequados.
A ausência de expiração de tokens e de invalidação de sessões inativas significa que um session ID válido pode ser utilizado por um período prolongado, mesmo que o usuário não esteja mais ativo. Isso aumenta a janela de oportunidade para um atacante que tenha obtido o session ID, pois ele pode utilizá-lo para acessar a aplicação como se fosse o usuário legítimo. O HTTPS não mitiga essa vulnerabilidade, pois o atacante não precisa interceptar o tráfego; ele já possui o session ID e pode utilizá-lo diretamente.
Portanto, a afirmação está correta ao destacar que aplicações web com controle de sessão inadequado são vulneráveis ao sequestro de sessão, mesmo utilizando HTTPS. O HTTPS é uma camada de proteção importante, mas não é suficiente para garantir a segurança da sessão.
Sequestro de sessão (session hijacking)
1Como o atacante obtém o session ID
Interceptação de tráfego (mitigada pelo HTTPS)
XSS
Engenharia social
Falhas no controle de sessão
2O que o HTTPS protege
Confidencialidade e integridade do tráfego
Session ID durante a transmissão
3O que o HTTPS NÃO protege
Armazenamento inseguro no navegador
Exposição por vulnerabilidades (XSS)
Ausência de expiração/invalidação da sessão
LEVEL · soulevel.com.br
NÃO CAIA NESSA!
A banca explora a falsa sensação de segurança que o HTTPS transmite. O candidato pode pensar que, com a criptografia, o session ID está protegido e, portanto, o sequestro de sessão não seria possível. No entanto, o HTTPS protege apenas o tráfego em trânsito, não a sessão em si. O sequestro de sessão pode ocorrer por outras vias, como a exploração de vulnerabilidades na aplicação ou a falta de controles de expiração e invalidação.
PEGA ESSA DICA!
Para resolver questões sobre segurança de aplicações web, lembre-se de que o HTTPS é uma medida de proteção do canal de comunicação, mas não substitui os controles de segurança da aplicação. O gerenciamento adequado de sessão, com expiração de tokens, invalidação de sessões inativas e uso de tokens anti-CSRF, é fundamental para prevenir ataques como o sequestro de sessão e o CSRF.