Como evitar a injeção de SQL

A aplicação do acesso com menor privilégio, a higienização das entradas do usuário e a restrição dos procedimentos do banco de dados podem ajudar a evitar a injeção de SQL e a subsequente violação de dados.

Objetivos de aprendizado

Após ler este artigo, você será capaz de:

  • Explicar como funciona a injeção de SQL
  • Analisar as práticas recomendadas para impedir a injeção de SQL
  • Saiba como a Cloudflare ajuda a evitar ataques de SQLi

Conteúdo relacionado


Quer saber mais?

Assine o theNET, uma recapitulação mensal feita pela Cloudflare dos insights mais populares da internet.

Consulte a política de privacidade da Cloudflare para saber como coletamos e processamos seus dados pessoais.

Copiar o link do artigo

Como funcionam os ataques de injeção de SQL

A injeção de linguagem de consulta estruturada (SQLi) é um ataque de injeção de código que permite ao invasor recuperar, manipular ou destruir informações confidenciais localizadas em bancos de dados SQL. Esses ataques funcionam com a inserção de comandos especializados nos campos de consulta SQL; quando executados, os comandos podem permitir que o invasor falsifique a identidade de usuários legítimos, visualize ou recupere dados protegidos e até mesmo obtenha acesso root aos servidores.

Muitas vezes, os invasores executam o SQLi explorando vulnerabilidades em interfaces de programação de aplicativos (APIs) que não conseguem diferenciar adequadamente entre códigos legítimos e não confiáveis. Sem a capacidade de detectar comandos ou consultas alterados, essas APIs podem ser usadas para executar solicitações maliciosas, como contornar o firewall de aplicativos web (WAF) ou medidas de autenticação.

Normalmente, o SQLi é executado usando um desses três métodos:

  1. A injeção de SQL em banda usa um único canal de comunicação para iniciar e concluir um ataque. Os tipos comuns de SQLi em banda incluem SQLi baseado em erro (quando as mensagens de erro ajudam o invasor a identificar informações críticas sobre o banco de dados subjacente) e SQLi baseado em união (quando o invasor usa operadores UNION SQL para descobrir vulnerabilidades no banco de dados). Essa é a forma mais simples e mais comum de SQLi.
  2. A injeção de SQL fora de banda, ao contrário, não permite que o invasor use o mesmo canal de comunicação para iniciar e concluir um ataque. Em vez disso, o aplicativo comprometido deve ser capaz de exfiltrar dados para um endpoint remoto sob o controle do invasor, geralmente por meio de solicitação de DNS ou HTTP. Essa é a forma mais difícil e menos comum de SQLi.
  3. A injeção de SQL inferencial, também chamada de blind SQLi, exige que o invasor envie conteúdo malicioso para o servidor visado a fim de aprender como explorá-lo. Ela geralmente assume uma de duas formas: blind SQLi baseada em booleano (quando os invasores usam consultas verdadeiro-falso para forçar um servidor a produzir respostas diferentes) ou blind SQLi baseada em tempo (quando os invasores podem inferir as mesmas informações por meio de variações nos tempos de resposta do servidor). Isso geralmente leva mais tempo para ser concluído do que a SQLi em banda, mas pode ser igualmente prejudicial.

Para ver exemplos reais de consultas SQL benignas e maliciosas, leia O que é injeção de SQL?

Como evitar a injeção de SQL

Embora a injeção de SQL seja uma das ameaças de APIs mais comuns, ela pode ser evitada de forma eficaz com as estratégias de prevenção corretas. As abordagens úteis para evitar a injeção de SQL incluem a restrição de procedimentos do banco de dados, a higienização das entradas do banco de dados e a aplicação do acesso com privilégios mínimos.

Restringir procedimentos e códigos de banco de dados

A injeção de SQL depende em grande parte da capacidade de um invasor de manipular entradas de dados e funções de banco de dados. Ao restringir essas entradas e limitar o tipo de procedimentos de banco de dados que podem ser executados, as organizações podem minimizar o risco de consultas não autorizadas ou maliciosas. As formas de fazer isso incluem:

  • Aplicação de instruções preparadas e consultas parametrizadas: as instruções preparadas definem o código SQL aceitável e, em seguida, definem parâmetros específicos para as consultas de entrada. Quaisquer instruções SQL maliciosas são classificadas como entradas de dados inválidas, em vez de comandos executáveis.
  • Utilização de procedimentos armazenados: assim como as instruções preparadas, os procedimentos armazenados são instruções SQL preparadas e reutilizáveis que podem ser recuperadas de um banco de dados e impedem que partes maliciosas executem códigos diretamente no próprio banco de dados.

Validar e higienizar as entradas do banco de dados

As entradas do usuário em qualquer banco de dados SQL devem ser monitoradas, validadas e higienizadas regularmente para eliminar código malicioso.A validação de entradas garante que os dados sejam devidamente inspecionados e formatados de acordo com critérios predeterminados, enquanto a higienização de entradas modifica (ou "higieniza") a entrada removendo caracteres inválidos ou inseguros e reformatando-a conforme necessário. As formas de garantir a validação de entradas incluem:

  • Estabelecimento de uma lista de permissões: uma lista de permissões pode ajudar a definir entradas de usuário válidas, em relação às quais o banco de dados pode verificar (e rejeitar) consultas de entrada que pareçam anormais. Por exemplo, caracteres especiais e URL estendido são dois tipos de entradas de usuário que podem ser exploradas por invasores para coletar informações sobre um banco de dados (antes de executar consultas maliciosas). Limitar o uso dessas entradas pode ajudar a minimizar a probabilidade de um ataque.
  • Evitar a entrada fornecida pelo usuário: as organizações também podem optar por evitar (ou seja,tratar como entrada, em vez de comandos ou condicionais) todas as entradas fornecidas pelo usuário, de modo que caracteres ou palavras específicos não possam ser usados para formar solicitações maliciosas.

Aplicar o acesso com menor privilégio

O acesso com menor privilégio é o princípio de dar aos usuários apenas o acesso aos recursos protegidos que sua função exige. Por exemplo, isso pode significar limitar o número de usuários que recebem privilégios de administrador em um banco de dados ou até mesmo conceder aos usuários acesso temporário de administrador que pode ser revogado posteriormente.

Restringir o acesso de usuários a um nível baseado em função também ajuda a minimizar o impacto de uma violação, pois o invasor que violar um banco de dados usando credenciais roubadas terá a mesma capacidade limitada de visualizar, modificar, roubar ou destruir dados protegidos. Pelo mesmo motivo, as organizações devem limitar o acesso compartilhado a bancos de dados em vários sites e aplicativos.

Como a Cloudflare ajuda a evitar a injeção de SQL

A Cloudflare ajuda as organizações a melhorar sua resiliência contra ataques de SQLi com um poderoso aplicativo e o portfólio de segurança de APIs:

  • O WAF da Cloudflare monitora os padrões de tráfego para detectar possíveis explorações de SQL, detecta desvios e variações nos tipos de ataque e usa tecnologias avançadas de aprendizado de máquina para adaptar conjuntos de regras de WAF aos métodos de ataque em constante evolução.
  • O Cloudflare D1 é um banco de dados SQL sem servidor que se integra nativamente ao Workers para implementar instruções preparadas e impedir que os usuários modifiquem ou excluam bancos de dados.