SQL Injection em Ambientes WEB

Entendendo o SQL Injection

Segundo Duarte (2007), nas �ltimas d�cadas observou-se um aumento expressivo no desenvolvimento de tecnologias computacionais. Entretanto, toda esta evoluç�o � acompanhada por um n�mero crescente de sistemas sendo sondados, invadidos, infectados, comprometidos e utilizados para gerar ataques a outros sistemas. Todos estes problemas de segurança fazem parte do cotidiano de instituiç�es, e de usu�rios dom�sticos. Desta forma, observa-se que a segurança � um aspecto muito importante, seja para o desenvolvimento desktop ou para o ambiente web.

Em um mercado onde requisitos mudam constantemente e o fator produtividade � sempre primordial, alguns aspectos acabam sendo desconsiderados, sendo a segurança um requisito quase sempre esquecido ou colocado em segundo plano. No entanto, as conseq��ncias geradas por esta pr�tica quase sempre s�o desastrosas quando as aplicaç�es entram em produç�o.

Relacionado: Update Triggers: Como proteger tabelas de SQL Injection

Em se tratando de aplicaç�es web, a segurança � um fator de grande import�ncia, j� que a aplicaç�o fica dispon�vel em qualquer parte do mundo e pass�vel de manipulaç�o pelos mais diversos usu�rios, al�m de tamb�m estar pass�vel aos mais diversos ataques.

Os ataques est�o cada vez mais sofisticados e sempre se aproveitando do grande n�mero de falhas presentes nas aplicaç�es. Podem ser destacados alguns tipos de ataques como: url manipulation, web session hijaking e SQL injection.

Motivados pela observaç�o do grande n�mero de sites em produç�o que possuem falhas em relaç�o a segurança, este artigo ter� como foco os ataques do tipo SQL injection, visto a sua simplicidade e em contrapartida os grandes problemas que o mesmo pode trazer.

SQL Injection

Em um cen�rio onde existem informaç�es armazenadas em bancos de dados e que podem ser acessados via web, tem-se a possibilidade do ataque do tipo SQL injection. SQL injection � um tipo de ataque muito simples, que baseia-se na execuç�o de comandos SQL, sejam comandos de manipulaç�o de dados - DML (select, insert, update, delete) ou comandos de definiç�o de dados - DDL (create, drop, alter). Estes comandos s�o executados atrav�s das entradas de formul�rios web, ou seja, no local destinado para digitaç�o de informaç�es pelo usu�rio, onde s�o passados comandos SQL, que por falhas nas aplicaç�es acabam por resultar em alteraç�es no banco de dados ou no acesso indevido � aplicaç�o.

A figura 1 apresenta um exemplo cl�ssico de tal pr�tica numa tela de autenticaç�o:

Figura 1 - Exemplo SQL injection

O problema ocorre devido a autenticaç�o do usu�rio ser validada internamente pela aplicaç�o com a seguinte instruç�o, que verifica se existe um usu�rio com o respectivo login e senha:


  SELECT * FROM tabela_usuarios WHERE login = 'campo_login' AND senha = 'campo_senha'

Normalmente, seriam digitados o login e a senha, que resultaria em uma consulta ao banco de dados para verificar se os mesmos conferem mas na figura acima foi passado parte de um comando SQL no campo reservado para senha, que internamente resultar� na seguinte instruç�o:


  SELECT * FROM tabela_usuarios WHERE login = '123' AND senha = ' ' or '1' = '1'

Observe que o comando passado no campo da senha fez com que independente do login e senha informados, a condiç�o seja sempre verdadeira, permitindo assim o acesso do usu�rio � aplicaç�o sem o mesmo possuir a devida permiss�o.

Existem diversas possibilidades de comandos que podem ser executados indevidamente atrav�s da passagem de par�metros, onde alguns exemplos podem ser observados na tabela 1:

SQL esperado	Parâmetros informados		SQL resultante	Comantário
SQL esperado	Campo_login	Campo_senha	SQL resultante	Comantário
SELECT * FROM tabela_usuarios WHERE login = 'campo_login' AND senha = 'campo_senha'	marcos’;--		SELECT * FROM tabela_usuarios WHERE login = 'marcos';--' AND senha = 'campo_senha'	Se o usuário já souber o login (no caso, login do usuário marcos) então consegue logar sem senha, já que os caracteres “--“ são comentários no SQL
	' OR 1=1 --		SELECT * FROM tabela_usuarios WHERE login = '' OR 1=1--' AND senha = 'campo_senha'	Neste caso, não é necessário saber nem o login nem a senha, pois a condição “OR 1=1” sempre vai ser satisfeita e todos os comandos posteriores são comentados pelos carecteres “--”
	123'; DROP TABLE produtos; --		SELECT * FROM tabela_usuarios WHERE login = '123'; DROP TABLE produtos;-- ' AND senha = 'campo_senha'	Este caso é muito parecido com o primeiro mas um comando para apagar uma tabela é executado antes do comentário. Na verdade aqui o objetivo era somente apagar a tabela, por isso foi passado um login qualquer.

Apesar desse tipo de ataque poder ocasionar grandes danos ao banco de dados, ele pode ser evitado apenas com boas pr�ticas de programaç�o, independente da linguagem. Em seguida ser�o abordadas formas de prevenç�o na linguagem PHP e JAVA.

Prevenç�o do SQL Injection na linguagem PHP

De acordo com Alves (2007), para se proteger 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.

Ainda de acordo com o mesmo autor, 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 validados e tratados 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 (ALVES, 2007):


  $usuario = $_POST['usuario'];$senha = $_POST['senha'];$usuario_escape = addslashes($usuario);$senha_escape = addslashes($senha);$query_string = "SELECT * FROM usuarios WHERE codigo = '{$usuario_escape}' AND senha = '{$senha_escape}'";?>

Atrav�s 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:


SELECT * FROM usuarios WHERE codigo = '' AND senha = '\' or 1=\'1'

Deve-se tamb�m evitar a exibiç�o das mensagens 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.

Prevenç�o do SQL Injection na linguagem JAVA

Quando uma aplicaç�o JAVA usa consultas �Statement�, ou seja, consultas onde a string SQL � concatenada com os par�metros e assim executada, ela provavelmente ter� problemas com SQL injection. Como ocorre no trecho de c�digo a seguir:


String sql = "select * from tabela_usuarios where login='" + campo_login +"' and senha='" + campo_senha + "'";

Statement stmt = con.createStatement();

ResultSet rs = stmt.executeQuery(sql);

if (rs.next())

  System.out.println("Usu�rio Logado com sucesso.");

else

  System.out.println("Usu�rio ou Senha n�o conferem.");

De acordo com a OWASP (2008), uma forma simples do SQL injection ser evitado, quando � utilizada a linguagem JAVA, � realizar a validaç�o das entradas, de forma que sejam evitados caracteres que n�o façam parte do conjunto de caracteres das entradas (inputs) e utilizar consultas �Prepared Statement�, ou seja, os par�metros n�o s�o concatenados, a string SQL define par�metros:


  String sql = "SELECT * FROM tabela_usuarios WHERE login = ? AND senha = ?";

PreparedStatement prepStmt = con.prepareStatement(sql);

prepStmt.setString(1,login);

prepStmt.setString(2,senha);

ResultSet rs = prepStmt.executeQuery();

Assim, vari�veis passadas como prepared statement far�o o escape automaticamente, da mesma forma como exposto na linguagem PHP.

Consideraç�es Finais

Sistemas Desktop e Web ainda permanecem como alvos vulner�veis, apesar da disponibilidade de ferramentas e de procedimentos que dificultam a ocorr�ncia de ataques. A fragilidade desses sistemas muitas vezes � potencializada pelo desconhecimento que os programadores possuem sobre a programaç�o segura e tamb�m sobre os cen�rios nos quais esses ataques ocorreram e foram bem sucedidos.

Assim, este trabalho apresentou alguns procedimentos que visam auxiliar a construç�o de aplicaç�es seguras sob o ponto de vista dos ataques provocados pela SQL injection.

Links �teis

Saiba mais sobre SQL ;)

Guia SQL:
Neste Guia de Refer�ncia voc� encontrar� todo o conte�do que precisa para aprender sobre a SQL, linguagem de consulta estruturada utilizada por programadores e DBAs para a execuç�o de consultas e comandos nos principais SGBDs do mercado.
Trabalhando com a linguagem T-SQL:
Este artigo apresenta o uso da linguagem T-SQL. Ser�o discutidos alguns recursos que podem ser usados no desenvolvimento e manipulaç�o na consulta a dados usando a ferramenta SQL Server.
Conceitos e criaç�o de views no SQL Server:
Veja neste artigo como trabalhar com views no SQL Server, aprendendo como utilizar os comandos CREATE, ALTER e DROP VIEW.

SQL Injection em ambientes Web

Segurança é um aspecto que muitas vezes é deixado de lado em detrimento a outros, tornando na maioria das vezes um site vulnerável a sql injection.