Mostraremos no
decorrer deste artigo como elas acontecem e o mais importante, formas de como
nos proteger delas. Veremos quais as melhores técnicas de desenvolvimento para
este tipo de problema para que não tenhamos mais perdas por esse motivo.
Embora existam milhares de potenciais meios para tirar proveito de sites mal estruturados, injeção de SQL (ou SQL injection) é de longe um dos tipos de ataque mais eficazes, mais fáceis e de longo alcance.
Ataques de injeção de SQL são reportados em uma base de dados diária como, por exemplo, sites que contam com projetos baseados em dados para criar conteúdo dinâmico para os seus leitores. Estes projetos dinâmicos usam o MySQL ou outro SGBD que provavelmente seja baseado em SQL, tornando-os assim, mais vulneráveis aos ataques.
Injeção de SQL é uma técnica de injeção de código que explora uma vulnerabilidade de segurança na camada de banco de dados de um aplicativo.
Esta vulnerabilidade pode ser encontrada quando a entrada do usuário é incorretamente filtrada por strings de caracteres postas por eles, tendo assim, caracteres de escape embutidas em instruções SQL.
Embora a injeção de SQL seja mais comumente utilizada para atacar sites, ela também pode ser usada para atacar qualquer banco de dados SQL.
No ano passado, uma empresa de segurança informou que aplicações web, em média, são atacadas pelo menos quatro vezes por mês por meio de técnicas de injeção SQL. Cabe a nós DBA’s mantermos a segurança desses dados intacta.
Agora que temos um entendimento comum sobre a gravidade do problema, bem como uma definição básica de injeção de SQL, no decorrer deste artigo iremos abordar com mais detalhes sobre como realizar ataques de injeção de SQL e também como nos defendermos contra eles.
Atacando com injeção de SQL (SQL Injection)
Como podemos nos defender de ameaças que nem ao menos temos o conhecimento? Por conta disso, o primeiro passo para a defesa contra um ataque de injeção SQL é entender exatamente como elas acontecem.
Antes de começarmos, algumas informações importantes devem ser lembradas. Em primeiro lugar, não devemos executar um ataque de injeção SQL em qualquer aplicação sem a permissão expressa, por escrito.
Em segundo lugar, não devemos colocar código conhecido que não seja seguro em uma máquina de produção.
Finalmente, não devemos colocar o nosso código de testes em um local de acesso público, já que estamos em um mundo conectado e nele existem pessoas com mal intencionadas que farão uso de nosso código, caso o encontrem.
Agora que temos esses pontos definidos, começaremos então com nosso primeiro exemplo. O exemplo será uma página web simples com base em um banco de dados que será o AdventureWorks 2012.
Especificamente, teremos um aplicativo de formulários da Web ASP.NET conversando com uma instância do SQL Server 2014 (mas a injeção de SQL é relevante em todos os aplicativos e combinações de plataformas de banco de dados).
Imaginemos então, uma grid básica que mostra uma lista de subcategorias de produtos da tabela Production.ProductSubcategory em AdventureWorks 2012. Além desta lista, nós temos um filtro de nomes no qual um usuário poderá digitar uma palavra parcialmente, com uma grid que exibe os itens correspondentes. O SQL para tal consulta pode ser observado na Listagem 1.
Listagem 1. SQL básico para listagem de subcategoria de produtos.
DECLARE @Filter NVARCHAR(50);
SET @Filter = 'Bike';
SELECT ProductSubcategoryID ,
ProductCategoryID ,
Name
FROM Production.ProductSubcategory
WHERE Name LIKE '%' + @Filter + '%'Pelo que está exposto na listagem, a consulta retorna linhas de produtos que incluem a palavra "Bike" em seu nome. Este é o comportamento esperado, e até o momento está tudo bem. Para simularmos um ataque de injeção SQL, podemos tentar mudar o valor do filtro de 'Bike' para 'Bike'' OR 1 = 1--'.
Nosso objetivo aqui, como atacantes, é fazer com que “fora” dos limites do parâmetro, em que ponto nós podemos manipular a própria consulta ou executar alguma instrução SQL completamente diferente.
Neste caso em particular, o nosso objetivo é estender a pesquisa, de forma a retornar as linhas onde o nome é como "%Bike" ou todos os resultados (porque 1 é igual a 1 e é sempre verdadeiro). Em seguida, comentaremos o resto da consulta para evitar erros de sintaxe.
A execução dessa primeira tentativa de um ataque não irá nos mostrar nenhum resultado, ou seja, o nosso ataque falhou. A razão pela qual não fomos capazes de obter um resultado “fora” do parâmetro é que ao invés de procurar por "%Bike" ou onde 1 = 1, estamos realmente procurando por uma subcategoria de produto cujo nome é igual a "Bike 'OR 1 = 1--" e, naturalmente, não há subcategorias de produtos que correspondam a esse nome.
O que fizemos foi uma tentativa de realizar a injeção de SQL contra uma consulta SQL estática, o que simplesmente não é possível. Injeção de SQL só é possível contra o SQL dinâmico. Na Listagem 2 construímos uma consulta SQL dinâmica básica que retorna os mesmos resultados que a Listagem 1.
Listagem 2. Retornando uma lista filtrada de produtos de forma dinâmica.
Declare @Filter Nvarchar(Max);
Set @Filter = 'Bike';
Declare @Sql Nvarchar(Max);
Set @Sql = N'select Productsub ... 
