A segurança das informações é um assunto que exige atenção especial, principalmente em se tratando de informações armazenadas em bancos de dados acessados via web.
Uma das técnicas de fraude mais conhecida pelos desenvolvedores web é a SQL Injection. Trata-se da manipulação de uma instrução SQL através das variáveis quem compõem os parâmetros recebidos por um script server-side, tal como PHP, ASP, ColdFusion e outros.
O principal motivo pelo qual deve-se impossibilitar a utilização da SQL Injection está no fato de que, através de uma simples instrução SQL, como por exemplo, uma projeção de dados, outras operações podem ser executadas, podendo impactar sobre o esquema das tabelas, os dados armazenados, e até mesmo sobre elementos do sistema operacional, tendo em vista que alguns bancos de dados permitem a execução de comandos do shell do próprio sistema operacional.
Detectando a vulnerabilidade de um sistema
Para ilustrar o conceito de SQL Injection, a seguinte simulação pode ser realizada. Imaginemos que um script de validação de acesso de usuários tenha sido desenvolvido como segue:
Nas linhas 3 e 4, as variáveis $usuario e $senha, respectivamente, recebem o conteúdo submetido por um formulário através do método POST. Eis a fonte do problema.
Suponha que a seguinte entrada tenha sido informada no campo usuário no formulário chamador do script de validação.
Logo, a query string resultante será:
Se nenhuma outra validação for realizada, o usuário mal intencionado terá efetuado login no sistema, sem ao menos informar um usuário contido na tabela. Isto foi possível pois o valor de entrada informado não recebeu o tratamento devido, sendo adicionado à instrução para ser executado. Vale ressaltar que as validações apresentadas no exemplo são apenas ilustrativas, havendo a necessidade de checagens mais eficazes para um script de validação de acesso.
Impossibilitando o uso de SQL Injection
Para que se esteja livre da utilização da SQL Injection, certas providências devem ser tomadas. Algumas das ações serão realizadas no servidor de banco de dados, outras devem ser garantidas pelo código fonte.
Deve-se tomar cuidado com a configuração do usuário que estabelece a conexão com o banco de dados. O ideal é que as permissões de acesso deste usuário estejam restritamente limitadas às funções que irá realizar, ou seja, para a exibição de um relatório, a conexão com o banco de dados deve ser realizada por um usuário com permissões de leitura e acesso somente às tabelas necessárias para sua operação.
Todos os valores originados da coleta de dados externos, devem ser validadas e tratadas a fim de impedir a execução de eventuais instruções destrutivas ou operações que não sejam as esperadas.
Um tratamento básico para a execução de querys com variáveis contendo valores informados pelo usuário:
Com a utilização da função addslashes() será adicionada uma barra invertida antes de cada aspa simples e aspa dupla encontrada, processo conhecido como escape. Se a diretiva de configuração do PHP magic_quotes_gpc estiver ativada, o escape é realizado automaticamente sobre os dados de COOKIES e dados recebidos através dos métodos GET e POST. Neste caso, não deve ser efetuado o tratamento com addslashes(). A função get_magic_quotes_gpc(), disponível nas versões do PHP a partir da 3.0.6, retorna a configuração atual da diretiva magic_quotes_gpc.
Abaixo, a query string resultante da aplicação do tratamento mencionado:
Em muitos bancos de dados, existem funções específicas para o tratamento de variáveis em query strings, o que diminui a compatibilidade do código fonte para operação com outros sistemas de banco de dados.
Outra dica importante é evitar a exibição das mensagem de erro em um servidor de aplicação em produção, pois geralmente nos erros ou alertas são exibidos caminhos de diretórios do sistema de arquivos e informações à respeito do esquema do banco de dados, podendo comprometer a segurança do sistema.
Para ocultar a exibição de erros e alertas do PHP, é necessária a configuração da diretiva display_errors para Off no arquivo de configurações do PHP.
Cabe ao desenvolvedor estar atento às possíveis brechas de segurança existentes nos códigos fonte que produz, principalmente quando o que está em jogo é um bem de grande valia: a informação. Tenha consciência. Isto evita futuras dores de cabeça e atritos desnecessários com o cliente.
36 Comentários
Qual a sua opinião?