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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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:
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çãoget_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.
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çãoget_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.
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.
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.
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.
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.
Nenhum comentário:
Postar um comentário