SQL Injection é uma técnica de ataque na qual o invasor se aproveita de falhas em aplicativos web que interagem com bases de dados para inserir uma instrução SQL personalizada e indevida. Para evitar essa ameaça de segurança, é necessário:
- A)utilizar expressões regulares para cifrar as variáveis enviadas para o sistema;
Errada: expressões regulares não servem para cifrar variáveis, e criptografia não resolve SQL Injection.
- B)concatenar diretamente o input do usuário com a consulta SQL;
Errada: concatenar diretamente o input do usuário na SQL é justamente a prática que facilita o ataque.
- C)encapsular as entradas de dados dentro de aspas simples ao montar dinamicamente consultas SQL;
Errada: colocar aspas simples não impede injeção, porque o invasor pode quebrar a estrutura da consulta.
- D)retornar no corpo das respostas HTTP as mensagens de erro em bancos de dados;
Errada: exibir mensagens de erro do banco na resposta HTTP ajuda o atacante a entender a estrutura interna do sistema.
- E)validar todas as entradas de dados, como formulários ou URL da aplicação.
Certa: validar todas as entradas é uma medida básica para reduzir o risco de SQL Injection.
Gabarito: E
SQL Injection acontece quando o sistema monta a consulta SQL do jeito errado e acaba misturando comando com dado. Em vez de tratar a entrada do usuário como simples informação, o aplicativo engole o texto recebido e pode transformar isso em uma instrução maliciosa. É o famoso caso em que o banco faz exatamente o que foi mandado, mas o problema foi quem escreveu a consulta sem cuidado. Para reduzir esse risco, a regra de ouro é não confiar em nenhuma entrada externa: formulário, URL, cookie, cabeçalho e até campos que pareçam inofensivos. Validar, filtrar e, principalmente, usar consultas parametrizadas/prepared statements são as medidas mais seguras na prática. Isso impede que o conteúdo enviado pelo usuário seja interpretado como parte do código SQL. No enunciado, a banca quer justamente a ideia de proteção por validação das entradas. Isso é coerente com boas práticas de segurança da informação, como o princípio de "input validation" e de defesa em profundidade. Em prova, desconfie de alternativas que misturam criptografia, aspas soltas ou concatenação direta: isso quase sempre é caminho para desastre. Por isso, o gabarito está em validar todas as entradas de dados, como formulários ou URL da aplicação. Não é a única medida possível na vida real, mas é a que melhor expressa a prevenção pedida pela questão.