Questão de Segurança da Informação — Análise de Vulnerabilidade e Gestão de Riscos — FGV 2022
Segurança da Informação›Análise de Vulnerabilidade e Gestão de Riscos
Código
fg052394
Banca
FGV
Órgão
SEFAZ-AM
Ano
2022
Nível
Superior
Cargo
Analista de Tecnologia da Informação da Fazenda Estadual - Manhã
Em aplicações Web, a vulnerabilidade denominada CSRF (cross site request forgery) ocorre quando solicitações não autorizadas a um website são enviadas a partir de um equipamento onde existe uma sessão ativa em que o website confia.Uma forma de se proteger desse ataque é a(o)
Adesativação do recurso HSTS.
Buso de cabeçalho X-Csrf-Protection nas requisições GET.
Cuso do atributo httponly nos cookies utilizados.
Duso de tokens anti-csrf pela aplicação.
Egarantia que os cookies não serão enviados em texto claro na rede.
Revelar gabarito e comentário▾
GabaritoD — uso de tokens anti-csrf pela aplicação.
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”.
CSRF (Cross-Site Request Forgery) e Proteção
Gabarito: letra D. O ataque CSRF explora a confiança que um site tem no navegador do usuário, enviando requisições não autorizadas aproveitando uma sessão ativa. A principal defesa é o uso de tokens anti-CSRF, valores únicos e imprevisíveis que o servidor valida em cada requisição sensível.
As demais alternativas abordam medidas de segurança, mas não específicas para CSRF:
Alternativa A — ❌ Incorreta
HSTS (HTTP Strict Transport Security) força conexões HTTPS, prevenindo ataques de downgrade de protocolo, mas não impede CSRF. A vulnerabilidade CSRF independe do uso de criptografia no transporte.
Alternativa B — ❌ Incorreta
Não existe um cabeçalho padrão "X-Csrf-Protection" para requisições GET. A proteção CSRF geralmente envolve tokens enviados em campos ocultos de formulários ou cabeçalhos personalizados (ex.: X-CSRF-Token), e requisições GET não devem alterar estado — portanto essa alternativa confunde o mecanismo.
Alternativa C — ❌ Incorreta
O atributo HttpOnly impede que cookies sejam acessados por scripts do lado do cliente, protegendo contra XSS (Cross-Site Scripting), mas não contra CSRF. No CSRF, o navegador envia os cookies automaticamente com a requisição, mesmo que sejam HttpOnly.
Alternativa D — ✅ Correta ⟵ GABARITO
Tokens anti-CSRF são a defesa padrão: a aplicação gera um token único associado à sessão do usuário e o inclui em formulários ou cabeçalhos de requisições sensíveis. O servidor valida o token a cada requisição; sem ele, a requisição é rejeitada. Isso impede que um atacante crie requisições válidas sem conhecer o token.
Alternativa E — ❌ Incorreta
Garantir que cookies não sejam enviados em texto claro (usando HTTPS) protege a confidencialidade e integridade durante o transporte, mas o CSRF ocorre mesmo com HTTPS, pois o navegador envia os cookies automaticamente nas requisições legítimas. A criptografia não valida a intenção do usuário.
NÃO CAIA NESSA!
A banca explora a confusão entre proteções de sessão. HttpOnly (alternativa C) protege contra XSS, não CSRF. Já a alternativa B inventa um cabeçalho específico — lembre-se: a proteção CSRF padrão usa tokens, não cabeçalhos fixos.
Gabarito: letra D — uso de tokens anti-CSRF é a medida correta e amplamente adotada.