Os ataques de SQL Injection representam um tremendo risco para aplicativos da Web que dependem de um back-end de banco de dados para gerar conteúdo dinâmico. Nesse tipo de ataque, os hackers manipulam um aplicativo da Web na tentativa de injetar seus próprios comandos SQL naqueles emitidos pelo banco de dados. Por exemplo, veja o artigo SQL Injection Attacks on Databases. Neste artigo, vamos dar uma olhada em várias maneiras de testar seus aplicativos da Web para determinar se eles são vulneráveis a ataques de injeção de SQL.
Escaneamento automatizado de injeção de SQL
Uma possibilidade é usar um scanner de vulnerabilidade de aplicativo da Web automatizado, como o WebInspect da HP, o AppScan da IBM ou o Hailstorm da Cenzic. Todas essas ferramentas oferecem maneiras fáceis e automatizadas de analisar seus aplicativos da Web quanto a possíveis vulnerabilidades de injeção de SQL. No entanto, eles são muito caros, correndo em até US $ 25.000 por assento.
Testes Manuais de Injeção SQL
O que um desenvolvedor de aplicativos ruim deve fazer? Você pode realmente executar alguns testes básicos para avaliar seus aplicativos da Web para vulnerabilidades de Injeção de SQL usando nada mais que um navegador da web. Em primeiro lugar, uma palavra de cautela: os testes que descrevemos buscam apenas falhas básicas de SQL Injection. Eles não detectam técnicas avançadas e são um pouco entediantes de usar. Se você puder pagar, use um scanner automatizado. No entanto, se você não conseguir lidar com esse preço, o teste manual é um ótimo primeiro passo.A maneira mais fácil de avaliar se um aplicativo é vulnerável é experimentar ataques de injeção inócuos que não causarão danos ao seu banco de dados se forem bem-sucedidos, mas fornecerão evidências de que é necessário corrigir um problema. Por exemplo, suponha que você tenha um aplicativo da Web simples que procure um indivíduo em um banco de dados e forneça informações de contato como resultado. Essa página pode usar o seguinte formato de URL: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike
Podemos supor que esta página realiza uma consulta ao banco de dados, usando uma consulta semelhante à seguinte: Telefone SELECT
Diretório FROM
ONDE lastname = 'chapple' e firstname = 'mike'
Vamos experimentar isso um pouco. Com nossa suposição acima, podemos fazer uma alteração simples na URL que testa ataques de injeção de SQL: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1
Se o aplicativo da Web não tiver sido protegido adequadamente contra a injeção de SQL, ele simplesmente conectará esse nome falso à instrução SQL executada no banco de dados, resultando em: Telefone SELECT
Diretório FROM
ONDE lastname = 'chapple' e firstname = 'mike'
E (selecione count (*) de falso)> 0
OU '1' = '1'
Você perceberá que a sintaxe acima é um pouco diferente daquela no URL original. Nós tomamos a liberdade de converter a variável codificada em URL para seus equivalentes ASCII para facilitar seguir o exemplo. Por exemplo,% 3d é a codificação de URL para o caractere '='. Também adicionamos algumas quebras de linha para propósitos semelhantes. O teste surge quando você tenta carregar a página da Web com o URL listado acima. Se o aplicativo da Web for bem comportado, ele removerá as aspas simples da entrada antes de passar a consulta ao banco de dados. Isso simplesmente resultará em uma pesquisa estranha para alguém com um nome que inclua um monte de SQL. Você verá uma mensagem de erro do aplicativo semelhante à abaixo: Erro: Nenhum usuário encontrado com o nome mike + AND + (selecione + count (*) + de + fake) +% 3e0 + OU + 1% 3d1
Chapple!
Por outro lado, se o aplicativo for vulnerável à injeção de SQL, ele passará a instrução diretamente para o banco de dados, resultando em uma das duas possibilidades. Primeiro, se o seu servidor tiver mensagens de erro detalhadas ativadas (o que você não deveria), você verá algo assim: Provedor Microsoft OLE DB para erro ODBC Drivers '80040e37'
Microsoft Driver ODBC do SQL Server SQL Server Nome de objeto inválido 'fake'.
/directory.asp, linha 13
Por outro lado, se o seu servidor da Web não exibir mensagens de erro detalhadas, você receberá um erro mais genérico, como: Erro do Servidor InternoO servidor encontrou um erro interno ou uma configuração incorreta e não pôde concluir sua solicitação.
Entre em contato com o administrador do servidor para informar sobre a hora em que o erro ocorreu e sobre qualquer coisa que você tenha feito que possa ter causado o erro.
Mais informações sobre esse erro podem estar disponíveis no log de erros do servidor.
Se você receber um dos dois erros acima, seu aplicativo ficará vulnerável a ataques de injeção de SQL. Algumas etapas que você pode seguir para proteger seus aplicativos contra ataques de injeção de SQL incluem: Avaliando os resultados
