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

Injeção de SQL (SQL Injection)

Gabarito: letra C. A principal causa da injeção de SQL é a falha na validação adequada da entrada do usuário: quando a aplicação concatena dados fornecidos pelo usuário diretamente em consultas SQL, sem validar, filtrar ou higienizar essas entradas, o atacante consegue manipular a consulta e executar comandos maliciosos no banco de dados. Essa é a essência da vulnerabilidade, conforme o OWASP Top 10 e a literatura de segurança da informação.

A injeção de SQL (SQLi) é um tipo de ataque que explora a confiança excessiva que a aplicação deposita na entrada do usuário. Em vez de tratar os dados como simples valores, a aplicação os interpreta como parte do comando SQL, permitindo que o invasor altere a lógica da consulta. Por exemplo, em um formulário de login, se o campo de senha receber ' OR '1'='1, e a aplicação montar a consulta SELECT * FROM usuarios WHERE login='admin' AND senha='' OR '1'='1', a condição '1'='1' é sempre verdadeira, e o atacante consegue acessar o sistema sem credenciais válidas.

A causa raiz, portanto, não está em falhas de autenticação, firewalls, criptografia ou atualizações do sistema operacional — embora esses elementos façam parte de uma estratégia de segurança mais ampla, eles não são a origem da vulnerabilidade de injeção. A injeção de SQL ocorre no nível da aplicação, na forma como as consultas são construídas e como os dados de entrada são tratados.

As principais vulnerabilidades que permitem a injeção de SQL são: dados fornecidos não são validados, filtrados ou higienizados; consultas dinâmicas ou chamadas não parametrizadas sem escape; dados hostis são usados diretamente ou concatenados em consultas. As prevenções incluem o uso de consultas parametrizadas (prepared statements), validação rigorosa de entrada, escape adequado de caracteres especiais e manutenção da separação entre dados e comandos.

É importante distinguir a injeção de SQL de outros ataques comuns a aplicações web, como XSS (Cross-Site Scripting) e CSRF (Cross-Site Request Forgery). Enquanto o SQL Injection ataca o banco de dados por meio da manipulação de consultas, o XSS explora a execução de scripts maliciosos no navegador do usuário, e o CSRF força o usuário autenticado a realizar ações indesejadas. A banca explora justamente essa confusão entre os tipos de ataque, e a alternativa correta é a que identifica a causa raiz da injeção de SQL.

Guarde o critério decisivo: a injeção de SQL é causada pela falta de validação/sanitização da entrada do usuário — é nesse ponto que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Falha na autenticação de usuários está relacionada a problemas como senhas fracas, falta de MFA ou gerenciamento inadequado de credenciais. Embora uma falha de autenticação possa permitir acesso não autorizado, ela não é a causa da injeção de SQL. A injeção explora a construção da consulta SQL, não o processo de autenticação em si.

Alternativa B — ❌ Incorreta

O uso inadequado de firewalls pode expor a rede a outros tipos de ataque, mas o firewall não é a defesa primária contra injeção de SQL. Como o ataque ocorre no nível da aplicação, o firewall não consegue distinguir uma consulta legítima de uma maliciosa, pois ambas chegam pela porta 80/443. A prevenção eficaz está na validação de entrada e no uso de consultas parametrizadas.

Alternativa C — ✅ Correta ⟵ GABARITO

A falha na validação adequada da entrada do usuário é exatamente a causa da injeção de SQL. Quando a aplicação não valida, filtra ou higieniza os dados fornecidos pelo usuário antes de incorporá-los a uma consulta SQL, o atacante pode injetar comandos maliciosos. Essa é a definição clássica da vulnerabilidade, e a alternativa espelha o texto do OWASP e da literatura de segurança.

Alternativa D — ❌ Incorreta

A implementação excessiva de criptografia não causa injeção de SQL. A criptografia protege os dados em trânsito e em repouso, mas não impede que uma consulta malformada seja executada. Na verdade, a criptografia é uma medida complementar de segurança, não uma causa de vulnerabilidade.

Alternativa E — ❌ Incorreta

Atualizações frequentes do sistema operacional são uma boa prática de segurança, pois corrigem vulnerabilidades conhecidas, mas não estão relacionadas à causa da injeção de SQL. A vulnerabilidade reside no código da aplicação, não no sistema operacional subjacente.

Gabarito: letra C