Técnicas defensivas contra injeção de comandos

[Guybrush 0]

Técnicas defensivas contra injeção de comandos

 

31/1/2003 - 14:03 Nelson Murilo

 

Este é um artigo técnico do especialista em segurança Nelson Murilo, a respeito de causas e como se proteger de ataques chamados de SQL Injection. Para uma visão mais prática do que o problema pode acarretar, leia o texto Site do Ministério da Justiça foi invadido.

 

 

Serviços nos quais existe autenticação ou consulta, normalmente fazem integração com os bancos de dados e permitem interação do usuário através de páginas com formulários. Uma vez informados os campos do formulário, uma interface deve proceder uma conversão de linguagem, de forma a permitir o entendimento por parte do banco de dados utilizado. Servidores WEB entendem HTML (HyperText Markup Language), enquanto bancos de dados em geral utilizam SQL (Structured Query Language). Esta tradução deve limitar a busca (identificar se um usuário está ou não cadastrado, recuperar documentos, etc.) ao objeto da pesquisa, de forma a não permitir a execução de comandos arbitrários que comprometem a segurança das informações armazenadas, ou até mesmo o ambiente computacional local e de terceiros.

 

As técnicas de injeção de comandos podem variar desde uma simples geração de erros, que expõem aspectos do ambiente, até permitir o comprometimento completo do sistema. Não é demais lembrar que a despeito de cada fabricante adicionar funcionalidades proprietárias, a linguagem SQL ANSI é aceita incondicionalmente pela grande maioria dos fornecedores de bancos de dados, como: Oracle, SYBASE, MS SQL Server, DB2, Access, MySQL, entre outros. Portanto o risco da injeção de comandos não está restrito a um determinado fornecedor, muito pelo contrário, já que a quase totalidade das instalações mundiais fazem uso de um ou mais bancos citados acima.

 

Métodos e informações sobre os ataques

 

Ataques bem sucedidos utilizando injeção de comandos seguem, normalmente, os seguintes passos:

 

1 - Análise dos erros gerados pela aplicação em função de preenchimento dos campos com informações não esperadas;

 

2 - Manipulação dos campos de entrada de dados com objetivo de determinar a estrutura de esquemas, bases, tabelas e colunas;

 

3 - Determinar o comando ou comandos que permitirão ler ou manipular as informações de interesse;

 

4. Obter as informações propriamente ditas e verificar a possibilidade de obter informações ou executar comandos no servidor.

 

Atacantes podem se valer de particularidades de determinados bancos de dados como conta “scoth” ou “sys” do Oracle, ou “sa” do MS SQL Server, ou acessar bases específicas como o “master” ou “tempdb”, também existentes no MS SQL Server.

 

Usando uns poucos comandos, podem ser listadas bases, esquemas, tabelas e colunas. Em ambientes MS SQL Server poderia ser usada, por exemplo, a seqüência abaixo:

 

SELECT * FROM master..sysdatabases

USE database SELECT syscolumns.name,sysobjects.name FROM syscolumns,sysobjects WHERE sysobjects.xtype='U' and syscolumns.id = sysobjects.id

 

De posse destes dados é possível obter informações, incluir, excluir ou alterar dados da base.

 

Ainda que o perigo deste tipo de ataque ficasse restrito à manipulação de bases de dados, o risco já seria suficientemente alto. Porém, infelizmente, a injeção de comandos extrapola estes limites e pode, em alguns ambientes, permitir ao atacante obter informações do sistema, executar comandos arbitrários no servidor, invadir outros servidores da mesma rede e até usar o método como base para ataques a terceiros.

 

O exemplo abaixo utiliza uma chamada disponível em Sybase e MS SQL Server, que permite listar os arquivos de um determinado diretório do servidor:

 

master..xp_cmdshell 'dir c:\WINNT'

 

Deve ficar claro que, assim como ‘dir’ foi usado como exemplo para ambientes Windows, qualquer comando disponível no sistema operacional pode ser executado, seja ele Windows ou Unix. As únicas limitações são o nível de permissão do usuário e detalhes de implementação, em funcão do fabricante do banco de dados.

 

Estratégias de defesa

 

O principal ponto de filtragem de comandos não autorizados é a validação dos campos. Mas é preciso ter em mente qual o melhor local para fazer a validação do que foi digitado. Alguns projetistas fazem uso apenas de linguagens interpretadas pelo navegador, notadamente JavaScript, para validar as entradas. Não há dúvida que esta é uma estratégia util, mas se existir validação apenas neste ponto, um atacante pode facilmente desabilitar esta funcionalidade ou mesmo utilizar navegadores — Lynx por exemplo — que não interpretam JavaScript e outras linguagens assemelhadas.

 

De uma maneira geral, a chamada, assim como os nomes dos campos que irão formar o comando de consulta, está no código HTML, sendo assim, nada impede que o atacante monte o comando e passe diretamente ao programa que irá processar o formulário, via URL ou via POST.

 

Portanto, o ideal é montar as estratégias de defesa nos programas que efetivamente irão conversar com o banco de dados. Notadamente as linguagens utilizadas são ASP, VisualBasic, ColdFusion, Perl e PHP.

 

Alguns procedimentos simples podem evitar problemas, como, por exemplo, limitar o tamanho do campo do formulário. É util, mas não suficiente limitar apenas no código HTML:

 

<INPUT type="text" name="login" size=16> Login</INPUT>

 

É importante testar também após o formulário ser enviado. Na tabela abaixo estão funções para verificação do tamanho dos campos:

 

ASP: len(cadeia)

PERL: length cadeia;

PHP: Strlen($cadeia);

java script: document.write(cadeia.length)

 

Campos numéricos devem conter apenas algarismos. As rotinas que permitem remover qualquer outro caracter, para algumas linguagens, estão na tabela abaixo:

 

ColdFusion: REreplace (campo, “[^0-9]”, “”, “ALL”)

PERL: $campo =~ s/[^0-9]//g

PHP: ereg_replace (“[^0-9]”, “”, $campo)

 

Utilizando ASP existem pelo menos duas maneiras de retirar o que não for algarismo. A mais flexivel é, possivelmente, por meio da criação de uma função:

 

function ReplaceNum (MatchedString) { return “ “; }

var regex = /[0-9]/g;

campo = data.replace(regex, ReplaceNum);

 

A mesma idéia pode ser aplicada a outras necessidades, como campos que devam conter apenas letras minúsculas, campos alfanuméricos, etc.

 

O principal problema em ataques de injeção de comandos é em relação a caracteres especiais, notadamente plicas (‘), sinal de menos (-), ponto e virgula ( ;) e o asterisco (*). Porém, todas as regras para criação de senhas de difícil adivinhação apontam para uma mistura de letras (maiúsculas e minúsculas), números e caracteres especiais. Portanto é preciso avaliar corretamente quais campos devem conter determinados filtros e talvez impor alguns limites na criação de senhas e caracteres que podem ser utilizados em textos livres.

 

Usando a mesma idéia anterior é possível retirar plicas e outros caracteres suspeitos. Porém existem situações em que o tratamento campo a campo não é possivel. Neste caso uma maneira interessante de evitar a introdução de comandos arbitrários é manipular a quantidade de plicas (‘) e aspas (“) do comando. Desta forma, ficam sem efeito as tentativas de interromper ou adicionar elementos à linha de comando que irá acessar a base de dados SQL:

 

PERL: $cadeia =~s/[‘”]/’’/g;

PHP: ereg_replace(“’”, “’’”, $cadeia

ColdFusion: REReplace(cadeia, “’”, “’’”)

 

Considerações finais

 

Evitar a injeção de comandos SQL é uma pequena, mas importante, parte dos procedimentos de proteção necessários a um servidor Web e, de resto, à instalação como um todo. Existem medidas de segurança que mesmo focando a defesa contra injeção de comandos, podem beneficiar todo o ambiente, tais como:

 

● Enviar mensagens genéricas de erro, tratando nos programas as mensagens detalhadas vindas do ODBC e similares;

 

● Os dados numéricos devem ter tipos compatíveis. É muito comum encontrarmos colunas do tipo VARCHAR, quando deveriam ser do tipo INT;

 

● Limitação de privilégios. A conta utilizada para acessar o banco deve ter o menor nivel de privilégio possível. Jamais deve poder manipular informações além das necessárias. Em ambientes onde existe apenas uma consulta ao banco, via página, não há razões para esta conta ter poderes maiores que o de leitura;

 

● Jamais coloque senhas ou outras informações importantes em arquivos .INC. O conteúdo pode ser facilmente visualizado, e portanto, as informações lá contidas ficarão expostas. Na mesma linha, códigos HTML não devem conter informações sobre seus esquemas, nomes de bases, tabelas e colunas. Isso pode ser confundido com “segurança por obscuridade”, mas em segurança da informação existem vários níveis de confidencialidade, existem coisas que o usuário DEVE saber, algumas que ele PODE saber, outras que ele NÃO PRECISA saber (estamos neste caso) e ainda as que ele NÃO PODE saber. Evitar informar coisas que o usuário não precisa saber pode ser útil para evitar vários tipos de ataque, inclusive os de engenharia social.

 

● Bloquear acesso ao servidor SQL. Normamente necessitam ter acesso a servidores SQL apenas os responsáveis pela manutenção ou pelo desenvolvimento. Filtrar, nos firewalls e/ou roteadores o acesso externo e mesmo interno aos serviços SQL, que utilizam as portas 1433 e 1434 (TCP e UDP), pode evitar muitos problemas, inclusive ataques de Worms, como o SQL Slammer ou Sapphire.

 

Ao contrário do que normalmente ocorre, quando o administrador do sistema é o responsável por promover e manter medidas de segurança no seu ambiente, muito do trabalho para manter bases SQL seguras depende de conscientização do desenvolvedor, e deve começar no protótipo do sistema, pois os mecanismos de segurança devem ser incorporados ao desenvolvimento de forma transparente. Assim, não há desculpa para entregar um sistema sabidamente inseguro com a promessa de incluir estes mecanismos na versão final. Empresas que prometem ou aceitam este tipo de situação devem rever, urgentemente, seus procedimentos de segurança.

 

Nelson Murilo de Oliveira Rufino atua na área de segurança de redes desde 1992. É autor do livro Segurança Nacional - Técnicas e ferramentas de ataque e defesa. É diretor da empresa de segurança Pangéia Informática; administra o Centro de Tratamento e Resposta a Incidentes Computacionais do Departamento de Polícia Federal do Brasil; é membro do Grupo de Segurança (GTS) do Comitê Gestor da Internet/BR; ministra cursos de segurança há 9 anos e palestras em eventos nacionais e internacionais; entre outras atividades.

 

Quem Tiver Artigos posta ae!

[Mário Monteiro 179]

Movido de ASP para Área para Tutoriais (ASP)acho mais adequado este local

[micox 2]

Muito bom seu artigo. Bom para alertar quem não ainda não conhece os problemas de segurança web e acham que isso nunca irá chegar até sua página.Só uma pequena correção: Servidores Web entendem Http e não html (quem entende html é o browser. hehe)