Acerca dos conceitos de segurança web e da Lei Geral de Proteção de Dados Pessoais (LGPD) – Lei nº 13.709/2018 –, julgue o item seguinte.Utilizar comandos SQL diretamente concatenados com dados fornecidos pelo usuário é uma prática eficaz para proteger a aplicação contra ataques do tipo injeção de código, que podem comprometer o banco de dados, disponibilizado pela Internet.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
Segurança web: injeção de SQL e a LGPD
Gabarito: ERRADO. Concatenar comandos SQL diretamente com dados fornecidos pelo usuário é exatamente a prática que abre a porta para ataques de injeção de SQL (SQL Injection), e não uma proteção — a forma segura é usar comandos parametrizados (prepared statements) e validar/filtrar as entradas. A afirmação inverte completamente o conceito de segurança, e a LGPD, embora trate da proteção de dados pessoais, não altera essa regra técnica de segurança da informação.
A injeção de SQL é uma das ameaças mais comuns e perigosas a sistemas que utilizam banco de dados. Ela ocorre quando o atacante consegue inserir comandos SQL maliciosos através de campos de entrada de dados de uma aplicação (como formulários de login, campos de busca ou URLs). O problema fundamental é que, ao concatenar diretamente a entrada do usuário na string da consulta SQL, a aplicação não consegue distinguir o que é dado do que é comando — o interpretador SQL passa a executar o trecho malicioso como parte da instrução legítima.
Imagine um sistema de login que monta a consulta assim: SELECT * FROM usuarios WHERE nome = '$usuario' AND senha = '$senha'. Se o atacante digitar no campo de senha ' OR '1'='1, a consulta final vira SELECT * FROM usuarios WHERE nome = 'x' AND senha = '' OR '1'='1'. Como '1'='1' é sempre verdadeiro, a condição inteira é satisfeita e o atacante consegue acessar o sistema sem credenciais válidas. Esse é o exemplo clássico de manipulação de SQL, o tipo mais comum de ataque de injeção.
Os danos possíveis vão muito além do login indevido: o atacante pode obter dados sigilosos de todo o banco, alterar ou excluir informações, executar comandos remotos no servidor, contornar a autenticação, realizar escalada de privilégios e até provocar negação de serviço. Por isso, a proteção contra injeção de SQL é um requisito básico de segurança em qualquer aplicação que acesse banco de dados.
As técnicas corretas de proteção são justamente o oposto da concatenação direta. A principal delas é o uso de comandos parametrizados (prepared statements), em que a entrada do usuário é vinculada a um parâmetro da consulta, e não embutida na string SQL. Outra técnica é a validação e filtragem da entrada, removendo ou escapando caracteres especiais como a aspa simples. O material de apoio confirma: "O uso de variáveis de ligação (também conhecidas como parâmetros) protege contra ataques de injeção e também melhora o desempenho".
A LGPD (Lei nº 13.709/2018) estabelece a obrigação de adotar medidas de segurança para proteger dados pessoais, mas não define técnicas específicas de programação. Ela exige que os agentes de tratamento adotem medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou difusão. A concatenação de SQL é uma falha de segurança que pode levar ao vazamento de dados pessoais, o que violaria diretamente os princípios e obrigações da LGPD — portanto, a prática descrita no item é não apenas ineficaz, mas também um risco de não conformidade com a lei.
A pegadinha desta questão é a inversão total do conceito: a banca apresenta a prática mais vulnerável como se fosse uma medida de proteção. O candidato que conhece o básico de segurança web identifica imediatamente que concatenar SQL com entrada do usuário é a causa da vulnerabilidade, não a solução. Guarde essa distinção: concatenar = vulnerável; parametrizar = seguro.
SQL Injection: Causa (Concatenar SQL com entrada do usuário, Aplicação não distingue dado de comando); Consequências (Acesso indevido, Vazamento de dados, Alteração/exclusão de dados, Escalada de privilégios); Proteção (Comandos parametrizados (prepared statements), Validação/filtragem da entrada)
Item — ❌ ERRADO
A afirmação está errada porque inverte completamente o conceito de segurança. Utilizar comandos SQL diretamente concatenados com dados fornecidos pelo usuário é a causa da vulnerabilidade de injeção de SQL, não uma proteção. Essa prática permite que o atacante manipule a consulta SQL inserindo comandos maliciosos através da entrada de dados, comprometendo o banco de dados. A forma correta de proteger a aplicação é usar comandos parametrizados (prepared statements) e validar/filtrar as entradas do usuário.
NÃO CAIA NESSA!
Na prova, quando a questão falar em "concatenar SQL com dados do usuário", "montar query com entrada direta" ou "string de consulta com valores do usuário", a resposta quase sempre será que isso é vulnerável a SQL Injection. A proteção correta é sempre parametrização (prepared statements) e validação de entrada. Essa é uma pegadinha recorrente em concursos de TI.