Questão de Segurança da Informação — Ataques e ameaças — FGV 2025
Segurança da Informação›Ataques e ameaças
Código
fg104524
Banca
FGV
Órgão
AL-AM
Ano
2025
Nível
Superior
Cargo
Analista Legislativo - Analista de Sistema
Ao desenvolver a área de intranet da Assembleia, o Analista de Sistemas deve se proteger contra ataques de Cross-Site Scripting (XSS), que ocorrem quando um invasor injeta código malicioso no navegador de um usuário.
A principal linha de defesa contra a maioria dos ataques XSS, aplicada na saída de dados do servidor para o browser, é
Ao Output Encoding de dados não confiáveis.
Bimplementar Rate Limiting no backend.
Cutilizar senhas fortes e únicas para cada usuário.
Dusar Prepared Statements no banco de dados.
Ebloquear todas as requisições HTTP do tipo POST.
Revelar gabarito e comentário▾
GabaritoA — o Output Encoding de dados não confiáveis.
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”.
Defesa contra Cross-Site Scripting (XSS)
Gabarito: letra A. A principal defesa contra XSS, aplicada na saída de dados do servidor para o navegador, é o Output Encoding de dados não confiáveis, que codifica caracteres especiais para evitar que scripts injetados sejam interpretados pelo navegador. As demais alternativas protegem contra outras ameaças, mas não contra XSS.
A questão exige conhecimento das contramedidas específicas para cada tipo de ataque. O Cross-Site Scripting explora a falta de sanitização de entradas/saídas, permitindo que código malicioso (geralmente JavaScript) seja executado no contexto de um site confiável. A proteção mais eficaz no lado do servidor, ao gerar respostas HTML, é o Output Encoding (ou escaping), que converte caracteres como <, >, &, " em suas entidades HTML seguras (ex.: <, >).
Alternativa A — ✅ Correta ⟵ GABARITO
O Output Encoding de dados não confiáveis é a técnica recomendada pelo OWASP como principal barreira contra XSS refletido, armazenado e baseado em DOM. Ao codificar a saída, o conteúdo injetado é tratado como texto comum, não como código executável.
Alternativa B — ❌ Incorreta
Implementar Rate Limiting no backend limita o número de requisições em um período, prevenindo ataques de força bruta e DDoS, mas não impede a injeção de scripts em páginas.
Alternativa C — ❌ Incorreta
Senhas fortes e únicas protegem contas contra acesso não autorizado, mas não evitam que um invasor insira código malicioso que será executado no navegador de outros usuários.
Alternativa D — ❌ Incorreta
Prepared Statements (ou consultas parametrizadas) são a defesa padrão contra SQL Injection, pois separam os dados do comando SQL. Não têm efeito sobre injeção de scripts no navegador.
Alternativa E — ❌ Incorreta
Bloquear requisições HTTP do tipo POST inviabilizaria funcionalidades legítimas do sistema e não impediria XSS, já que scripts podem ser injetados também via GET, cabeçalhos ou outras fontes.
NÃO CAIA NESSA!
A alternativa D (Prepared Statements) é um distrator clássico: muitos candidatos confundem a proteção contra SQL Injection (que age no banco de dados) com a proteção contra XSS (que age no navegador). Lembre-se: Output Encoding é para XSS; Prepared Statements são para SQL Injection.