Como um ataque de injeção SQL é executado
aplicativos que executam consultas SQL com base na entrada do usuário são potencialmente vulneráveis a ataques de injeção de SQL. Por exemplo, um aplicativo da web pode utilizar consultas SQL para implementar um processo de autenticação. O usuário fornece seu nome de usuário, que o aplicativo usa para procurar o hash da senha da conta desse usuário. Se o hash da senha fornecida pelo usuário corresponder a esse hash de senha, o usuário autenticará com êxito e obterá acesso à sua conta.
Se o aplicativo da web não realizar a validação do nome de usuário antes de incluí-lo em uma consulta SQL, um nome de usuário deliberadamente malformado poderá ser mal interpretado pelo programa. Por exemplo, as consultas SQL geralmente usam aspas simples (') ou aspas duplas (“) para denotar dados em um comando. Por exemplo, um comando para consultar o registro de um cliente em um banco de dados baseado no nome de usuário user pode ser SELECIONE *FROM clientes ONDE nome de usuário=”usuário”.
Um invasor que executa um ataque de injeção de SQL contra seu comando pode incluir aspas duplas em sua entrada para que alguns de seus dados sejam interpretados como código. Por exemplo, considere o nome de usuário usuário” OU “1”=”1.
Quando inserida na consulta SQL, a consulta se torna SELECIONE *FROM clientes ONDE nome de usuário=”usuário” OU “1”=”1”. Em vez de procurar registros onde o nome de usuário corresponde ao valor fornecido pelo usuário, esta consulta retornará registros que correspondam a uma das duas condições. O primeiro é o teste pretendido nome de usuário=”usuário”, que retornaria o registro do usuário.
A segunda condição é o teste “1”=”1”. Como isso é sempre verdade, retornará todos os registros do banco de dados. Isso pode permitir que o invasor extraia informações confidenciais sobre outros usuários ou potencialmente permitir que o invasor ignore a autenticação ou se autentique como outro usuário.
Tipos de injeção SQL
Os ataques SQLi podem ser usados para atingir diferentes propósitos e podem ser executados de várias maneiras. Os três principais tipos de SQLi incluem:
- SQLi em banda: Os ataques SQLi em banda usam o mesmo meio, como uma solicitação HTTP, para realizar seus ataques e coletar resultados. Duas formas comuns de ataques SQLi de entrada são ataques SQLi baseados em erros, que tentam gerar mensagens de erro que fornecem informações sobre o banco de dados de destino para uso em ataques, e SQL baseado em união, que usa o operador SQL UNION para mesclar SQL SELECT declarações.
- SQLi cego: Em um ataque SQLi cego, o invasor não recebe dados do servidor com base em suas solicitações. Em vez disso, o invasor modifica seus ataques com base no comportamento do servidor. Por exemplo, entradas diferentes podem fazer com que uma operação seja bem-sucedida ou falhe ou impactar a quantidade de tempo que uma operação leva para ser executada.
- SQLi fora de banda: Os ataques SQLi fora de banda executam um ataque em um meio e coletam dados em outro. Este ataque depende da disponibilidade de determinados recursos no servidor de banco de dados. Por exemplo, um invasor pode medir o sucesso de um ataque SQLi com base na capacidade de forçar o servidor de banco de dados a gerar solicitações HTTP ou DNS para um servidor controlado pelo invasor.
Como prevenir SQLI
Os ataques SQLi aproveitam a validação de entrada deficiente ao usar dados não confiáveis para comandos SQL. Muitos ataques SQLi envolvem o uso de um caractere inesperado, como aspas simples ou duplas, na entrada do usuário.
Realizar a validação de entrada antes de incluir dados fornecidos pelo usuário em consultas SQL pode ajudar a reduzir a ameaça de ataques SQLi. Por exemplo, um aplicativo pode restringir a entrada do usuário a um determinado conjunto de caracteres, como permitir apenas nomes de usuário alfanuméricos ou bloquear a inclusão de determinados caracteres na entrada do usuário. No entanto, a validação de entrada, embora importante, não é suficiente para proteger contra ataques de injeção de SQL. Os invasores podem contornar listas de permissões ou listas de bloqueio usando combinações inesperadas de caracteres para evitar bloqueios.
Por esta razão, as empresas também devem implantar um Firewall de aplicativo da web (Web Application Firewall, WAF) (WAF) ou, idealmente, Proteção de aplicativos da Web e API (WAAP) diante de aplicativo da web e API que realizam consultas SQL. Essas soluções podem ajudar a identificar e bloquear solicitações maliciosas que tentam explorar SQLi e outros ataques contra aplicativos da web e API.
Prevenção SQLi com Check Point
Os ataques SQLi são um dos muitos ataques que representam uma ameaça à segurança de uma organização. segurança do aplicativo (AppSec). As organizações precisam de soluções de segurança que possam proteger seus aplicativos e bancos de dados voltados para a Internet, tanto no local quanto na nuvem.
Check Point CloudGuard AppSec fornece recursos WAAP automatizados que aprendem como um aplicativo funciona e evita que solicitações ilegítimas e maliciosas cheguem a aplicativos vulneráveis. Para saber mais sobre o CloudGuard AppSec e sua capacidade de proteção contra SQLi e outros ataques, confira isto e-Book. Você também é bem-vindo inscreva-se para uma demogratuita para ver você mesmo os recursos do CloudGuard AppSec.
Opinião