Vulnerabilidades em aplicações Web — SQL Injection

A segurança em aplicações web já é um tema bastante discutido por empresas e desenvolvedores. No momento de desenvolvimento e manutenção de aplicações, novas maneiras de ataques e proteção surgem na web a todo tempo e já existem diversas ferramentas para testes e simulações que ajudam na análise e melhoria da segurança dessas aplicações.

A OWASP (Open Web Application Security Project) Comunidade aberta dedicada a orientar organizações sobre o desenvolvimento de aplicações mais seguras, publicou um documento contendo o TOP 10 dos riscos mais críticos encontrados em aplicações web e a Injeção (SQL e Outras), apareceu em primeiro lugar!

Mas afinal, o que realmente é SQL Injection?

SQL Injection é uma técnica de ataque que normalmente tem o objetivo de obter acesso a áreas ou informações especificas de uma aplicação web, inserindo ou consultando informações do banco de dados que esta aplicação utiliza.

O ataque normalmente se utiliza de formulários não validados pela aplicação ou até mesmo de parâmetros que podem ser passados pela URL da aplicação para inserir comandos no banco de dados, que podem retornar dados sensíveis ou por exemplo, dar acesso não autorizado a usuários.

Como funciona na prática?

Abaixo segue dois exemplos práticos de como um ataque desse tipo acontece em uma aplicação web.

1º O ataque via URL:

Cenário: Você está construindo uma API que precisa retornar carros em um determinado status que é fornecido como parâmetro na URL, construindo este recurso, a URL da API poderia ficar da seguinte forma:

www.suaapi.com/carros/status/parâmetro

Esse parâmetro é passado para a consulta, pois é necessário para retornar as informações do banco de dados de acordo com o status especifico. Ficaria algo parecido com isso:

SELECT * FROM carros WHERE status = ‘parâmetro’

Neste caso sua consulta retornaria todos os carros que estão com o status fornecido no parâmetro. Porém devemos lembrar que o controle do que está sendo passado nesse momento, está do lado do usuário, certo?

Imagine que ao invés de passar um status o usuário passe, por exemplo, uma outra consulta como parâmetro que invalida a sua e executa a dele no lugar, algo como a URL seguinte:

www.suaapi.com/carros/status/’;SELECT * FROM usuários

Neste caso a aspa simples e o ponto e vírgula, serviriam para terminar a sua consulta e executar uma segunda consulta, que retorna todos os dados dos usuários da aplicação. O que antes era uma única consulta que retornava carros se torna duas que também retorna os dados dos usuários, ficando assim:

SELECT * FROM carros WHERE status = ”; SELECT * FROM usuários

Com isso todos os dados dos usuários na tabela em questão estariam expostos e o ataque teria sucesso!

2º O ataque via formulário

O ataque via formulário tem o mesmo conceito do ataque via URL, mas a diferença que o usuário tenta inserir informações, por exemplo, em um formulário de login, que pode levar ao acesso a partes restritas de um sistema sem o fornecimento de um login e uma senha válidos.

Cenário: Um formulário simples de login com usuário e senha que consulta se o usuário existe ou não em um banco de dados.

Nesse cenário uma consulta exemplo utilizada para validar este login poderia ser:

SELECT * FROM usuarios WHERE login = ‘parametrologin’ AND senha = ‘parametrosenha’

Então imagine que o usuário digite, por exemplo, o comando ‘ OR ‘1’=’1 nos campos de login e senha, a consulta final ficaria da seguinte forma:

SELECT * FROM usuarios WHERE login = ” OR ‘1’=’1′ AND senha = ” OR ‘1’=’1′

Com essa modificação a consulta passa a retornar os registros de usuários do sistema sem validar o usuário e senha. Pois 1 sempre será igual a 1, logo, se o desenvolvedor estiver utilizando esta consulta para validar se existem usuários ou não com este login e senha, e baseado nisso liberar o acesso a alguma área da ferramenta, o acesso seria liberado facilmente.

“Sempre valide os dados fornecidos pelo usuário!”

Esta é a dica chave para se proteger contra estes ataques, todos os dados e parâmetros que são fornecidos pelo usuário devem ser validados e tratados antes de serem passados para as consultas no banco de dados.

Segue algumas outras dicas que podem nos ajudar a não ter problema com o SQL Injection:

Utilizar consultas parametrizadas: Nunca utilizar consultas com os parâmetros concatenados direto no código, esta pratica pode abrir vulnerabilidades para quem está explorando a aplicação.

Utilizar ferramentas que auxiliam nos testes: Existem ferramentas automatizadas interessantes que ajudam a identificar possíveis vulnerabilidades na sua aplicação, recomendo uma pesquisa no Google sobre o sqlmap e sobre o hajiv!

Utilize LIMIT nas suas consultas: Não só o LIMIT, mas outros controles das consultas podem evitar o acesso em massa aos registros em caso de SQL Injection bem-sucedido.

Limitar acessos somente ao necessário: A Maioria dos SGBDS de mercado fornecem um bom sistema para limitar os acessos aos usuários e impedir o acesso a informações que não devem ser expostas.

A ideia deste artigo foi passar uma visão básica de como um dos ataques a aplicações web mais famosos e utilizados acontece e como você pode se proteger do mesmo, procurei me abster de falar ou dar exemplo de uma linguagem de programação especifica, mas hoje a maioria das linguagens também tem bibliotecas com métodos e meios que te ajudam mais ainda com a proteção dos dados da sua aplicação. Vale sempre dar uma pesquisa no nosso amigo Google 🙂

Você pode também sempre ler e pesquisar mais sobre estes e outros ataques no site da OWASP!