Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — FCC 2025
Segurança da Informação›Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.)
Código
fc150696
Banca
FCC
Órgão
TRT 1
Ano
2025
Cargo
TJ TRT1
Uma equipe de Técnicos Judiciários recebeu relatos de usuários identificando atividades suspeitas no sistema web interno de um Tribunal Regional do Trabalho. Ao realizar uma auditoria de segurança, foi descoberto que um invasor explorou uma falha na aplicação web para inserir comandos maliciosos e obter acesso não autorizado ao banco de dados. Como consequência, dados sigilosos foram extraídos e manipulados. Além disso, o atacante conseguiu elevar privilégios e criar novas contas administrativas, comprometendo a integridade do sistema. A auditoria concluiu que
Ao ataque foi um Cross-Site Scripting (XSS), no qual o invasor injetou scripts maliciosos na aplicação web para roubar informações dos usuários. A principal solução é considerar a entrada de dados como não-confiável. No caso de entrada de dados em HTML, por exemplo, conteúdos ativos são os mais recomendados.
Ba causa do problema foi a ausência de autenticação multifator (MFA), que permitiu que o atacante acessasse contas privilegiadas apenas com senhas comprometidas. Para evitar esse tipo de ataque, deve-se implementar MFA obrigatório para todas as contas administrativas, conforme recomenda o CIS Controls v8.
Co incidente foi causado por um ataque de força bruta, no qual o invasor testou múltiplas combinações de senhas até obter acesso. A solução mais eficaz seria bloquear automaticamente endereços IP após um número excessivo de tentativas falhas de login.
Do problema ocorreu devido a um ataque Man-in-the-Middle (MITM), que permitiu ao atacante interceptar credenciais de usuários na rede. Para evitar esse tipo de ameaça, deve-se implementar criptografia TLS para todas as comunicações web.
Ea vulnerabilidade explorada foi uma falha de SQL injection, que permitiu ao invasor executar comandos maliciosos diretamente no banco de dados da aplicação. Para mitigar esse risco, devem-se utilizar consultas parametrizadas, restringir privilégios de banco de dados e adotar práticas de segurança recomendadas pelo CIS Controls v8.
Revelar gabarito e comentário▾
GabaritoE — a vulnerabilidade explorada foi uma falha de SQL injection, que permitiu ao invasor executar comandos maliciosos diretamente no banco de dados da aplicação. Para mitigar esse risco, devem-se utilizar consultas parametrizadas, restringir privilégios de banco de dados e adotar práticas de segurança recomendadas pelo CIS Controls v8.
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”.
SQL Injection: injeção de comandos no banco de dados
Gabarito: letra E. O cenário descreve um ataque de SQL Injection, no qual o invasor explora falhas na validação de entradas da aplicação para inserir comandos SQL maliciosos diretamente no banco de dados, permitindo extração, manipulação de dados e elevação de privilégios. A mitigação correta envolve consultas parametrizadas, restrição de privilégios e práticas do CIS Controls v8.
O SQL Injection (SQLi) é uma vulnerabilidade de segurança web que permite a um invasor interferir nas consultas que uma aplicação faz ao seu banco de dados. Isso ocorre quando os dados fornecidos pelo usuário não são validados, filtrados ou higienizados, e são concatenados diretamente em consultas SQL dinâmicas. O atacante pode então visualizar dados que normalmente não poderia acessar, modificar ou deletar esses dados, e até mesmo elevar privilégios, como descrito no enunciado.
A principal causa é a construção de consultas dinâmicas sem parametrização, onde os dados hostis são usados diretamente ou concatenados. A prevenção fundamental é manter os dados separados dos comandos e consultas, utilizando consultas parametrizadas (prepared statements), que tratam a entrada como dado, não como código executável. Além disso, é essencial restringir privilégios de banco de dados ao mínimo necessário (princípio do menor privilégio) e adotar práticas de segurança recomendadas pelo CIS Controls v8, que incluem controle de acesso e gestão de vulnerabilidades.
É importante distinguir o SQL Injection de outros ataques web comuns. O XSS (Cross-Site Scripting) executa scripts maliciosos no navegador do usuário, explorando a confiança que o navegador tem no site. O CSRF (Cross-Site Request Forgery) força o usuário autenticado a executar ações indesejadas, explorando a confiança que o site tem no navegador. O ataque de força bruta testa múltiplas combinações de senhas, e o MITM (Man-in-the-Middle) intercepta comunicações na rede. Cada um tem características e mitigações específicas, e a banca explora exatamente essa confusão entre eles.
A pegadinha central desta questão é associar o cenário de acesso direto ao banco de dados com o ataque errado. O candidato pode confundir com XSS, que também envolve injeção, mas atua no navegador, não no banco. A chave é identificar o alvo: o SQL Injection atinge o banco de dados, enquanto o XSS atinge o navegador do usuário. Além disso, a menção a "elevar privilégios e criar novas contas administrativas" é um forte indicativo de SQL Injection, pois permite manipular diretamente os dados de autenticação no banco.
Guarde a fronteira entre os ataques: SQL Injection = injeção no banco de dados; XSS = injeção de scripts no navegador; CSRF = ações forçadas em sessão autenticada. É exatamente nessa distinção que as alternativas se dividem.
Ataque
Alvo
Efeito principal
Mitigação típica
SQL Injection
Banco de dados
Execução de comandos SQL maliciosos; extração/manipulação de dados; elevação de privilégios
Consultas parametrizadas; restrição de privilégios; CIS Controls v8
XSS (Cross-Site Scripting)
Navegador do usuário
Execução de scripts maliciosos no navegador; roubo de informações da vítima
Sanitização/validação de entradas; evitar conteúdos ativos não confiáveis
CSRF (Cross-Site Request Forgery)
Sessão autenticada
Forçar o usuário autenticado a executar ações indesejadas
Tokens anti-CSRF; validação de origem
Força bruta
Autenticação
Tentativas repetidas de senhas até obter acesso
Bloqueio de IP; MFA; políticas de senha
MITM (Man-in-the-Middle)
Comunicação de rede
Interceptação de credenciais/dados em trânsito
Criptografia TLS; autenticação mútua
Alternativa A — ❌ Incorreta
Descreve o ataque como XSS, mas o cenário indica acesso direto ao banco de dados, característico de SQL Injection. O XSS executa scripts no navegador da vítima, não no banco. A solução citada, "considerar a entrada de dados como não-confiável", é uma boa prática geral, mas a afirmação de que "conteúdos ativos são os mais recomendados" em HTML é incorreta — na verdade, deve-se evitar ou sanitizar conteúdos ativos para prevenir XSS.
Alternativa B — ❌ Incorreta
Atribui a causa à ausência de MFA, mas o cenário descreve uma falha de injeção, não de autenticação. O MFA é uma defesa contra acesso não autorizado por credenciais comprometidas, mas não impede SQL Injection. A implementação de MFA é uma boa prática, mas não é a solução para a vulnerabilidade descrita.
Alternativa C — ❌ Incorreta
Classifica o incidente como ataque de força bruta, que testa múltiplas combinações de senhas. O cenário, porém, descreve a exploração de uma falha na aplicação para inserir comandos maliciosos no banco, não tentativas repetidas de login. Bloquear IPs após tentativas falhas é uma medida contra força bruta, não contra SQL Injection.
Alternativa D — ❌ Incorreta
Aponta MITM, que intercepta credenciais na rede. O cenário não menciona interceptação de comunicação, mas sim injeção de comandos na aplicação. TLS é uma defesa contra MITM, mas não resolve a vulnerabilidade de SQL Injection.
Alternativa E — ✅ Correta ⟵ GABARITO
Identifica corretamente a SQL Injection como a vulnerabilidade explorada, permitindo executar comandos maliciosos diretamente no banco de dados. As mitigações citadas — consultas parametrizadas, restrição de privilégios e práticas do CIS Controls v8 — são exatamente as recomendadas para prevenir esse tipo de ataque, conforme o conteúdo de apoio.
NÃO CAIA NESSA!
A banca troca o alvo do ataque: SQL Injection atinge o banco de dados, enquanto XSS atinge o navegador e CSRF explora a sessão autenticada. O candidato que confunde esses alvos cai nas alternativas A, C ou D. Lembre-se: injeção de comandos SQL = banco de dados; script no navegador = XSS; ação forçada em sessão = CSRF.
PEGA ESSA DICA!
Para identificar o tipo de ataque, foque no alvo e no efeito: se o invasor manipula diretamente o banco de dados, é SQL Injection; se executa scripts no navegador da vítima, é XSS; se força ações em uma sessão já autenticada, é CSRF. Essa distinção resolve a maioria das questões sobre ataques web.