Qualquer SGBD (Sistema Gerenciador de Bancos de Dados Relacional) entende apenas uma linguagem: SQL (Structured Query Language) ou linguagem de consulta estruturada. CREATE, DELETE, UPDATE e SELECT são apenas alguns dos comandos mais utilizados nesta linguagem, mas não está no escopo do nosso artigo, ensinar SQL e sim apresentar-lhe o SQL INJECTION.
uma das mais formas mais comuns e efetivas de ataque na internet é o SQL Injection. No SQL Injection, um hacker tenta enviar códigos SQL via consultas SQL não autorizadas e filtradas. O código SQL do hacker pode não ter nenhum retorno em termos de informações de segurança ou simplesmente executar um processo de destruição absoluta.
Existem precauções básicas que você deve tomar, para proteger os dados que serão recebidos através de formulários, principalmente se foi você quem o desenvolveu. A regra básica é tratar e validar os dados que serão recebidos e se assegurar que o seu código nunca irá recber os dados de uma forma bruta, ou seja, sem o devido tratamento.
Você pode tratar os dados de várias formas, desde limite de caracteres aceitos com maxlenght e size até scripts em javascript, para fazer a validação a nível cliente e scripts PHP, para validação a nível provedor.
Todos os dados enviados, devem ser processados e validados antes de serem utilizados pela aplicação.
Campos de texto em formulário sem filtragem
por exemplo, um formulário HTML podem aceitar um campo para um nome. Enquanto um usuário normal iria simplesmente digitar o seu nome no campo de texto do formulário, o hacker injeta código SQL para tentar executar uma consulta não autorizada ao banco de dados. Se no código do script PHP que vai receber os dados do formulário você setou a variável $name do tipo Get ou Post nome, que é o campo do formulário, a consulta normal ao banco de dados seria algo isto: $sql="Select * FROM jos_users WHERE name =' " . $name. " ';";
o hacker então digitaria algo parecido com o que segue: dummytext ' OR ' a ' = ' a
o código SQL gerador a partir desta injeção seria algo parecido com isto: select * FROM jos_users WHERE name = 'dummytext' OR ' a ' = ' a ' ;
quando a consulta enviada pelo hacker é executada, o teste ' a ' = ' a ' retornaria um valor real para cada linha e a consulta apresentaria a lista de todos os usuários existentes na tabela jos_users! O mais assustador é que qualquer código SQL válido, ou seja, sem erro de sintaxe, pode ser injetado, como mostrado no código a seguir: dummytext ' ; DROP table jos_users; SELECT * FROM jos_poll where title = '
o código acima iria destruir completamente a tabela de usuários do Joomla. Uma rotina simples de tratamento e validação do campo de texto do formulário, permitiria eliminar qualquer perigo de um ataque deste tipo.
Manuseando campos de texto em Joomla e PHP
Joomla inclui rotinas para gerar caracteres de escape para quaisquer caracteres (string) que não podem ser armazenados adequadamente dentro de um banco de dados. Por exemplo, a plica ( ' ) não pode ser armazenada na declaração SQL padrão de inserção sem modificação. Portanto, uma sequência de caracteres de escape com barra invertida ( \ ) permite a inclusão de caracteres especiais no MySql. Assim, uma barra invertida seguida pela citação ( \ " ) seria o único meio de armazenar os dados no campo do banco de dados. A seqüência de caracteres de escape fornecidos pelo próprio sistema invalida o ataque via injection, porque os caracteres digitados pelo hacker não serão entendidos pelo sistema como um comando SQL, será apenas um caracter literal comum a ser armazenado no banco de dados.
O provável resultado dessa consulta seria o retorno de um erro, uma vez que não existem registros correspondentes a esse valor seria encontrado.Para o código PHP, você pode usar um banco de dados específicos de cada método para gerar uma string que cria códigos para escapar de caracteres especiais. Para o MySQL, PHP inclui a função mysql_real_escape_string ()
O uso da função fica parecido com isto: $name = mysql_real_escape_string($name);
joomla fornece um método getEscaped () que irá retornar a string independentemente de sequência de escape de caracteres. Embora Joomla atualmente só suporta MySQL (previsto suportar ORACLE a partir da versão 6), você pode obter com o objeto JDatabase, a string que escapou e seria algo parecido com isto:
$db =& Jfactory::getDBO();
$name = $db->getEscaped($name) ;
Voltando aos ataques, no primeiro exemplo de ataque via SQL Injection, com os caratceres de escape, teríamos a seguinte seqüência inofensiva:
dummytext \ ' or \'a \ ' = \' a
O segundo exemplo ficaria assim:
dummytext\' ; Drop Table jos_users; select * from jos_polls where title = \ 'Existe uma diretiva do PHP conhecida como "magic quotes", que irá adicionar automaticamente barras para todos os campos recebidos de fonte externa (como um navegador da web). Na versão 6 do PHP, esta diretiva foi eliminada.
Portanto, é melhor ficar atento(a) aos códigos, principalmente de extensões de terceiros, para que seja executado de forma segura e caso esteja hospedando o Joomla em servidores com PHP 4.x (a maioria dos baratinhos ainda utilizada esta versão antiga do PHP) verifique a magiq quotes. ELA DEVE ESTAR LIGADA, ou seja, magiq_quotes = ON
Tipos não esperados
outra forma de ataque via SQL Injection pode ocorrer quando valores não esperados, (string, float, e assim por diante) são digitados e passados diretamente para a consulta SQL. Por exemplo, um valor de id obtido a partir de uma consulta ao banco de dados executada diretamente em linha de comando como esta:
$sql = " select * from jos_users where id = " . $id . "; " ;
o mesmo tipo de SQL Injection poderia ser utilizado com o id recuperado, se não for tratado com os caracteres de escape:
1; Drop table jos_users;
portanto, quando você aceitar valores de uma consulta ou formulário de envio, certifique-se de escrevê-los através do php. Por exemplo, para escrever o $id em um valor inteiro (Integer), você poderia utilizar o seguinte código PHP:
$id= intval($id);
digitando este código, qualquer tipo de Sql Injection, será automaticamente eliminado, ou irá gerar um erro quando o código encontrar os caracteres inválidos.
Se você usar os métodos JRequest:: getVar () ou JRequest:: get (), nativos do Joomla para obter a sequência de dados enviados via formulário de consulta, você já está protegido. Estas funções fornecem um filtro seguro para todos os tipos de dados indefinidos ou não esperados. Entretanto, quaisquer dados obtidos fora dessas funções, devem ser tratados por você com caracteres de escape, sempre que possível.
.png){kind=logo}
