SQL Injection – breve explicação
Tenho tido muito tempo livre nestas férias, pelo que decidi aproveitá-lo devidamente a estudar programação. Tenho vários projectos importantes em mãos, que envolvem a utilização da linguagem PHP que já estudo há cerca de 6 meses e com a qual já estou minimamente familiarizado. Posso dizer que neste momento, podem pedir-me para fazer qualquer coisa nessa linguagem que eu, com mais ou menos estudo prévio, consigo fazê-lo.
Nas últimas semanas tenho estudado dois temas mais específicos da linguagem: Programação Orientada a Objectos e Segurança.
Hoje, venho falar-vos um pouco da segurança em PHP, nomeadamente de SQL Injection, um método muito falado mas também muito fracamente compreendido pelas massas. Ora, para muitos programadores, SQL Injection é uma daquelas coisas que todos sabem que é mau, mas o conhecimento do método não passa disso. Ouve-se muitas vezes a expressão vinda de técnicos de segurança e associa-se imediatamente a algo mau, mas nunca se sabe exactamente o que é, nem como se evitar.
Este artigo tem, portanto, um objectivo duplo:
- ensinar como identificar uma vulnerabilidade que pode ser aproveitada com métodos SQL Injection;
- ensinar como salvaguardar o vosso código contra ataques SQL Injection.
Como identificar uma vulnerabilidade SQL Injection?
Esta é, nos casos mais simples, uma tarefa realmente fácil. Sempre que o utilizador tiver que introduzir dados como um parâmetro numa consulta á base de dados, existe a possibilidade de SQL Injection. Como exemplo, vamos supor que a seguinte consulta é usada para verificar um nome de utilizador/password:
$query = “SELECT * FROM users WHERE utilizador=’{$_POST[’utilizador]}’ AND password=’{$_POST[’password’]}’”;
Normalmente, o programador assume que o utilizador, perante o formulário, introduziria o seu nome de utilizador e a password, mas é aqui que se situa o primeiro erro do programador: confiar nos utilizadores. Ora, se o utilizador em vez de introduzir o seu nome de utilizador e a password, introduzir parte de uma instrução de consulta? Quando se junta toda a instrução, esta seria executada como uma consulta vulgar. Por exemplo, imaginemos que o utilizador introduz “Rui” como nome de utilizador e ” ’OR 1=1′”(reparem nos single quotes) como password. A nossa consulta ficaria assim:
$query = “SELECT * FROM users WHERE utilizador=’Rui’ AND password=’’ OR 1=1″;
Isto retornaria todos os registos da base de dados, autorizando um cracker a ganhar acesso á nossa aplicação sem necessitar de qualquer nome de utilizador/password válidos.
Como salvaguardar o nosso código contra ataques SQL Injection?
Agora que compreendem como funciona um ataque via SQL Injection, como devem proteger as vossas aplicações de modo a evitá-los? Em PHP, é na verdade, muito simples. Basta passar os dados $_POST['utilizador'] e $_POST['password'] pela função mysql_real_escape_string() . O que esta função faz é “escapar” os caracteres especiais numa frase para usar numa consulta SQL, levando em conta o conjunto actual de caracteres (os singles quotes, por exemplo, como utilizamos na consulta acima). Usando o exemplo da consulta anterior, o modo correcto de a proteger minimamente contra SQL Injection seria este:
$query = sprintf(”SELECT * FROM users WHERE utilizador=’%s’ AND password=’%s’”,
mysql_real_escape_string($_POST[’utilizador’]),
mysql_real_escape_string($_POST[’password’]));
Como podem ver, proteger as vossas aplicações contra SQL Injection é bastante simples. Espero ter conseguido explicar-vos este pequeno processo devidamente. De qualquer modo, no caso de não terem compreendido algo, espero que questionem sem qualquer problema.
6 Comments »
Leave a Reply
-
Recent
- Morreu John W. Backus, com 82 anos
- Ruby on Rails – novo vício
- GLAT – Google Labs Aptitude Test
- Depois do wiki, o que se segue?
- SQL Injection – breve explicação
- O fim definitivo do ciclo?
- A escuridão do mês de Outubro – breve reflexão e análise
- Windows Vista criará 100 mil novos empregos? Naaaa….
- Upgrade SMF 1.1 RC2 para 1.1 RC3 – todo o processo…
- Criar documentação profissional com ferramentas em GNU/Linux
- Novas áreas de estudo
- Microsoft pondera comprar Yahoo?
-
Links
-
Archives
- March 2007 (3)
- February 2007 (1)
- December 2006 (1)
- November 2006 (2)
- September 2006 (2)
- June 2006 (2)
- May 2006 (3)
- January 2006 (1)
- December 2005 (8)
-
Categories
-
RSS
Entries RSS
Comments RSS
Boa explicação! Apesar de ainda não ter dado SQL a fundo um professor meu já me tinha alertado para esse facto e explicou o que poderia acontecer com uma consulta dessas. Nós, claro fomos testar logo com alguns sites…
Mas hoje em dia quase todos previnem isso.
É preciso ter muito cuidado com isso senão qualquer utilizador pode acede a dados confidenciais da empresa ou de outro utilizador.
Andava à procura disto à algum tempo e entretanto tinha-me esquecido
Muito bom artigo, pequeno, mas suficientemente claro. Obrigado
do Brasil, parabéns, gostei.
Muito bom esse esclarecimento sobre SQL Injection.
Gostaria de saber se existe algo similar para Java?
olá fiquei com uma duvida:
como utilizo mesmo o “mysql_real_escape_string()”???
e isso limpa mesmo todos os caracteres “especiais”/”perigosos”?
não deveria ser algo deste género:
$user = mysql_real_escape_string($_POST[’user’]);
$pass = mysql_real_escape_string($_POST[’password’]);
para que as variáveis que guardam a pass e o user serem limpas antes e só depois é que era verificado o login
não percebi para que a query antes e o sprintf
Cumprimentos , Rodrigo Graça
Sou estudante de informática no Brasil.Entendi que as instruções de SQL Injection são por meio do preenchimento do campo onde se coloca a password?Essa era a minha dúvida.A port de entrada para introduzir o SQL Injection.