A melhor defesa para falhas de segurança é o teste adequado do software e a utilização componentes com alto nível de maturidade.
SQL Injection é uma ameaça de segurança que utiliza um conceito bastante simples para atacar suas vítimas: utilizar comando SQL em campos de entrada de dados na tentativa de “enganar” o programa e obter acesso ao banco de dados, podendo ser para roubar ou adulterar informações ou prejudicar a imagem da empresa, indisponibilizando os serviços prestados pela vítima.
Abaixo temos o exemplo de um aplicativo fictício:
FIGURA 1 – TELA DE UM SISTEMA FICTÍCIO PARA CONSULTAR AUTORES.
A consulta acima gera a query abaixo:
SELECT id, nome, sobrenome FROM autores WHERE nome = “MACHADO” AND sobrenome = “ASSIS”;
O comando acima simplesmente busca no banco de dados referências ao autor “Machado de Assis”. Com algum conhecimento em SQL e principalmente nas suas peculiaridades, um usuário pode fazer algo como o exemplo abaixo:
FIGURA 2 – CONSULTA CONTENDO INSTRUÇÕES SQL
Já esta consulta irá gerar o comando abaixo:
SELECT id, nome, sobrenomeFROM autores WHERE nome = “MACHADO”;
DROP TABLE autores;
–AND sobrenome = “ASSIS”;
Ao introduzir comandos SQL nos campos de entrada do sistema, o usuário acaba por apagar fisicamente a tabela “autores” do banco de dados. Caso o programa em questão não possua uma tratativa para detectar comandos SQL em entradas de dados, fica fácil para qualquer usuário ganhar acesso ao banco de dados.
De modo geral, todas as novas linguagens de programação já possuem bibliotecas de persistência que estão aptas a tratar este tipo de intrusão, como JPA (Java), NHibernate (.Net).
Infelizmente, muitas empresas consideram o investimento de comprar uma biblioteca para gerenciar a conexão com no banco de dados desnecessária, visto que a implementação de uma classe de conexão é simples, e acabam por deixar seu produtos expostos para este tipo ataque.
Investir em treinamento de equipe e utilizarmos boas práticas no desenvolvimento de software é fundamental para fazermos softwares seguros.
Por Fabrício Casali
Artigo do Seminário de Segurança em Desenvolvimento de Sistemas 2011-2
Revisão Thiarlei Macedo | Fonte Micreiros.com