SQL Injection: o que é, como se proteger e exemplos

Em um contexto de transformação digital e avanço dos crimes cibernéticos, é importante conhecer as vulnerabilidades mais exploradas pelos cibercriminosos para proteger os dados de sua empresa ou aplicação . A SQL Injection é uma delas.

Nos próximos apresentados, vamos explicar o que é SQL Injection e mostrar alguns exemplos comuns, explicando como esse tipo de vulnerabilidade é encontrado e explorador.

Além disso, vamos falar também sobre a criação de uma boa estratégia para evitar a SQL Injection. Continue a leitura.

O que é SQL Injection?

A SQL Injection ou injeção de SQL pode ser definida como uma vulnerabilidade de segurança da Web que possibilita a interferência, por um cibercriminoso, nas consultas que um aplicativo faz em determinado banco de dados .

Isso significa que o invasor em questão poderá visualizar dados que normalmente o usuário não consegue recuperar.

Vários tipos de dados podem estar envolvidos, incluindo dados de terceiros e quaisquer informações que o aplicativo esteja programado para acessar.

Isso pode comprometer, inclusive, o cumprimento das diretrizes da Lei Geral de Proteção de Dados ( LGPD ).

Muitas vezes, o invasor faz alterações ou exclui os dados, causando mudanças persistentes no conteúdo e no comportamento do aplicativo .

Os cibercriminosos também podem escalar um ataque de SQL Injection e comprometer o servidor subjacente ou alguma outra infraestrutura de back-end.

Outra estratégia muito utilizada pelos invasores é o ataque de negação de serviço , que torna o aplicativo totalmente improdutivo.

Quando um ataque de SQL Injection é bem-sucedido, o acesso indevido a dados, senhas e informações pessoais pode resultar em grandes prejuízos para uma empresa.

Em alguns casos, um invasor pode obter um backdoor persistente nos sistemas de uma organização, levando a um comprometimento de longo prazo que pode passar despercebido por um período longo.

Esses danos podem ser irreparáveis, considerando que os consumidores estão cada vez mais conscientes a respeito da importância da cibersegurança e da proteção de dados .

Isso significa que, além de perder clientes, a empresa pode ter sua consideração tolerada de maneira incisiva, comprometendo os negócios por muito tempo

Além disso, os gestores também precisam se preocupar com os danos imediatos referentes, por exemplo, a processos judiciais e punições por descumprimento das diretrizes legais.

Muitos casos de violação de dados que tornaram-se públicos nos últimos anos são resultados de investigações cibercriminosas experimentadas na SQL Injection.

5 exemplos de SQL Injection

Em termos práticos, a SQL Injection não corresponde a apenas uma vulnerabilidade. Existem diversas variedades de vulnerabilidades, ataques e técnicas de SQL Injection.

Eles podem surgir em diferentes situações, cujos exemplos mais comuns citaremos a seguir.

Ao recuperar dados ocultos

Recuperando dados ocultos, é possível promover mudanças em uma consulta SQL para retornar resultados adicionais.

Imagine, por exemplo, um aplicativo de compras que conta com produtos classificados em diferentes categorias.

Quando o usuário clica em uma delas, que vamos chamar de categoria X, o navegador solicita uma URL: http://website-inseguro.com.br/produtos?categorias=categoriaX

Isso vai fazer com que o aplicativo promova uma consulta SQL para recuperar os detalhes sobre os produtos relevantes dentro do banco de dados que correspondem à categoria X.

A consulta é exposta da seguinte forma: SELECIONAR * produtos ONDE categoria = categoria X e liberados = 1

Nesse caso, a consulta solicitou um retorno do banco de dados com todos os detalhes da tabela de produtos em que a categoria é X e os produtos lançados correspondem a 1.

A restrição “liberado = 1” é utilizada para ocultar produtos que não estão liberados. Para os produtos não lançados, presumivelmente o resultado é = 0.

O aplicativo não coloca em prática nenhuma defesa contra os ataques de SQL Injection e, assim, o cibercriminoso pode construir um ataque como: http://website-inseguro.com.br/produtos?categoria=categoriaX'- -

Isso vai resultar na seguinte consulta SQL: SELECIONAR * produtos ONDE categoria = categoria X'-- e lançados = 1.

A questão é que a sequência similar seguida dos dois traços “--” é um indicador de comentário em SQL e significa que o restante da consulta é interpretado como um comentário.

Isso vai efetivamente remover todo o restante da consulta , ou seja, ela não incluirá mais o “E lançados = 1”.

Assim, todos os produtos são exibidos, incluindo aqueles não liberados ou lançados, o que torna a consulta inútil.

A partir desse processo, o invasor pode fazer com que o aplicativo exiba todos os produtos em qualquer uma das categorias , inclusive aqueles que ele não conhece:

http://site-inseguro.com.br/produtos?categoria=categoriaX'+OR+1=1–

O resultado da consulta SQL será: SELECIONAR * DE produtos ONDE categoria = categoria X OU 1=1–' E lançados = 1

Essa consulta alterada vai retornar com todos os itens da categoria X ou em que 1=1. Como 1=1 é sempre verdadeiro, a consulta vai retornar com todos os itens.

Ao subverter a lógica do aplicativo

Nessa situação, é possível alterar uma consulta para interferir diretamente nos parâmetros da aplicação .

Considere um aplicativo em que os usuários façam login a partir de um nome de usuário e uma senha.

Suponhamos que determinado usuário utilize o nome cliente01 e a senha sigilo01. Nesse caso, o aplicativo vai verificar as credenciais a partir da seguinte consulta SQL:

selecionar * de usuários ONDE nome de usuário = 'cliente01' E senha = 'sigilo01'

Se essa consulta retornar com os detalhes de um usuário, o login ou credenciamento será bem-sucedido. Caso contrário, ele será rejeitado.

Dessa forma, o invasor poderá executar o login como qualquer usuário sem uma senha simplesmente recorrendo à utilização da sequência de comentário SQL -- para remover a verificação de senha associada à cláusula “ONDE” da consulta.

Por exemplo, ele pode enviar o nome de usuário administrador-- e uma senha em branco, gerada na seguinte consulta:

SELECIONAR * DE usuários ONDE nome de usuário = 'administrador'--' E senha = ''

Essa consulta vai retornar com o usuário cujo nome de usuário é 'administrador' e registrar com sucesso o cibercriminoso como sendo esse usuário.

Recuperando dados de outras tabelas de bancos de dados

Nesse tipo de SQL Injection, é possível recuperar dados de diferentes tabelas de bancos de dados.

Nas situações em que os resultados de uma consulta SQL são retornados nas respostas do aplicativo, o invasor pode utilizar uma vulnerabilidade de SQL Injection para recuperar os dados de outras tabelas nos bancos de dados.

Esse procedimento é feito a partir da utilização da palavra-chave “UNION”, que permite a execução de uma consulta adicional e a anexação dos resultados à consulta original.

Dessa forma, o aplicativo pode ser executado, por exemplo, a seguinte consulta contendo uma categoria selecionada pelo usuário “categoriaX”:

SELECIONAR nome, descrição DE produtos ONDE categoria = 'categoriaX'

Então, o cibercriminoso pode enviar a seguinte entrada: UNION SELECIONAR nome de usuário, senha DE usuários-- .

Isso vai fazer com que o aplicativo traga como resultados da consulta todos os nomes de usuários e senhas junto aos nomes e filmagem dos produtos.

Examinando o banco de dados

A partir desse tipo de SQL Injection, é possível extrair informações sobre a versão e a estrutura do banco de dados em questão.

Após a identificação inicial de uma vulnerabilidade de SQL Injection, normalmente é útil a obtenção de algumas informações adicionais sobre o próprio banco de dados.

Porém, o problema é que muitas vezes essas informações podem abrir novos caminhos para a exploração dos cibercriminosos.

São diversas as maneiras pelas quais você pode consultar os detalhes da versão do banco de dados em questão. Isso vai depender do tipo de banco de dados.

No Oracle, por exemplo, você pode executar uma consulta: SELECTIONAR * DE v$version.

Você também pode definir quais tabelas do banco de dados existem e quais colunas elas contêm.

Na maioria dos bancos de dados, é possível executar a seguinte consulta para listar as tabelas:

SELECIONAR * DE information_schema.table.

Vulnerabilidades de SQL Injections cegas

Nesse tipo de vulnerabilidade de SQL Injection, os resultados de uma consulta que você controla não estão presentes nas respostas do aplicativo.

Nessas instâncias, as vulnerabilidades são chamadas de “SQL Injections cegas”, o que significa que o aplicativo não vai retornar os resultados da consulta SQL ou demonstrar os resultados de possíveis erros de bancos de dados em suas respostas.

Como SQL Injections cegas também podem ser exploradas com o propósito de acessar dados não autorizados, mas, nesse caso, as técnicas envolvidas são mais complexas e difíceis de executar.

Conforme a natureza da vulnerabilidade e também do banco de dados envolvidos, uma das técnicas que podem ser utilizadas na exploração das SQL Injections cegas é a alteração da lógica da consulta para acionar uma diferença detectável na resposta do aplicativo, dependendo da veracidade de uma única condição .

Esse processo pode envolver, por exemplo, o acionamento condicional de um erro , como uma divisão por zero, ou uma nova condição com alguma lógica booleana.

Outra possibilidade de técnica para explorar uma SQL Injection cega é o acionamento de um atraso no processamento da consulta .

Isso vai possibilitar a inferência sobre a veracidade da condição com base no tempo que o aplicativo leva para responder.

Você também pode acionar uma interação de rede fora da banda , utilizando técnicas OAST, que são poderosas e operam em situações em que as outras técnicas não funcionam.

A partir desse tipo de técnica, frequentemente, é possível extrair dados diretamente por meio do canal fora da banda, colocando esses dados, por exemplo, em uma pesquisa de DNS para um domínio que você controla.

Como detectar vulnerabilidades de SQL Injection?

Como vimos, são diversos os tipos de SQL Injection que podem comprometer a segurança da sua aplicação e até da sua empresa.

Mas uma boa notícia é que a maioria deles pode ser encontrada de maneira rápida e confiável a partir da utilização de um scanner de vulnerabilidades .

Uma SQL Injection também pode ser detectada manualmente com o uso de um conjunto sistemático de testes em cada ponto de entrada da aplicação. Isso normalmente envolve:

• O envio do caractere de aspas simples (') ea procura por erros ou outras anomalias;
• A submissão de alguma sintaxe específica de SQL Injection para o valor base do ponto de entrada e para um valor diferente e procura por diferenças sistemáticas nas respostas do aplicativo;
• A submissão de condições booleanas, como OU 1=1 OU 1=2 e procura por diferença nas respostas do aplicativo;
• O envio de cargas projetadas para acionar atrasos de tempo quando executadas em uma consulta SQL e procura por variação no tempo necessário para a resposta;
• O envio de cargas OAST projeta para acionar uma interação de rede fora de banda quando executado em uma consulta SQL e monitoramento de quaisquer sofrimentos resultantes.

Como evitar as vulnerabilidades de SQL Injection?

Grande parte das instâncias de SQL Injection pode ser evitada a partir das consultas parametrizadas , também chamadas de instruções preparadas , ao invés da concatenação de strings na consulta.

As consultas parametrizadas podem ser aplicadas para qualquer situação em que a entrada não confiável como dados da consulta , incluindo a cláusula ONDE e os valores em uma instrução do tipo INSERT ou UPDATE.

Elas não podem ser usadas para lidar com entradas não aguardavam em outras partes da consulta, como, por exemplo, nomes de mesas ou colunas.

A funcionalidade do aplicativo responsável pela colocação dos dados não baixados nestas partes da consulta vai precisar adotar uma abordagem diferente, como uma lista de valores de entrada permitidos .

Também é possível continuar a uma lógica diferente para fornecer o comportamento necessário.

Para alcançar a eficácia em uma consulta parametrizada na prevenção de vulnerabilidades de SQL Injection, a cadeia de caracteres utilizada na consulta deve ser sempre uma constante embutida no código .

Isso significa que ela nunca poderá conter nenhum dado variável de qualquer origem, ou seja, a decisão não pode ser tomada caso a caso.

Evitar uma SQL Injection não é uma tarefa tão complicada, mas é preciso ficar atento, pois é muito frequente o cometimento de erros sobre a possível origem dos dados e também em relação às alterações em outro código que violam suposições sobre quais dados estão corrompidos.

Para que sua estratégia de prevenção seja bem-sucedida, as ações podem resistir às vulnerabilidades de SQL Injection devem integrar uma gestão de riscos eficiente e robusta .

Essa prevenção não pode ser uma ação individualizada, já que a proteção de dados deve ser uma meta constante que passa por melhorias progressivas dentro da sua gestão de TI.

Assim, para que as vulnerabilidades de SQL Injection sejam combatidas eficientemente em sua empresa e em sua aplicação, recomendamos também a leitura do artigo sobre gestão de riscos cibernéticos .

Conheça a EcoTrust e utilize-a para identificar vulnerabilidades de SQL Injection. Agendar uma Demo .