SQL Injection em m�ltiplas plataformas

SQL Injection

SQL Injection � uma t�cnica em que usu�rios maliciosos podem injetar comandos SQL em um procedimento SQL atrav�s da entrada de dados em uma p�gina web. Esses comandos SQL injetados alteram um SQL j� existente e que deveria processar uma requisiç�o pr�-definida. Esse SQL que pode ser injetado compromete severamente a segurança de uma aplicaç�o web.

Assim sendo, o ataque de Injeç�o de SQL (SQL Injection) consiste de inserç�es diretas de c�digo nos campos de entrada de dados que ser�o concatenados com comandos SQL e posteriormente executados. A alteraç�o direta de comandos SQL pode expor dados escondidos, sobrescrever dados valiosos, ou ainda executar comandos de sistema perigosos no servidor. No entanto, isso tudo � poss�vel se a aplicaç�o receber dados da entrada do usu�rio e combinar com par�metros est�ticos para montar a consulta SQL.

Os ataques de Injeç�o de SQL s�o divididos em tr�s categorias:

O primeiro deles � aquele em que um atacante pode simplesmente entrar com uma string maliciosa e causar a execuç�o imediata do c�digo;
O segundo tipo de ataque � aquele em que um atacante insere dados no armazenamento persistente, que � considerado como uma fonte confi�vel. Um ataque � posteriormente executado por outra atividade.
O terceiro tipo de ataque � aquele em que o atacante pode manipular a funç�o impl�cita To_Char() alterando os valor das vari�veis de ambiente, NLS_Date_Format ou NLS_Numeric_Characters.

O primeiro deles � o tipo de ataque mais comumente realizado pelos atacantes.

As principais consequ�ncias relacionadas � segurança s�o:

Confidencialidade: Como as bases de dados SQL possuem informaç�es sens�veis, a perda de confidencialidade � um problema frequente com vulnerabilidades de Injeç�o de SQL;
Autenticaç�o: Se um comando SQL � usado para verificar nomes de usu�rio e senhas, pode ser poss�vel se conectar ao sistema como outro usu�rio sem conhecimento pr�vio da senha;
Autorizaç�o: Se as informaç�es de autorizaç�o est�o num banco de dados SQL, pode ser poss�vel alterar essas informaç�es por meio da exploraç�o bem-sucedida de uma vulnerabilidade de SQL Injection;
Integridade: Assim como pode ser poss�vel ler informaç�es sens�veis, tamb�m � poss�vel fazer alteraç�es ou mesmo excluir essas informaç�es com um ataque de SQL Injection.

A melhor forma de verificar se a aplicaç�o est� vulner�vel a ataques de Injeç�o de SQL � verificando os passos que os atacantes utilizam para explorar a vulnerabilidade. Normalmente um atacante inicia seu trabalho a partir da an�lise de alguns pontos espec�ficos do aplicativo, s�o eles:

Realizar uma inspeç�o nos formul�rios e pontos de entrada de dados do aplicativo que aparentemente n�o estejam filtrando o uso de meta-caracteres, ou seja, c�digos de erro e mensagem de falha;
Realizar testes para construç�o de pedidos SQL de maneira a contornar eventuais mecanismos de proteç�o de uso de meta-caracteres. Por exemplo, a utilizaç�o de meta-caracteres que sejam interpretados como coment�rios, como � o caso da sequ�ncia ��, � frequentemente empregada nos ataques de injeç�o SQL, isso faz com que o restante do c�digo seja ignorado.
Combinar o ataque com a utilizaç�o de stored procedures para esconder a injeç�o de meta-caracters;

As aplicaç�es de m�dio e grande porte costumam utilizar bancos de dados para incluir informaç�es sens�veis como: credenciais de acesso dos usu�rios, informaç�es pessoais, cat�logo completo e hist�rico de produtos e serviços, pedidos, extratos de conta corrente e informaç�es sobre pagamentos, lista de clientes e de fornecedores, entre outras informaç�es.

Normalmente quando usamos SQL (Structured Query Language) para exibir informaç�es na p�gina web ou processar dados � comum permitirmos que os usu�rios insiram valores para realizarmos uma pesquisa ou processamento. Isso permite uma filtragem melhor dos dados que realmente interessam ao usu�rio e permite armazenar informaç�es.

Visto que comandos SQL nada mais s�o do que textos, � muito simples alterarmos esses comandos SQL com um pouco de c�digo para permitir ao usu�rio visualizar a informaç�o selecionada como mostra o c�digo da Listagem 1.:

Listagem 1. Selecionando os dados de um usu�rio espec�fico.


  txtIdUsuario = getRequestString("idUsuario");
  txtSQL = "SELECT * FROM Usuarios WHERE idUsuario = " + txtIdUsuario;

No c�digo mostrado acima criamos um comando SELECT adicionando uma vari�vel (txtIdUsuario) para selecionar um valor atribu�do a string. Essa vari�vel � obtida a partir da entrada do usu�rio na p�gina. Essa entrada pode ser um perigo potencial que pode ocasionar a Injeç�o de SQL que por sua vez pode destruir com uma base de dados.

A maioria das vulnerabilidades e dos problemas de segurança s�o originados por falta de atenç�o quanto � segurança no momento da programaç�o. No restante do artigo analisaremos a Injeç�o de SQL ou SQL Injection.

Quer se aprofundar mais na linguagem SQL? Confira os cursos de SQL e banco de dados da DevMedia.

Exemplos de Ataques de Injeç�o de SQL

Um exemplo de Injeç�o de SQL � no comando "1=1". Por exemplo, digamos que um SQL inicialmente deveria selecionar um usu�rio com um determinado id. Por�m, um atacante malicioso entra com a seguinte entrada no input da p�gina: "105 or 1=1".

Nesse caso ter�amos o seguinte SQL: "SELECT * FROM Usuarios WHERE idUsuario = 105 or 1=1".

Podemos verificar que esse SQL � v�lido e retornar� todas as linhas de uma tabela "Usuarios", visto que 1=1 � sempre verdadeiro e, portanto todas as linhas s�o verdadeiras e ser�o retornadas.

Aparentemente podemos pensar que n�o h� maiores problemas listarmos os usu�rios de uma tabela, mas e se essa tabela cont�m senhas, nomes, cpf e outros dados confidenciais? O problema torna-se mais grave e perigoso.

Outro ataque de Injeç�o SQL bastante comum � o baseado no ""="" que tamb�m sempre � verdadeiro para cada linha de uma tabela. Por exemplo, imaginamos dois campos de entrada numa p�gina web solicitando "Nome de Usu�rio" e "Senha". Nesse caso, ter�amos o seguinte SQL: "SELECT * FROM Usuarios WHERE Nome ="" + nome + "" AND Senha ="" + senha + """

Um hacker poderia ter acesso a todos os nomes de usu�rios e senhas em uma base de dados apenas inserindo "" ou ""="" dentro do campo de nome de usu�rio ou senha.

Com isso teremos um SQL v�lido que resultar� no comando SELECT * FROM Usuarios WHERE Nome ="" or ""="" AND Senha ="" or ""="" e como resultado teremos todas as linha de uma tabela Usuarios, visto que ""="" � sempre verdadeiro.

Outro ataque de Injeç�o de SQL comum s�o os comandos SQL em lote que � suportado pela maioria das bases de dados. Nesse caso os comandos s�o separados por ponto e v�rgula, como mostra o exemplo da Listagem 2.

Listagem 2. Comandos SQL executados em lote.

SELECT * FROM Usuarios; DROP TABLE Fornecedores

O comando acima retornar� todas as linhas na tabela Usuarios e ent�o apagar� a tabela Fornecedores.

Podemos imaginar o seguinte comando SQL da Listagem 3.

Listagem 3. Selecionando um usu�rio dado o id.

�SELECT * FROM Usuarios WHERE idUsuario = " + txtIdUsuario;

E a seguinte entrada fornecida no campo de texto da p�gina web:

105; DROP TABLE Fornecedores

O c�digo resultante ser� igual ao da Listagem 4.

Listagem 4. C�digo SQL resultante ap�s a entrada do usu�rio no campo de entrada.

SELECT * FROM Usuarios WHERE idUsuario = 105; DROP TABLE Fornecedores

Esse SQL � v�lido e ser� processado.

Uma forma bastante comum de ataque de Injeç�o de SQL ocorre nos bancos de dados MSSQL Server onde o atacante envia o valor a%" exec master..xp_cmdshell "net user test testpass /ADD" -- para uma vari�vel que espera uma entrada. Por exemplo, dado o c�digo PHP da Listagem 5 que utiliza uma base de dados MSSQL Server.

Listagem 5. C�digo PHP que espera uma entrada na vari�vel $prod e lista o produto.


  <?php
  $query  = "SELECT * FROM products WHERE id LIKE "%$prod%"";
  $result = mssql_query($query);
  ?>

Podemos imaginar que o atacante envie o valor a%" exec master..xp_cmdshell "net user test testpass /ADD" � para a vari�vel $prod, assim ter�amos o SQL resultante da Listagem 6.

Listagem 6. C�digo resultante ap�s concatenar com a entrada do usu�rio.


  <?php
  $query  = "SELECT * FROM products
                      WHERE id LIKE "%a%"
                      exec master..xp_cmdshell "net user test testpass /ADD"--";
  $result = mssql_query($query);
  ?>

Ap�s receber o comando acima o Microsoft SQL Server executa os comandos SQL em lote com um comando para adicionar um novo usu�rio para o banco de dados de contas locais. Se essa aplicaç�o estiver sendo executada como �as� e o serviço �MSSQLSERVER� estiver sendo executado com privil�gios suficientes, o atacante teria agora uma conta com a qual poderia acessar essa m�quina, ocasionando um enorme perigo � base de dados.

No banco de dados PostgreSQL tamb�m existe uma forma bem comum utilizada pelos atacantes de Injeç�o de SQL em que se criam super-usu�rios diretamente no banco. Por exemplo, podemos imaginar o c�digo da Listagem 7.

Listagem 7. C�digo que lista os produtos e espera uma entrada para vari�vel $offset.


  <?php
  $offset = $argv[0]; 
  $query  = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
  $result = pg_query($conn, $query);
  ?>

Os usu�rios clicam nos links �pr�xima� e �anterior� ou ent�o em setas que movem para a pr�xima p�gina ou para a p�gina anterior. Podemos verificar que a vari�vel $offset � codificada na URL. O script espera que o valor de $offset seja um n�mero decimal. No entanto, atacantes de Injeç�o de SQL tentam invadir acrescentando a forma codificada por urlencode() como mostrado na Listagem 8.

Listagem 8. Entrada realizada pelo atacante.


  0;
  insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
      select "crack", usesysid, "t","t","crack"
      from pg_shadow where usename="postgres";
  --

Com isso, o script forneceria de presente ao atacante acesso de super-usu�rio. Podemos verificar que 0; � para fornecer um deslocamento v�lido para a consulta original e termin�-la, assim ap�s isso o atacante insere o restante do comando SQL que lhe fornece acesso de super-usu�rio ao banco de dados PostgreSQL.

No final do comando ainda podemos verificar a presença de um "--". Isto � um sinal de coment�rio que força o SQL a ignorar o resto da consulta escrito pelo desenvolvedor.

N�o s�o apenas comandos SELECT que s�o suscet�veis a ataques de Injeç�o de SQL, os comandos UPDATE tamb�m tem um risco potencial. Os comandos UPDATE tamb�m s�o ameaçados por cortes e acr�scimos de uma nova consulta. Al�m disso, o atacante poder usar a cl�usula SET, mas neste caso ele precisa ter conhecimento sobre o esquema para poder manipular a consulta com sucesso. Para conseguir informaç�es sobre o esquema o atacante poderia examinar os nomes das vari�veis do formul�rio, ou simplesmente tentar por força bruta. Por exemplo, podemos verificar o c�digo da Listagem 9.

Listagem 9. C�digo em PHP aguardando uma entrada nas vari�veis $pwd e $uid.


  <?php
  $query = "UPDATE usertable SET pwd="$pwd" WHERE uid="$uid";";
  ?>

Agora podemos imaginar que um atacante envie o valor " or uid like"%admin%"; -- para a vari�vel $uid para alterar a senha do administrador, ou ainda simplesmente configura $pwd para "qlqrcoisa", admin="yes", trusted=100 " (com um espaço sobrando) para ganhar mais privil�gios. Dessa forma, ter�amos o c�digo resultante na Listagem 10.

Listagem 10. C�digo resultante ap�s a entrada de dados fornecida pelo atacante.


  <?php
  // $uid == " or uid like"%admin%"; --
  $query = "UPDATE usertable SET pwd="..." WHERE uid="" or uid like "%admin%"; --";
   
  // $pwd == " qlqrcoisa", admin="yes", trusted=100 "
  $query = "UPDATE usertable SET pwd="qlqrcoisa", admin="yes", trusted=100 WHERE
  ...;";
  ?>

Prevenindo SQL Injection

Os desenvolvedores costumam usar uma "blacklist" de palavras ou caracteres para pesquisar por uma entrada SQL, para prevenir ataques de Injeç�o de SQL. Essa n�o � uma ideia muito interessante, visto que muitas dessas palavras como delete ou drop al�m de caracteres como ";" e " s�o usados comumente e poderiam ser permitidos em algumas entradas.

Saiba mais sobre SQL Injection nesse artigo da GURU99 (conte�do em ingl�s).

A melhor forma de proteger os web sites de ataques de SQL Injection � usar par�metros SQL. Os par�metros SQL s�o valores que s�o adicionados em uma consulta SQL em tempo de execuç�o e de uma forma controlada.

Por exemplo, em ASP.NET as entradas s�o tratadas da mesma forma que a apresentada na Listagem 11.

Listagem 11. Utilizando par�metros para tratar os comandos SQL.


  txtIdUsuario = getRequestString("idUsuario");
  txtSQL = "SELECT * FROM Usuarios WHERE idUsuario = @0";
  db.Execute(txtSQL, txtIdUsuario);

Os par�metros s�o tratados por um marcador "@" como mostra o exemplo na Listagem 12 abaixo.

Listagem 12. Outro exemplo utilizando procedimento SQL para tratar os comandos SQL.


  txtNom = getRequestString("NomeCliente");
  txtEnd = getRequestString("Endereco");
  txtCid = getRequestString("Cidade");
  txtSQL = "INSERT INTO Clientes (NomeCliente, Endereco, Cidade) Values(@0,@1,@2)";
  db.Execute(txtSQL, txtNom, txtEnd, txtCid);

Em PHP podemos fazer da mesma forma que a apresentada na Listagem 13.

Listagem 13. Utilizando par�metros para tratar os comandos SQL.


  $stmt = $dbh->prepare("INSERT INTO Customers (NomeCliente, Endereco, Cidade)
  VALUES (:nom, :end, :cid)");
  $stmt->bindParam(":nom", $txtNom);
  $stmt->bindParam(":end, $txtEnd);
  $stmt->bindParam(":cid", $txtCid);
  $stmt->execute();

Em Java utilizamos Prepared Statements conforme mostra a Listagem 14.

Listagem 14. Utilizando Prepared Statements para tratar os comandos SQL.


  String selectStatement = "SELECT * FROM Usuarios WHERE idUsuario = ? ";
  PreparedStatement prepStmt = con.prepareStatement(selectStatement);
  prepStmt.setString(1, idUsuario);
  ResultSet rs = prepStmt.executeQuery();

Uma forma incorreta utilizada em Java e que deve ser evitada � mostrado na Listagem 15.

Listagem 15. Tratando incorretamente consultas SQL


  String sql = "select * from usuarios where username="" + username +"" and senha="" + senha + """;
  stmt = conn.createStatement();
  rs = stmt.executeQuery(sql);

Outras linguagens t�m suas formas de realizar o mesmo procedimento.

Utilizando essa forma a engine do SQL checa cada um dos par�metros para assegurar que eles est�o corretos para as suas respectivas colunas e eles s�o tratados literalmente, e n�o como uma parte do SQL a ser executado.

Outra forma de evitar ataque de Injeç�o de SQL � validar todas as entradas testando o tipo, tamanho, formato, intervalo, etc. Devemos tamb�m validar documentos XML, usar Stored Procedures para validar entradas do usu�rio, nunca usar comandos Transact-SQL diretamente da entrada do usu�rio, implementar m�ltiplas camadas de validaç�o na aplicaç�o e n�o somente na primeira camada e nunca concatenar entradas do usu�rio.

Uma forma simples de proteger contra ataques de injeç�o de SQL � utilizando cl�usulas LIKE onde caracteres "curinga" devem ser ignorados, conforme mostrado no c�digo da Listagem 16.:

Listagem 16. Escapando caracteres especiais usando a cl�usula LIKE.


  s = s.Replace("[", "[[]");
  s = s.Replace("%", "[%]");
  s = s.Replace("_", "[_]");

Revisar o c�digo � sempre algo bastante indicado procurando por poss�veis vulnerabilidades de Injeç�o de SQL. Uma forma de fazer essa busca � procurar por palavras-chaves como chamadas a EXECUTE, EXEC, ou sp_executesql no caso de utilizarmos o SQL Server.

Algumas dicas que devem ser consideradas s�o: termos bastante cuidado com pacotes prontos disponibilizados na comunidade open source, um atacante poderia adquirir uma c�pia do c�digo e acessar dados importantes da base de dados, como informaç�es do esquema. Tamb�m nunca devemos confiar em nenhum tipo de entrada, especialmente as entradas do lado do cliente, cuidando at� mesmo combos (combobox), campos hidden ou cookies. Outras dicas importantes s�o:

Nunca conectar ao banco de dados como super-usu�rio ou como o dono do banco de dados. Devemos sempre usar usu�rios personalizados com privil�gios limitados.
Sempre verificar se uma entrada qualquer tem o tipo de dados esperado. As linguagens normalmente oferecem funç�es prontas que j� fazem esse tipo de verificaç�o. No PHP temos, por exemplo, as funç�es is_numeric(), ctype_digit(), entre outras. O PHP tamb�m oferece filtros que podem ser utilizados para entradas n�o confi�veis. Mais informaç�es podem ser encontradas em http://us.php.net/manual/en/intro.filter.php.
Devemos adicionar aspas para cada valor n�o num�rico especificado pelo usu�rio que ser� passado para o banco de dados com as funç�es de caracteres de escape, como por exemplo, as funç�es mysql_real_escape_string(), sqlite_escape_string(), entre outras dispon�veis pelo PHP.
Nunca devemos imprimir qualquer informaç�o espec�fica do banco de dados, especialmente sobre o esquema.
Podemos usar stored procedures e cursores previamente definidos para abstrair acesso aos dados para que os usu�rios n�o acessem tabelas ou views diretamente, mas essa soluç�o pode ter outros impactos e deve ser bem analisada previamente.

Al�m disso, � interessante registrarmos as consultas e operaç�es do banco de dados. Este relat�rio � interessante para que possamos rastrear qual aplicaç�o foi atacada. O relat�rio n�o � �til em si, mas atrav�s da informaç�o que ele cont�m.

Neste artigo vimos que o ataque de Injeç�o de SQL � bastante comum e pode provocar danos enormes, visto que eles atacam a Confidencialidade, Autenticaç�o, Autorizaç�o e a Integridade. O ataque de Injeç�o de SQL pode ocorrer em qualquer plataforma que prov� suporte � linguagem SQL, inclusive em outros pontos de uma aplicaç�o web como par�metros cookies, al�m das solicitaç�es http GET e http POST. O ataque � realizado atrav�s de caracteres inseridos na entrada de dados para ent�o ser inseridos no comando SQL que ser� executado posteriormente numa base de dados. Algumas das melhores pr�ticas para evitar Injeç�o de SQL s�o atrav�s de parametrizaç�o das consultas, usar "stored procedures", escapar toda entrada fornecida pelo usu�rio e limitar privil�gios aos acessos.

SQL Injection em m�ltiplas plataformas

Veja neste artigo o que é e como é originado o ataque de SQL Injection em diferentes tecnologias e banco de dados. Aprenda também a prevenir ataques de SQL Injection.

SQL Injection

Exemplos de Ataques de Injeç�o de SQL

Prevenindo SQL Injection

Bibliografia

Artigos relacionados