Questão de Tecnologia da Informação · FCC DPE-RS 2017 (nº 57)

As falhas de SQL Injection ocorrem quando a entrada do usuário é tratada como parte do código SQL, permitindo que um atacante manipule a consulta ao banco de dados. Para evitar isso, é crucial que a entrada do usuário seja sempre tratada como dados, e não como código.

• (A) Incorreta: Tokens imprevisíveis são usados para prevenir ataques de CSRF (Cross-Site Request Forgery), garantindo que a requisição venha de uma sessão legítima, e não para mitigar SQL Injection.
• (B) Incorreta: A referência direta a objetos por usuário ou sessão, se não for bem controlada, pode levar a vulnerabilidades de IDOR (Insecure Direct Object References), onde um usuário pode acessar recursos não autorizados, mas não é uma técnica de prevenção de SQL Injection.
• (C) Incorreta: "Buffer procedures" não é um termo padrão para prevenção de SQL Injection. "Stack SQL statements" sugere a concatenação de comandos SQL, o que é a causa da SQL Injection, não a solução.
• (D) Incorreta: "Direct statements" (consultas SQL construídas por concatenação de strings) são a principal causa de SQL Injection. Embora "design patterns" e "frameworks" possam incorporar boas práticas de segurança, eles não são as técnicas específicas de prevenção em si; são conceitos mais amplos. Armadilha da banca: Esta alternativa é tentadora porque frameworks e bons designs ajudam na segurança, mas a inclusão de "direct statements" (que são a raiz do problema) e a generalidade dos outros termos a tornam incorreta como técnica específica.
• (E) Correta: Prepared statements (consultas parametrizadas) e stored procedures (procedimentos armazenados) são técnicas eficazes porque separam o código SQL dos dados fornecidos pelo usuário. Isso garante que a entrada do usuário seja tratada apenas como valor, e não como parte da lógica da consulta, impedindo a injeção de código malicioso.