O que é SQL Injection e como se prevenir desse ataque?

SQL Injection é uma das vulnerabilidades mais perigosas para sites e aplicativos online. Ocorre quando um usuário adiciona dados não confiáveis ​​a uma consulta de banco de dados, por exemplo, ao preencher um formulário da web. 

Se a injeção de dados for habilitada, os invasores podem criar entradas do usuário para roubar dados valiosos, ignorar a autenticação ou corromper os registros em seu banco de dados.

Existem diferentes tipos de ataques de injeção de SQL, mas em geral, todos eles têm uma causa semelhante. Os dados não confiáveis ​​que o usuário insere são concatenados com a string de consulta. 

Portanto, a entrada do usuário pode alterar a intenção original da consulta e ocasionar inúmeros problemas de segurança. 

Neste artigo, abordamos e recomendamos algumas práticas saudáveis para técnicos usarem na prevenção de ataques de SQL Injection. Continue a leitura e entenda mais sobre essas práticas! 

Não confie na validação de entrada do lado do cliente

A validação de entrada do lado do cliente é uma excelente prática para evitar ataques de SQL Injection. Com a validação de entrada do lado do cliente, você já pode evitar que informações inválidas sejam enviadas para a lógica do seu sistema. No entanto, isso só funciona para usuários que não têm más intenções e desejam usar o sistema conforme projetado. 

Fornecer ao usuário um feedback direto de que um determinado valor não é válido é muito útil e fácil de usar. Portanto, você deve usar a validação do lado do cliente para ajudar na experiência do usuário. 

Ao observar a injeção de SQL, não é um método no qual você deve confiar. Você pode remover a validação do lado do cliente alterando algum código Javascript carregado em seu navegador. 

Além disso, é muito fácil fazer uma chamada HTTP básica para o backend em uma arquitetura cliente-servidor com um parâmetro que causa uma injeção de SQL. Tanto usando ferramentas como curl comandos da velha guarda.

Você deve validar no lado do servidor, de preferência o mais próximo possível da fonte. Neste caso, você cria a consulta SQL. Tudo o que um cliente envia a você deve ser considerado potencialmente prejudicial. Portanto, confiar na validação do lado do cliente para injeção de SQL, nesse caso, é uma ideia terrível.

Use mecanismos de banco de dados com privilégios restritos

Ao criar um usuário de banco de dados para sua  aplicação, você deve pensar sobre os privilégios deste usuário.

O aplicativo precisa ser capaz de ler, gravar e atualizar todos os bancos de dados? Que tal truncar ou descartar tabelas? Se você limitar os privilégios de seu aplicativo no banco de dados, poderá minimizar o impacto da injeção de SQL. 

 É aconselhável não ter um único usuário de banco de dados para sua aplicação, mas criar vários usuários de banco de dados e conectá-los a funções de aplicativo específicas, com diferentes privilégios. Os problemas de segurança são provavelmente um efeito cascata, portanto, você deve estar ciente de todos os relacionamento para evitar danos pesados.

Use instruções prontas e parametrização de consulta

Muitas linguagens têm recursos integrados disponíveis que ajudam a prevenir a injeção de SQL. Ao escrever consultas SQL, você pode usar algo como uma instrução pronta para compilar a consulta. 

Com uma instrução pronta, podemos realizar a parametrização da consulta, que  é uma técnica para criar instruções SQL dinamicamente. Você cria a consulta de base com alguns espaços reservados e anexa com segurança os parâmetros fornecidos pelo usuário a esses espaços reservados.

Ao usar uma instrução pronta real e consultas parametrizadas, o próprio banco de dados realmente cuida do escape. Primeiro, ele constrói o plano de execução da consulta com base na string de consulta com espaços reservados. 

Na segunda etapa, os parâmetros (não confiáveis) são enviados ao banco de dados. O plano de consulta já está criado, então os parâmetros não influenciam mais nisso. Isso evita a injeção completamente.

Faça uma varredura em seu código em busca de vulnerabilidades de injeção de SQL

Criar código personalizado provavelmente é fácil. No entanto, os erros são facilmente cometidos. Para verificar seu código, você pode ter processos em funcionamento, como revisão de código e programação em pares. 

No entanto, a pessoa que revisa seu código de pares com você precisa ser um bom conhecedor de cibersegurança. Independentemente disso, seria bom examinar automaticamente seu código personalizado para possíveis vulnerabilidades de segurança.

Com os serviços de algumas ferramentas, você pode inspecionar de maneira automática seu código em busca de vulnerabilidades de segurança. Isso pode ser facilmente automatizado em seu sistema, facilitando a procura por “brechas” utilizadas pelos cibercriminosos para invadir as suas estruturas. 

Execute a validação de entrada

Sim, você deve fazer validação de entrada, sempre! Embora as instruções preparadas com parametrização de consulta sejam a melhor defesa contra a injeção de SQL, sempre crie várias camadas de defesa. Assim como ter privilégios limitados para um usuário de banco de dados, a validação de entrada é uma ótima prática para reduzir o risco de seu aplicativo em geral.

Além disso, existem situações em que as declarações prontas não estão disponíveis. Alguns idiomas não oferecem suporte a esse mecanismo ou sistemas de banco de dados mais antigos não permitem que você forneça a entrada do usuário como parâmetro. A validação de entrada é uma alternativa aceitável nesses casos.

Certifique-se de que a validação de entrada depende da lista de permissões e não da lista de bloqueio, conforme descrito anteriormente. Crie uma regra que descreva todos os padrões permitidos com clareza. 

Tenha cuidado com os procedimentos armazenados

Muitas pessoas acreditam que trabalhar com procedimentos armazenados é uma boa maneira de evitar invasões. Isso não é sempre o caso. Semelhante às consultas SQL criadas em seu aplicativo, um procedimento armazenado também pode ser injetado de forma mal-intencionada. 

Como as consultas SQL em seu aplicativo, você deve parametrizar as consultas em seu procedimento armazenado em vez de concatenar os parâmetros. A injeção de SQL em um procedimento armazenado é muito fácil de prevenir.

Certifique-se de saber como implementar procedimentos armazenados para seu banco de dados e esteja atento às SQL Injections também. Gostou de tudo que foi discutido por aqui? Então, acrescente a sua leitura e saiba quais os ataques virtuais mais comuns nas empresas e como evitá-los agora mesmo.