Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — FCC 2026

Sequestro de Sessão (Session Hijacking): detecção por anomalias de ambiente

Gabarito: letra D. O cenário descreve um sequestro de sessão (session hijacking), em que o atacante rouba o cookie de sessão válido e o reutiliza para se passar pelo usuário legítimo — sem precisar de senha ou do segundo fator. A medida mais adequada para detectar esse tipo de ataque é comparar o contexto da sessão atual (IP, User-Agent) com o contexto registrado no servidor e invalidar a sessão diante de mudanças significativas, exatamente o que a alternativa D propõe. As demais alternativas tratam de prevenção (A, B, E) ou de outros ataques (C), não de detecção do sequestro já ocorrido.

O sequestro de sessão é um ataque em que o invasor obtém o identificador de sessão (geralmente o cookie) de um usuário autenticado e o utiliza para assumir aquela sessão. O atacante não precisa conhecer a senha nem o segundo fator, pois o servidor já validou a autenticação — ele apenas "reapresenta" a credencial de sessão roubada. A detecção desse tipo de abuso exige que o servidor verifique se a sessão está sendo usada pelo mesmo contexto que a criou. Parâmetros como endereço IP e User-Agent (navegador/sistema operacional) são indicadores razoáveis de identidade do cliente: se uma sessão criada em um IP e com um navegador específico passa a ser usada de outro IP e com outro navegador, há forte indício de sequestro. Por isso, a prática recomendada é armazenar esses dados no servidor e invalidar a sessão quando houver divergência significativa.

É importante distinguir detecção de prevenção. As alternativas A, B e E descrevem medidas preventivas: regenerar o cookie após autenticação e mudança de privilégio (A) reduz a janela de reuso de IDs antigos; usar Secure + HTTPS (B) protege o cookie em trânsito contra interceptação; e HttpOnly (E) impede que scripts (XSS) leiam o cookie. Nenhuma delas detecta o sequestro depois que o cookie já foi roubado por malware — o atacante simplesmente usa o cookie legítimo, e essas medidas não geram alerta. A alternativa C trata de CSRF, um ataque diferente, que explora a confiança do site no navegador para forçar ações, e não o roubo do cookie.

A pegadinha central desta questão é o verbo "detectar". O enunciado pergunta qual medida é adequada para detectar o ataque, não para prevenir. O candidato que lê rápido tende a escolher uma medida preventiva (como Secure/HTTPS ou HttpOnly), mas a pergunta é sobre identificação do abuso já em andamento. A detecção por anomalia de contexto (IP/User-Agent) é a única que cumpre esse papel.

Guarde a fronteira entre prevenção (impedir que o cookie seja roubado ou reutilizado) e detecção (perceber que o cookie roubado está sendo usado): é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

A regeneração de sessão (session regeneration) é uma medida preventiva que troca o ID da sessão após eventos críticos (autenticação, mudança de privilégio), dificultando a fixação de sessão (session fixation) e reduzindo a janela de reuso de IDs antigos. Porém, no cenário descrito, o cookie já foi roubado após a autenticação — o atacante usa o cookie atual e válido. A regeneração não detecta o uso indevido; ela apenas limita o tempo de validade de um ID específico. Não é a medida de detecção pedida.

Alternativa B — ❌ Incorreta

O atributo Secure e o uso obrigatório de HTTPS são medidas preventivas que protegem o cookie contra interceptação durante o trânsito (sniffing). No cenário, o cookie foi extraído por um malware já instalado no computador do funcionário — não houve interceptação de rede. Portanto, Secure/HTTPS não impediriam o roubo nem detectariam o uso indevido do cookie. A criptografia protege o canal, não o endpoint comprometido.

Alternativa C — ❌ Incorreta

Tokens anti-CSRF e o header SameSite são defesas contra CSRF (Cross-Site Request Forgery), ataque que força o navegador da vítima a enviar requisições indesejadas a um site em que ela está autenticada, explorando a confiança do site no navegador. O cenário da questão é sequestro de sessão (roubo do cookie), não CSRF. O atacante não está forçando requisições pelo navegador da vítima; ele está usando o cookie roubado diretamente. Portanto, essa alternativa trata de um ataque diferente e não detecta o sequestro.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta é a medida de detecção adequada. Ao registrar no servidor o contexto da sessão (IP, User-Agent) e invalidar a sessão quando houver mudança significativa, o sistema identifica que a sessão está sendo usada de um ambiente diferente do original — forte indício de sequestro. Essa técnica é conhecida como detecção de anomalia de sessão e é uma das formas de mitigar o session hijacking. Ela não impede o roubo, mas detecta o uso indevido e encerra a sessão, limitando o dano.

Alternativa E — ❌ Incorreta

O atributo HttpOnly impede que scripts do lado do cliente (XSS) acessem o cookie via DOM, sendo uma medida preventiva contra roubo de cookie por XSS. No cenário, o cookie foi extraído por um malware no computador — não por um script XSS no navegador. O HttpOnly não impede o malware de ler o cookie (o malware opera fora do navegador, no sistema) nem detecta o uso indevido. Portanto, não é a medida de detecção pedida.

Gabarito: letra D — a detecção de sequestro de sessão se faz pela comparação do contexto de uso (IP/User-Agent) com o contexto registrado, invalidando a sessão em caso de divergência significativa.