Prevenção de SQL Injection
Gabarito: letra E. Técnicas eficazes contra SQL Injection incluem o uso de prepared statements (consultas parametrizadas) e stored procedures quando implementados corretamente, pois separam os dados da estrutura SQL, impedindo a injeção de código malicioso. O contexto apresentado destaca o uso de variáveis de ligação (prepared statements) como principal defesa.
Alternativa A — ❌ Incorreta
Tokens imprevisíveis (como tokens CSRF) protegem contra ataques de falsificação de requisição entre sites, mas não impedem SQL Injection, que explora a má construção de consultas SQL com entrada do usuário.
Alternativa B — ❌ Incorreta
A referência direta a objetos (direct object reference) é uma vulnerabilidade em si — expõe identificadores internos sem validação de autorização —, portanto não é uma técnica de prevenção contra SQL Injection.
Alternativa C — ❌ Incorreta
"Buffer procedures" e "stack SQL statements" não são termos técnicos reconhecidos como medidas de segurança contra SQL Injection. Provavelmente confundem com outros conceitos (buffer overflow, pilha de chamadas) que não se aplicam diretamente.
Alternativa D — ❌ Incorreta
Direct statements (declarações diretas, como Statement em Java) são justamente o vetor de ataque, pois concatenam entrada do usuário na string SQL. Design patterns e frameworks podem auxiliar, mas isoladamente não garantem proteção contra injeção.
Alternativa E — ✅ Correta ⟵ GABARITO
Prepared statements (consultas parametrizadas) e stored procedures bem escritas são as técnicas mais eficazes. O contexto cita explicitamente: "O uso de variáveis de ligação (usando comandos parametrizados) protege contra ataques de injeção". As stored procedures, quando não utilizam concatenação dinâmica, também previnem injeção.
Gabarito: letra E