GabaritoE — Errado
❌ ERRADO. A afirmação está incorreta porque, embora as consultas parametrizadas sejam a principal defesa contra SQL Injection, elas não eliminam todas as vulnerabilidades de injeção, como a LDAP Injection, que exige técnicas específicas de sanitização e escape. O uso de consultas parametrizadas é uma medida eficaz contra injeção de SQL, mas não é uma solução universal para todos os tipos de injeção.
O conceito central aqui é o de injeção (injection), uma das categorias mais críticas do OWASP Top 10. Injeção ocorre quando dados fornecidos pelo usuário são interpretados como parte de um comando ou consulta, permitindo que um atacante manipule a execução. Isso pode acontecer em diferentes contextos: SQL, LDAP, comandos do sistema operacional, NoSQL, entre outros. A defesa fundamental é manter os dados separados dos comandos, garantindo que a entrada do usuário seja tratada como dado, e não como código.
As consultas parametrizadas (também chamadas de prepared statements) funcionam exatamente assim: o comando SQL é definido com placeholders (parâmetros), e os valores fornecidos pelo usuário são passados separadamente, de modo que o banco de dados os trata como dados puros, nunca como parte da instrução. Isso elimina a possibilidade de SQL Injection naquela consulta específica, pois o conteúdo do parâmetro não é concatenado ao comando. Porém, essa técnica é específica para consultas SQL. A LDAP Injection explora consultas ao protocolo LDAP (Lightweight Directory Access Protocol), usado para acesso a diretórios. A defesa adequada envolve a validação e sanitização das entradas e o escape de caracteres especiais conforme a sintaxe do interpretador LDAP, não o uso de consultas parametrizadas SQL.
Na prática, um desenvolvedor que usa consultas parametrizadas para todas as interações com o banco de dados está protegido contra SQL Injection. No entanto, se a mesma aplicação também realiza consultas LDAP (por exemplo, para autenticação em um diretório corporativo) e não aplica as devidas proteções, ela continua vulnerável a LDAP Injection. Portanto, a afirmação de que consultas parametrizadas eliminam vulnerabilidades de injeção de forma geral é incorreta.
A banca explora aqui a generalização indevida: o candidato sabe que consultas parametrizadas previnem SQL Injection e pode assumir que isso vale para todas as injeções. A pegadinha está em estender uma defesa específica a um conjunto mais amplo de ameaças. É essencial lembrar que cada tipo de injeção exige uma defesa adequada ao seu interpretador.
A afirmação é incorreta porque generaliza o alcance das consultas parametrizadas. Elas são a defesa primária contra SQL Injection, mas não têm efeito direto sobre LDAP Injection, que requer validação de entrada e escape de caracteres específicos do protocolo LDAP. O OWASP Top 10 lista a injeção como uma categoria que abrange SQL, NoSQL, comandos de sistema, LDAP e outras, e as medidas de prevenção variam conforme o tipo. Portanto, afirmar que consultas parametrizadas eliminam vulnerabilidades de injeção como SQL e LDAP é um erro.
A banca troca a defesa específica (consultas parametrizadas contra SQL Injection) por uma solução universal para todas as injeções. O candidato que sabe que parametrização previne SQLi pode marcar "certo" sem perceber que LDAP Injection exige outra abordagem. Lembre-se: cada interpretador (SQL, LDAP, shell) tem sua própria técnica de escape e validação.
Gabarito: ❌ ERRADO.
Link permanente: /questoes/ce390767