iMasters | Por uma internet mais criativa e dinâmica

• PHP
• Segurança

• Imprimir
• Indicar
• Digg it
• Del.icio.us
• Twitter
• 20 comentários

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.

Todos os artigos de Tiago Alexandre Vailati

20 comentários publicados

• 1. Muito bom seu artigo...

  Terça-feira, 05/12/2006, por Diego A. Griep
  

  Já conhecia o assunto, mas é sempre bom ler a visão de outras pessoas, é bom se proteGer do sql injection.
  
  * Dica:
  Quando for postar um artigo, tenha sempre um dicionário ao lado.
  
  [ ]'s

  Responder comentário

• 2. Legal

  Terça-feira, 05/12/2006, por Rafael Capucho
  

  Eu gostaria de saber se assim também é possivel um Injection: WHERE senha = '".$senha."'; espero respostas, Obrigado.

  Responder comentário

• 3. Otima iniciativa.

  Quarta-feira, 06/12/2006, por Luis Fernando D. Andrade
  

  Ola, gostei da sua materia e parabens pela iniciativa de falar sobre seguranca embora que bem superficialmente ;).
  Uma funcao muito boa 'anti sql injection' foi criada pelo Fabyo, aqui:
  http://forum.imasters.com.br/index.php?showtopic=125349&hl=sql injection
  
  Parabens e que voce continue abordando temas relacionados a essa materia.
  []s
  Luis

  Responder comentário

• 4. Ai ai...

  Quarta-feira, 06/12/2006, por Igor Escobar
  

  Tem gente que gosta de voltar no tempo...

  Responder comentário

• 5. De qualquer forma Parabéns!!!

  Quinta-feira, 07/12/2006, por DANIEL MAFFIOLETTI
  

  Sem dúvida que este assunto é importante para iniciantes. Existem vários métodos relacionados!

  Responder comentário

• 6. Criptografia

  Quinta-feira, 07/12/2006, por Cleison Pinter Baldin
  

  Outra forma de tratar o uso do SQL Injection, é obrigar o usuário a digitar login e senha, pois desta forma ninguem consegue submeter a pagina sem as dias informações.
  Também utilizar criptografia na senha é muito interessante.

  Responder comentário

• 7. Legal mas poderia ser melhor

  Quinta-feira, 07/12/2006, por Ana Claudia Nogueira
  

  Muito legal a sua iniciativa de falar sobre sql injection, mas ficou um pouco resumido, poderia ter sido falado mais sobre outros modos de injection

  Responder comentário

• 8. SQL Injection

  Quinta-feira, 07/12/2006, por Tiago Alexandre Vailati
  

  Pessoal, tudo certo? Como foi abordado no artigo, hoje em dia, o próprio PHP já possui tratamento para dados recebidos via POST, GET e Cookies. Logo, a utilização da SQL Injection tem sido bastante dificultada. O artigo visa explanar sobre o conceito e como a SQL Injection atua, por isso, foi tratada numa visão mais superficial.

  Responder comentário

• 9. Bom, mas!

  Sexta-feira, 08/12/2006, por Laércio Crestani
  

  Seria um pouco melhor um
  
  <?
  if(!isset($_POST['usuario']) || trim($_POST['usuario']) =='' || !isset($_POST['senha']) || trim ($_POST['senha'] =='')){
  
  header('location:login.php');
  exit;
  }
  else {
  echo $_POST['usuario'];
  echo $_POST['senha'];
  };
  ?>
  
  se chegar '' vazio, ele volta ai senão ele continua... um pouco mais lógico e ñ precisa dea verificação ON em magic_quotes_gpc no php.ini...

  Responder comentário

• 10. Regular Expression

  Domingo, 10/12/2006, por Anderson Cavalcante
  

  Boa a matéria,
  
  São poucos os programadores que pensam na questão: "Segurança". Por isso tantas falhas.
  
  Algo muito bom de utilizar, são as expressões regulares. Onde você especifica o que o campo poderá aceitar de caracter. Neste caso, entraria de a-z, A-Z, 0-9. Nada mais do que isso, dae não teria problema de substituir por contra barra para escapar o caracter. Por exemplo, posso utilizar o caracter #, que iria comentar o restante do código SQL ;)
  
  Abraços

  Responder comentário

• 11. Simples e batido

  Quarta-feira, 13/12/2006, por Thiago Ferreira
  

  O artigo não trouxe nada de novo. Explicações manjadas da web. Acho que é preciso trazer alguma coisa realmente nova ou nem escrever nada.

  Responder comentário

• 12. Iniciantes

  Sexta-feira, 15/12/2006, por Admir Tomaz
  

  Serve apenas para novatos, sendo que o perigo do injetion nem foi falado, o perigo é quando fica vulnerável a ter uma tabela toda deletada pelo "drop", até um "select" de uma busca mal programada pode gerar uma perda enorme de dados.

  Responder comentário

• 13. sql injection outra forma de proteção

  Sexta-feira, 15/12/2006, por Érico Gustavo Kmetzsch
  

  eu custumo usar a funcao do php htmlspecialchars() filtrando as variaveis que recebem valores do metodo POST ou GET

  Responder comentário

• 14. md5()

  Terça-feira, 19/12/2006, por Kenneth becker carletto
  

  Nao sei se esta tecnica eh muito comum, mas eu costumo usar a funcao md5($str) para login. Ela transforma $str em uma chave criptografada.
  Quando cadastro usuario, salvo no banco a senha criptografada. Como esta funcao nao permite volta (nao existe um desfaz_md5()), utiliza-se a funcao tambem na senha passada por post, na ocaisao do login.
  
  Acredito que este procedimento evite o problema do injection.

  Responder comentário

• 15. =D

  Quarta-feira, 31/01/2007, por Juliano dos Santos da Silva
  

  Ae galera to gostanu até pq eu sou um novato msm na area e tento o melhor q eu posso nunca tem ninguem pra dar uma mãozinha sabem como é ¬¬
  
  ae galera tipo se tive alguem a fim de me tirar uma duvida me add ae no msn: kcd_cs@hotmail.com
  
  vlw gente fica cum DEUS

  Responder comentário

• 16. typecast também é bom..

  Sexta-feira, 02/02/2007, por Tiago Gouvêa
  

  Outra maneira de "limitar" as entradas de dados é utilizando typecast, convertendo assim uma entrada obtida $_POST ou $_REQUEST em um tipo determinado.
  Uma maneira é: $codigo=(int) $codigo;
  Outra pode ser:
  settype($codigo,integer);
  
  Saudações

  Responder comentário

• 17. Um solução melhor para SQL Injection

  Quinta-feira, 30/08/2007, por Leonardo Cesar Teixeira
  

  A função addslashes() é meio ultrapassada e eu não vejo porque em utilizada se tem uma função específica do PHP pra escapar aspas simples e duplas.
  
  No caso de um simples login o addslashes() pode quebrar um galho, mas na caso de inserção de dados o addslashes() irá estragar os textos mandando eles pro banco de daodos com barras invertidas.
  
  Então já que este site é uma das principais guias para os programadores do Brasil, eu não acho certo ensinar como evitar um problema de segurança utilizando o pior método.
  
  A melhor função para evitar ataques de SQL Injection é usando a função mysql_real_escape_string(), ela irá escapar os dados apenas na hora da consulta e no banco de dados não irá ficar com as barras invertidas.
  
  Eu fiz um artigo em meu blog explicando como se proteger de ataques de SQL Injection de forma eficaz e sem "destruir" os dados. E também tem um tutorialzinho ensinando a criar uma função para proteger seus scripts contra este ataque.
  
  Para lêr o artigo acesse o endereço abaixo:
  
  http://blog.portaldoleo.com/2007/08/28/como-evitar-ataques-de-sql-injection-no-php-e-mysql/
  
  Mas esse artigo do Imasters está muito bom pras pessoas terem uma idéia de como ocorre um ataque de SQL Injection.
  
  Abraços!

  Responder comentário

• 18. Ajudou d

  Sábado, 08/09/2007, por Maurício Reatto Duarte
  

  Nossa, eu tava tendo este problema, daí não lembrava mais como usar o anti sql-injection
  Dai essa vlw ein !!

  Responder comentário

• 19. Não entendi a senha e login de escape

  Segunda-feira, 10/03/2008, por Moacir Fernandes
  

  Pelo que percebi, você está dando o select validando o login e senha de escape, para que serve então o login e senha se não está sendo usado!

  Responder comentário

• 20. Ferramenta para injetar códigos

  Quinta-feira, 17/07/2008, por Daniel Neto
  

  É um complemento do firefox que possibilita injetar codigo em qualquer campo do formulario, esta ferramenta é muito usada por hackers, a ferramenta pode ser baixada aqui: https://addons.mozilla.org/pt-PT/firefox/addon/6727

  Responder comentário

Sobre o autor

Tiago Alexandre Vailati é bacharelando em Ciência da Computação pela Univali/SC. Conhece as linguagens PHP, C++, Delphi, Mumps e Genexus. Possui conhecimento também em Ajax, JavaScript, Bancos de dados (MS SQLServer, PostgreSQL e MySQL) e Desing (Corel Draw, Photoshop e Photopaint).

Indique para um amigo

Tags relacionadas

publicidade windows youtube mercado criação linux google tecnologia desenvolvimento microsoft apple ti android seguranca php 3g mobile brasil twitter yahoo celular lançamento iphone internet web crescimento

TI SHOP Produtos iMasters

• Lançamento: CD-ROM Treinamento Aplicado de SQL - Lançamento! Treinamento Aplicado de SQL - Aprenda a trabalhar com SQL com bancos de dados Oracle e SQL Server. São mais de 100 tópicos explicados por Mauro Pichilliani, um articulistas mais lidos do iMasters. Aproveite! Apenas R$ 69,90 no TI SHOP.
• Lançamento: Livro iMasters "O Encontro de 2 Mundos"- Este livro conta com 56 crônicas de profissionais mais admirados e influentes do mercado brasileiro de Internet. Aproveite o preço especial para leitores do iMasters. Apenas R$ 40,00 e envio imediato!
• DVD Curso Completo de Photoshop - Do conceito à finalização Lançamento! Curso Completo de Photoshop, em DVD, com mais de 230 aulas dividas em 4 módulos: conceito, básico, avançado e finalização. Apenas R$ 69,50 no TI SHOP - Frete com 50% de desconto
• DVD Javascript Starter - Curso Completo Com mais de 9 horas de vídeo-aulas, é um curso completo sobre Javascript. Ideal para quem deseja aprender a linguagem. Apenas R$ 64,90 no TI SHOP - Frete com 50% de desconto!