Injeção de SQL SQLi

O que é injeção de SQL

Você tem uma loja virtual. Um visitante digita algo estranho no campo de busca, aperta Enter e a página mostra para ele o nome, o telefone e o histórico de pedidos de todos os seus clientes. Ninguém roubou senha nenhuma. Ele digitou as palavras certas no lugar errado, e o seu site fez o resto. Isso é injeção de SQL.

A maioria dos sites guarda suas informações em um banco de dados: um depósito organizado de tabelas, parecido com um conjunto de planilhas. Para ler ou alterar essas informações, o site usa uma linguagem chamada SQL (Structured Query Language). Cada pedido que ele envia é uma consulta, por exemplo "encontre o cliente que tem este e-mail".

A injeção de SQL acontece quando um site pega o que o visitante digita e cola direto dentro de uma dessas consultas. Se o visitante digitar SQL em vez de texto comum, o banco de dados não percebe a diferença e segue o comando do atacante como se o próprio site tivesse escrito. Muita gente abrevia o nome para SQLi.

Como funciona um ataque de injeção de SQL

Pense em um funcionário de banco que repassa, palavra por palavra, qualquer bilhete que o cliente entrega para a equipe do cofre. Um bilhete normal diz "me mostrem meu saldo". Um bilhete malandro diz "me mostrem meu saldo e abram também todos os cofres". Se o funcionário nunca lê o bilhete antes, a equipe do cofre obedece.

Em um site, os passos costumam ser estes:

1. O atacante encontra um lugar que envia texto ao banco de dados: um formulário de login, um campo de busca, um formulário de contato ou o próprio endereço web, como a página de um produto que termina em "?id=25".
2. Ele digita um pedacinho de SQL no lugar de um texto comum. Um exemplo bem conhecido é digitar ' OR '1'='1 no campo de senha de um formulário de login.
3. O site junta esse texto à própria consulta sem verificar nada. Agora a consulta pede algo como "deixe esta pessoa entrar se a senha estiver certa, ou se 1 for igual a 1".
4. Como 1 é sempre igual a 1, o banco de dados responde que sim, e o atacante entra sem saber senha nenhuma.

Alguns ataques são mais silenciosos. Na injeção de SQL cega, a página não mostra dado nenhum, então o atacante faz ao banco perguntas de sim ou não e observa como a página reage, ou quanto tempo ela demora para carregar. Feito à mão, é um trabalho lento, e por isso os atacantes usam ferramentas automáticas gratuitas que fazem isso por eles.

O que um atacante pode fazer

Quando o banco de dados passa a seguir os comandos dele, o estrago depende do que a conta de banco de dados do site tem permissão para fazer. Muitas vezes, é bem mais do que o site precisa. Um atacante pode conseguir:

• ler dados privados, como nomes, endereços, e-mails e histórico de pedidos dos clientes, prontuários médicos ou senhas salvas
• entrar como outro usuário, inclusive como administrador
• alterar dados, como preços, saldos ou o status dos pedidos
• apagar tabelas inteiras, ou o banco de dados completo
• em algumas configurações, chegar ao próprio servidor e deixar arquivos nocivos nele

Por que isso importa para o seu negócio

A injeção de SQL é um dos ataques mais antigos da web, e continua por aí. A OWASP, uma comunidade aberta que publica a conhecida lista OWASP Top 10 de riscos de aplicações web, mantém a injeção nessa lista há anos. É fácil de tentar, e muitos sites ainda têm algum formulário esquecido que deixa o ataque passar.

Para quem tem um negócio, o prejuízo real quase nunca é técnico. É uma lista de clientes vazada, uma loja vendendo pelo preço errado, um sistema de agendamento que perde uma semana de horários ou uma mensagem que você precisa mandar aos clientes avisando que os dados deles foram expostos. Em muitos países, leis de proteção de dados como a GDPR também exigem que você proteja dados pessoais e comunique vazamentos.

Cada formulário do seu site foi feito pensando nisso? Sites montados às pressas com plugins antigos, ou alterados por muitas mãos ao longo dos anos, têm mais chance de esconder um ponto fraco.

Como proteger um site contra injeção de SQL

A solução principal é bem conhecida e funciona. Quase toda a proteção está no jeito como o site é construído, então estas são boas perguntas para fazer aos seus desenvolvedores ou ao seu fornecedor.

• Prepared statements. Também chamadas de consultas parametrizadas. O site envia a consulta e o texto do visitante separados, de modo que o banco sempre trata esse texto como dado comum e nunca como comando. Essa é a principal defesa. Frameworks modernos como o Laravel fazem isso por padrão quando os desenvolvedores usam as ferramentas de banco de dados que já vêm com eles.
• Verificação das entradas. Um campo de telefone deve aceitar só números, e um campo de data, só datas. Recusar cedo as entradas estranhas fecha muitas portas.
• Privilégio mínimo. A conta que o site usa para acessar o banco deve ter só as permissões de que precisa. Uma página pública de busca não tem motivo nenhum para apagar tabelas.
• Mensagens de erro discretas. Um erro detalhado do banco na tela entrega um mapa ao atacante. Mostre ao visitante uma mensagem curta e simples e guarde os detalhes em logs privados.
• Atualizações. Mantenha a plataforma, os plugins e as bibliotecas em dia, porque versões antigas costumam ter falhas conhecidas.
• Um firewall de aplicação web. É um filtro na frente do site que bloqueia muitos padrões de ataque conhecidos antes que cheguem ao seu código. Ajuda, mas não conserta código inseguro.
• Testes regulares. O teste de invasão (um ataque seguro e planejado, feito por especialistas) e a varredura de vulnerabilidades encontram os pontos fracos antes de um atacante.

Veja como alguns hábitos do dia a dia se comparam:

Erros comuns

• Confiar nas verificações do navegador. Verificações que rodam no aparelho do próprio visitante são fáceis de contornar, então o servidor precisa verificar tudo de novo.
• Achar que um site pequeno está seguro. Ferramentas automáticas varrem uma quantidade enorme de sites sem ligar para o tamanho deles.
• Corrigir um formulário e esquecer o resto. O campo de busca, os filtros, o endereço web e a API por trás de um aplicativo precisam do mesmo cuidado.
• Guardar senhas em texto puro. Se houver vazamento, senhas guardadas com um hash forte (transformadas em um código embaralhado que não dá para ler de volta) são muito mais difíceis de usar.
• Depender só de um firewall. Um filtro ganha tempo. A consulta insegura por trás dele ainda precisa ser corrigida.

Como podemos ajudar

Na Linkysoft, procurar injeção de SQL faz parte dos nossos serviços de cibersegurança. Fazemos ataques simulados e seguros no seu site, no seu aplicativo e na sua API, revisamos o código e entregamos uma lista em linguagem simples com o que encontramos e como corrigir. Depois das correções, testamos de novo. Isso vale também para sites feitos por outras equipes, e a verificação de segurança gratuita é um primeiro passo fácil.

Está planejando um sistema novo? Nossos aplicativos web e sistemas de gestão são seguros desde o projeto, com reforço segundo o OWASP Top 10 e teste de invasão antes do lançamento.