O que é injeção de SQL (SQLi)?

Uma injeção de SQL (SQLi) está entre os tipos de ataque cibernético mais previsíveis e fáceis de defender. Infelizmente, as injeções de SQL também estão entre as táticas de crime cibernético mais eficazes, principalmente porque são fáceis de executar e muitas empresas não conseguem implementar as contramedidas necessárias.

Um SQLi também tem consequências devastadoras (violações de dados, intrusos obtendo acesso root, uso indevido de contas, etc.), e é por isso que a prevenção de injeções deve estar no topo da sua lista de tarefas de segurança cibernética.

Este artigo mostrará tudo que uma equipe de segurança deve saber sobre injeções de SQL. Explicaremos o que é injeção de SQL, mostraremos as diferentes táticas que os hackers usam para explorar falhas relacionadas ao SQL e apresentaremos as maneiras mais eficazes de proteger um banco de dados contra tentativas de SQLi.

O que é injeção SQL?

Uma injeção de SQL (SQLi) é um ataque cibernético no qual alguém injeta instruções SQL maliciosas em um aplicativo para comprometer arquivos no banco de dados associado. Os criminosos usam SQLi para atingir aplicativos e sites que dependem de um banco de dados SQL (ou seja, MySQL, Oracle, PostgreSQL, Microsoft SQL Server, etc.).

As injeções de SQL normalmente ocorrem devido à má validação de entrada e à falta de parametrização adequada em aplicativos baseados em SQL. Os invasores exploram essas falhas para induzir o aplicativo a executar comandos não intencionais no servidor de banco de dados, permitindo que os hackers:

• Acesse dados.
• Extrair arquivos.
• Exclua ou modifique dados.

A maioria das vulnerabilidades do SQLi surge na cláusula WHERE de uma consulta SELECT. No entanto, uma falha pode ocorrer em qualquer local da consulta. Outros locais comuns onde surgem falhas SQLi são:

• Instruções INSERT (dentro dos valores inseridos).
• Instruções SELECT (dentro de nomes de tabelas/colunas ou na cláusula ORDER BY).
• Instruções UPDATE (dentro de valores atualizados ou na cláusula WHERE).

Se houver uma falha explorável no banco de dados, uma injeção de SQL será simples de ser executada, mesmo por um hacker novato. Os invasores normalmente encontram alvos vulneráveis usando pesquisas avançadas do Google (o chamado Google Dorking) e, em seguida, alimentam os URLs encontrados para um bot automatizado que realiza injeções.

Apesar desta simplicidade, algumas das maiores marcas do mundo foram vítimas de injeções de SQL nos últimos anos (LinkedIn, Target, Yahoo, Equifax, 7-Eleven, Epic Games, Zappos, TalkTalk, Sony Pictures, etc.).

Estatísticas de injeção SQL

Aqui estão algumas estatísticas recentes que você deve saber sobre injeções de SQL:

• Em 2022, 1.162 novas vulnerabilidades SQLi foram adicionadas ao CVE (Common Vulnerabilities and Exposures), o banco de dados de informações divulgadas publicamente sobre questões de segurança.
• Os bancos de dados SQL foram a principal fonte de vulnerabilidades de aplicativos web em 2022, respondendo por cerca de 33% de todas as falhas.
• Dois em cada três ataques na Web incluem uma tentativa de injetar um comando SQL malicioso.
• Especialistas em segurança suspeitam que 21% das organizações possuem atualmente uma vulnerabilidade explorável relacionada ao SQL.
• Em 2022, cerca de 42% de todas as tentativas de hacking em sistemas públicos foram injeções de SQL. A ameaça estende-se aos sistemas internos, mas em menor grau (aproximadamente 12%).
• A pesquisa sugere que um recorde de 35% das instituições educacionais tem uma vulnerabilidade SQLi explorável.

Potenciais consequências da injeção de SQL

As injeções de SQL geralmente têm consequências graves e de longo alcance para as organizações vítimas desses ataques. Aqui está o que agentes mal-intencionados podem realizar com uma injeção de SQL:

• Analise o banco de dados e aprenda sobre sua versão e estrutura, informações que se tornam valiosas em ataques futuros (por exemplo, uma carga útil de ransomware destinada a criptografar arquivos específicos em um banco de dados).
• Recuperar dados confidenciais do banco de dados (por exemplo, nomes de usuário, senhas, endereços de e-mail, detalhes de cartão de crédito, etc.).
• Modifique, insira ou exclua arquivos do banco de dados, causando corrupção e perda de integridade dos dados.
• Obstrua a lógica de um aplicativo.
• Explorar recursos do servidor e causar degradação de desempenho ou falhas.
• Ignore o mecanismo de autenticação e obtenha acesso a uma conta sem conhecer as credenciais.
• Aumente privilégios e obtenha acesso ao servidor subjacente.
• Interrompa as operações comerciais normais e cause tempo de inatividade, perda de receita e insatisfação do cliente.
• Use o servidor subjacente para lançar um ataque DDoS.
• Implante malware ou configure recursos para violações mais avançadas (por exemplo, um ataque APT).

Como funciona a injeção de SQL?

Uma injeção de SQL ocorre quando um hacker envia consultas SQL maliciosas (solicitações para realizar alguma ação em um banco de dados de aplicativo) a um site ou serviço baseado na Web por meio de um formulário ou caixa de pesquisa. Um invasor envia entradas especialmente criadas que incluem código SQL junto com dados legítimos. Dessa forma, um hacker engana o aplicativo para que ele execute comandos SQL não intencionais.

Por exemplo, um aplicativo baseado na web possui um formulário de login com dois campos, um para nomes de usuário e outro para senhas. O aplicativo constrói a seguinte consulta SQL para verificar a validade das credenciais quando alguém envia uma entrada:

SELECT * FROM users WHERE username = 'input_username' AND password = 'input_password';

Portanto, quando um usuário legítimo digita "admin1" como nome de usuário e "SuSIOP8f&)@^Sx2" como senha, a seguinte instrução SQL é executada no servidor de banco de dados:

SELECT * FROM users WHERE username = 'admin1' AND password = 'SuSIOP8f&)@^Sx2';

Essa consulta autentica o usuário que forneceu credenciais válidas. No entanto, um invasor pode inserir o seguinte no campo de nome de usuário:

' OR '1'='1

Depois que o aplicativo envia essa solicitação, a consulta se torna:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'input_password';

Como '1'='1' é sempre verdadeiro, a consulta efetivamente se torna:

SELECT * FROM users WHERE username = '' OR true AND password = 'input_password';

Essa consulta manipulada permite que um invasor ignore a verificação de senha e obtenha acesso não autorizado. A consulta retorna todas as linhas onde o nome de usuário está vazio ou verdadeiro.

Na maioria dos casos, não há indicações de que alguém esteja realizando injeções de SQL em um banco de dados. O único sinal de ataque é um número excessivo de solicitações em um curto espaço de tempo, um sinal de alerta que muitas vezes passa despercebido pela equipe de segurança.

Tipos de injeção SQL

Existem três tipos principais de injeções de SQL com base em como um invasor interage com o aplicativo de destino e seu banco de dados: injeções de SQL dentro da banda, inferenciais e fora da banda. Vamos dar uma olhada em cada categoria.

Injeções de SQL em banda

As injeções de SQL em banda ocorrem quando um invasor usa o mesmo canal de comunicação (ou seja, banda) para lançar o ataque e coletar resultados. O ator malicioso envia código SQL manipulado e a resposta do aplicativo fornece feedback direto sobre o sucesso do ataque.

Aqui estão as diferentes técnicas de injeção de SQL em banda:

• Injeções SQL clássicas: um invasor injeta código SQL malicioso em um campo de entrada para manipular a consulta do banco de dados. As injeções clássicas são a opção ideal para ignorar a autenticação ou recuperar arquivos do banco de dados.
• Injeções SQL baseadas em erros: um hacker aciona intencionalmente mensagens de erro SQL para coletar informações sobre o esquema ou conteúdo do banco de dados.
• Injeções de SQL baseadas em união: um invasor usa o operador SQL UNION para combinar os resultados da consulta original com os resultados de outra consulta. Dessa forma, um invasor recupera dados de outras tabelas do banco de dados.
• Injeções de SQL de segunda ordem: um agente malicioso não executa a entrada, mas a armazena em um banco de dados. A entrada armazenada é ativada em uma nova consulta SQL quando um usuário acessa alguma funcionalidade específica do aplicativo.

As táticas dentro da banda são o tipo mais comum de injeção de SQL. Esses ataques também são mais fáceis de realizar do que outros SQLi inferenciais ou fora de banda.

Injeções SQL inferenciais (SQLi cego)

As injeções inferenciais de SQL acontecem quando um invasor envia código SQL malicioso, mas não recebe feedback direto do aplicativo de destino. Em vez disso, o invasor infere informações do comportamento do servidor (daí o termo "SQLi cego").

Existem dois tipos distintos de injeções SQL inferenciais:

• Injeções SQL cegas baseadas em tempo: Um hacker usa atrasos em consultas SQL para avaliar as respostas do aplicativo e inferir informações sobre o banco de dados. Por exemplo, um hacker poderia usar uma consulta SQL para comandar um atraso de três segundos se a primeira letra do nome do primeiro banco de dados for A. Se a resposta levar três segundos, o invasor saberá que a consulta é válida.
• Injeções cegas de SQL baseadas em booleanos: um invasor envia uma série de perguntas do tipo "você ou não" baseadas em booleanos ao banco de dados do aplicativo da web. O hacker observa o comportamento do aplicativo e gradualmente coleta informações sobre a estrutura e o conteúdo do banco de dados.

Uma injeção inferencial de SQL é uma escolha comum para quem tenta mapear a estrutura do banco de dados.

Injeções SQL fora de banda

As injeções de SQL fora de banda ocorrem quando alguém envia código SQL malicioso ao aplicativo de destino e o engana para que envie dados a um endpoint remoto controlado pelo invasor. Aqui estão as técnicas de injeções SQL fora de banda mais comuns:

• Injeções XML SQL: se um aplicativo usa consultas XML para interagir com um banco de dados, um agente mal-intencionado pode manipular dados de entrada para injetar código XML malicioso e alterar o comportamento da consulta.
• Injeções de SQL baseadas em heap: esse tipo de injeção de SQL tem como alvo o mecanismo de alocação de memória do aplicativo. Um invasor injeta informações maliciosas para interromper ou corromper a memória do aplicativo, causando falhas ou obtendo acesso não autorizado.
• Injeções de procedimentos armazenados: esta técnica tem como alvo aplicativos que usam procedimentos armazenados para interagir com o banco de dados. Um invasor injeta informações maliciosas nos parâmetros do procedimento para obter acesso ou manipular dados.

As técnicas fora de banda são o tipo menos comum e mais complexo de injeção de SQL. Os hackers recorrem a esses métodos se o servidor de destino for muito lento ou instável para injeções de SQL inferenciais ou em banda (ou em casos específicos quando um aplicativo bloqueia ou limpa certos tipos de respostas).

Como prevenir a injeção de SQL?

Abaixo estão algumas das maneiras mais eficazes de garantir que seu banco de dados nunca seja vítima de uma injeção de SQL.

Adote práticas seguras de codificação de banco de dados

Adote práticas e princípios seguros de codificação de banco de dados para garantir que os desenvolvedores escrevam códigos resistentes a explorações comuns relacionadas ao SQL.

Aqui estão algumas práticas altamente eficazes na prevenção de injeções de SQL:

• Valide e higienize todas as entradas do usuário.
• Permita apenas formatos e caracteres de entrada esperados em seus formulários.
• Use consultas parametrizadas e instruções preparadas ao interagir com bancos de dados.
• Se consultas parametrizadas ou instruções preparadas não forem uma opção, evite a entrada do usuário antes de incluí-la em uma consulta para converter caracteres potencialmente perigosos em equivalentes seguros.
• Armazene dados confidenciais (senhas, chaves de API, tokens etc.) em arquivos de configuração seguros ou variáveis de ambiente, em vez de codificar dados na base de código.
• Evite construir consultas dinamicamente usando concatenação de strings.
• Use a codificação de saída para garantir que os dados sejam exibidos como conteúdo e não como código executável.
• Conduza revisões regulares de código por pares para identificar e corrigir possíveis vulnerabilidades.

Além disso, certifique-se de que os desenvolvedores usem apenas bibliotecas e estruturas de segurança bem estabelecidas que passaram por análises completas.

Use um firewall de aplicativo da Web (WAF)

Um Web Application Firewall (WAF) filtra todo o tráfego entre o aplicativo Web e seu banco de dados. Os WAFs analisam o tráfego de entrada e inspecionam os dados para:

• Padrões de ataque conhecidos.
• Anomalias.
• Comportamento suspeito.

Um WAF depende de várias técnicas para identificar e bloquear solicitações maliciosas (por exemplo, detecção baseada em assinaturas, análise comportamental, aprendizado de máquina, etc.). Esses firewalls bloqueiam tentativas de injeção de SQL em tempo real antes que elas atinjam o código do seu banco de dados.

Mantenha o software atualizado

As organizações devem manter o software atualizado com os patches de segurança mais recentes. Certifique-se de que os seguintes elementos tenham as atualizações mais recentes:

• Sistemas operacionais.
• Servidores web.
• Sistemas de gerenciamento de banco de dados (MySQL, PostgreSQL, Microsoft SQL Server, etc.).
• Sistemas de gerenciamento de conteúdo (WordPress, Joomla, Drupal, etc.).
• Frameworks de aplicativos (Django, Ruby on Rails, Laravel, etc.).
• Firewalls.
• Navegadores da Web.
• Bibliotecas, estruturas, plug-ins e extensões de terceiros.
• Bibliotecas de autenticação e autorização.
• Software de servidor (por exemplo, SSH, FTP, ferramentas de gerenciamento remoto, etc.).

Além disso, se seus aplicativos voltados para a Web se integrarem a APIs ou serviços de terceiros, verifique se eles estão usando as versões mais recentes de seus softwares.

Nunca armazene dados confidenciais em texto simples

A criptografia de dados valiosos garante que, mesmo que um invasor consiga extrair arquivos com uma injeção de SQL, os dados roubados permaneçam ilegíveis sem as chaves de descriptografia.

Implemente criptografia tanto para dados em repouso (armazenados no banco de dados) quanto em trânsito (transferidos entre o aplicativo e o banco de dados). Lembre-se de que sua estratégia de criptografia é tão boa quanto suas práticas de gerenciamento de chaves, portanto, certifique-se de que sua equipe saiba como manter as chaves criptográficas seguras.

Teste regularmente os pontos fracos do SQLi

O teste de vulnerabilidades de injeção de SQL é uma parte crítica da prevenção de ataques. Aqui estão algumas práticas que valem a pena:

• Revise regularmente seu código-fonte para identificar possíveis vulnerabilidades de injeção de SQL. Preste atenção especial às áreas onde as consultas usam diretamente entradas do usuário baseadas na web.
• Experimente cargas de injeção de SQL conhecidas para verificar a resistência do seu aplicativo a técnicas de ataque padrão.
• Manipule entradas para acionar erros de banco de dados e analise se as mensagens revelam algo de valor.
• Use ferramentas automatizadas de verificação de vulnerabilidades para identificar falhas comuns rapidamente.
• Execute testes de caixa branca (com conhecimento do funcionamento interno do aplicativo) e de caixa preta (sem conhecimento interno).
• Sempre teste entradas com caracteres especiais, palavras-chave SQL e cargas úteis para garantir a higienização adequada.
• Teste como seu aplicativo e seu banco de dados lidam com consultas parametrizadas e instruções preparadas.
• Injete consultas que causam atrasos no servidor e observe as diferenças no tempo que o aplicativo leva para responder.
• Teste injeções baseadas em booleanos com consultas que dependem de condições verdadeiras/falsas (por exemplo, OR 1=1 e OR 1=2).
• Verifique como seu aplicativo responde a diferentes consultas UNION.
• Envie o caractere de aspas simples em seu campo de entrada e procure por erros ou outras anomalias.
• Envie uma carga útil OAST projetada para acionar uma interação de rede fora de banda quando executada em uma consulta SQL. Em seguida, verifique se há interações resultantes.

Lembre-se de realizar testes de injeção de SQL regularmente. É uma excelente ideia fazer algumas verificações sempre que a equipe fizer alterações significativas no código, atualizações ou acréscimos de recursos.

Garanta o tratamento seguro de erros

Nunca exiba mensagens de erro detalhadas no navegador do cliente. Em vez disso, forneça mensagens de erro genéricas ou pop-ups fáceis de usar que não compartilhem insights sobre o funcionamento interno do seu aplicativo.

As injeções de SQL baseadas em erros são uma tática popular para reconhecimento do sistema, portanto, garanta que um agente mal-intencionado não consiga aprender nada de útil causando erros intencionalmente.

Treine a conscientização sobre SQLi

Eduque sua equipe sobre os riscos, técnicas e práticas recomendadas relacionadas às injeções de SQL para melhorar sua postura de segurança. Organize sessões regulares de treinamento em segurança cibernética para todo o pessoal técnico (desenvolvedores de software, controle de qualidade, SysAdmins, equipes de DevOps, etc.).

O alto conhecimento das ameaças SQLi reduz a superfície geral de ataque para injeções. Desenvolvedores experientes também são mais propensos a escrever códigos seguros e identificar falhas nos estágios iniciais de desenvolvimento.

Uma empresa bem preparada nunca deve ser vítima do SQLi

As injeções de SQL são uma técnica de hacking comum, com consequências muitas vezes graves. Portanto, é vital proteger sua empresa dessa ameaça. Felizmente, seguir as práticas recomendadas e testar periodicamente as falhas é suficiente para combater o risco do SQLi. Configure as precauções discutidas neste artigo e garanta que seus bancos de dados não sejam vulneráveis a injeções de SQL.