SQL Injection é um erro de programação muito mais comum do que se pensa e suas consequências podem ser realmente devastadoras. Muitos ataques tem sucesso quando um hacker descobre uma vulnerabilidade que dá a oportunidade de se inserir um código de SQL Injection.

Quando um SQL Injection ocorre, a estrutura de um comando SQL é comprometida com algum código sinistro inserido pelo usuário e como resultado você fica potencialmente a mercê dos hackers. Se há uma vulnerabilidade encontrada, os hackers podem explorar para obter acesso não só ao site e ao banco de dados como, em casos extremos, também a sua rede corporativa.

Porque SQL Injection ocorre com tanta frequência?

A resposta mais curta e simples é que programadores programam mal, muito mal. Hacker varrem a internet em busca dessas vulnerabilidades de código para fazerem um SQL Injection, infelizmente eles não precisam buscar tanto assim, as vulnerabilidades pulam na sua cara. É um tipo de vulnerabilidae em que o risco para inserção é mínimo e as recompensas são gigantes, exatamente o que qualquer racker quer.

Então, não relaxe com seu código achando que ninguém vai querer invadir seu site ou sua aplicação, existem outros interesses além de colocar seu site fora do ar ou buscar alguns dados em seu banco. Inseriri códigos maliciosos, obter acesso a rede onde está hospedado seu site, usar o espaç em disco para guardar arquivos e até mesmo usar o processamento da máquina para executar programas maliciosos.

A boa notícia é que, felismente,  SQL injection são relativamente fáceis de se evitar.

Medidas para se evitar um SQL Injection

Basicamente existem duas maneiras de se evitar  a todo custo um SQL injection:
1. Não use consultas de banco de dados dinâmicas
2. Não aceitar dados vindo dos usuários nas suas consultas

No entanto se seguirmos a risca esses dois passos nossos sites serão praticamente páginas estáticas sem nenhuma interatividade com os usuários, o que hoje na internet seria um absurdo. O que você pode fazer é minimizar os riscos ao usar consultas dinâmicas e entrada de dados do usuário. Aqui vão alguns princípios básicos que se aplicam a qualquer linguagem de programqação:

1. Corrigir o servidor de SQL regularmente.

Antes de falarmos de dicas e correções em nosso códigos existem coisas fundamentais que devem ser analisadas. SQL Injection é frequentemente resultado de uma má aplicação de código, mas não é a única maneira de ser invadido. Se você possue falhas em seu sistema operacional e servidor de banco de dados todo cuidado com o código da aplicação pode se tornar inútil. Então, sugiro que mantenha seu sistema sempre atualizado, principlamente o servidor de banco de dados.

2. Limitar o uso de consultas dinâmicas.

Como já mencionado, consultas dinâmicas são as portas de entrada para SQL Injection. Claro que temos que ser realistas e entender que não podemos descartar todas as consultas dinâmicas do sistema, mas temos algumas alternativas que podem ser utilizadas como: Stored Procedures, selects parametrizados, e acima de tudo – prepared statements. Abordagens específicas mudam de uma linguagem para outra mas qualquer linguagem de programação oferece alternativas para consultas dinâmicas.

3. Escapar entradas de dados dos usuários.

O segundo maior problema para abertura de SQL Injection são as entradas de dados por usuários. Como não podemos evitar completamente as interações com dados de usuário a melhor solução é sempre tratá-las. Escapar as entradas não é o trabalho ideal para as SQLs dinâmicas, mas é fundamental para evitar boa parte dos SQLs Injections. Por exemplo, se você estiver usando PHP, para GET e POST, use htmlspecialchars() para escapar caracteres XSS e addslashes(), no caso de você usar banco de dados. Alternativamente, você pode escapar de entrada do usuário de dentro do seu banco de dados, mas já que o códigovaria de um banco de dados para outro, você deve verificar na documentação do seu banco de dados a sintaxe exata para usar.

4. Armazenas as credenciais do banco de dados em um arquivo separado.

Pode parecer algo obvio, mas já vi diversas aplicações onde a conexão com o banco de dados era efetuada diretamente no arquivo, junto aos comandos SQL. Não vou nem entrar aqui no assunto de Design Pattens e padrão de desenvolvimento. Proteger a chave de sua casa deve ser um comportamento padrão para qualquer pessoa.

5. Use o princípio do menor privilégio.

O princípo do menor privilégio é a pedra angular  da segurança de sistemas, e isso também se aplica a SQL Injection. Se você tem a possibilidade de minimizar os privilégios do usuário do seu sistema (para apenas consultas ou para apenas algumas tabelas) faça isso, pois caso você sofra um ataque, seus danos serão minimizados.

6. Desligar o magic quotes.

Magic quotes é um recurso que o PHP “tinha” onde qualquer string passada que houvesse aspas simples ou duplas era automaticamente escapadas com uma barra invertida. Isso parece ser uma grande solução, mas o problema é que vários sistemas e frameworks já fazem esse tratamento sendo preciso desligar essa opção no servidor. Sem falar que essa opção pode ser desligada sem que você saiba deixando seu sistema vulnerável.

Na versão 5.3 do PHP esse é um recurso em “deprecated” e será removido no PHP 6.0

7. Desativar acesso a shell.

Vários bancos de dados dão acesso ao Shell, ou seja, se um hacker conseguir por SQL Injection as credenciais do seu banco e esse recurso estiver ativado ele poderá acessar via terminal todos os recursos do seu banco de dados. Então, leia a documentação do seu banco de dados e desabilite o acesso externo ao seu banco. Ensine a ele igual sua mãe fez: “Menino, não converse com estranhos”.

8. Desativar qualquer funcionalidade do banco que você não precisa

Há diversos recursos que um SGDB lhe oferece além de acesso ao Shell. A regra aqui é quanto menos melhor. Embora nem todos sejam um risco de segurança é melhor remover todos os recursos que você não utiliza, além de diminuir o risco de segurança, isso pode lhe proporcionar um melhor desempenho.

9. Teste seu código

Esse é um dos pontos fundamentais e mais negligenciados pela maioria dos programadores. Exixtem ferramentas para automatizar esse processo, acho que uma das mais conhecidas é a extensão do Firefox SQL Inject me. Essa ferramenta tem muitas opções e muitos testes, o melhor seria se tivessemos tempo para executar todas eles.

Todos esses passos são bem fáceis de se implementar, mas não fazê-los pode fazer uma enorme diferença. Se ater a essas regras fará você diminuir drasticamente o risco que seu site sofre sobre SQL Injections. Ainda assim, você nunca pode estar 100 por cento certo de que estará completamente protegido contra esse tipo de ataque (ou qualquer outro tipo de ataque, para ser mais preciso) e é por isso que você precisa manter o olho em seus logs, se uma violação ocorrer , você vai saber imediatamente e reagir adequadamente para minimizar os danos.

Fonte: developerdrive