Ataques de injeção SQL: Tão velhos, mas ainda tão relevantes. Aqui está por que (gráficos)

Views: 497
0 0
Read Time:7 Minute, 17 Second

Estamos vivendo na Era de Ouro dos dados. Algumas empresas analisam para melhorar a si mesmas, outras trocam-na por lucro, nenhuma desiste livremente devido ao seu valor — para seus negócios, e para os criminosos, também.

SQL (Structured Query Language) é uma maneira extremamente popular de se comunicar com bancos de dados. Embora muitos novos bancos de dados usem sintaxe não-SQL, a maioria ainda é compatível com SQL. Isso torna o SQL uma ferramenta útil para quem quer acessar dados, não importa seus motivos.

Ataques de injeção SQL (ou SQLi) existem há quase 2 décadas. Eles nunca param de bater no Firewall de Aplicativos Web (WAF)do Imperva . Então temos uma riqueza de dados e experiência para compartilhar. Neste post, compartilharemos estatísticas e gráficos recentes de milhares de sites sob proteção imperva, bem como exemplos de ataque, e maneiras de proteger seu site.

Ataques comuns a aplicativos baseados em SQL

SQL Injection é uma técnica de injeção de código usada para atacar aplicações. Os atacantes podem usar ferramentas, scripts e até navegadores para inserir instruções SQL em campos de aplicativos. As declarações são então executadas pelo mecanismo do banco de dados. Esses ataques geralmente são usados para:

  • Identidade falsa
  • Adulterar os dados existentes
  • Roubar dados
  • Destruir dados
  • Alterar permissões de banco de dados

Os dados por trás de um aplicativo geralmente são críticos da missão, e é por isso que os ataques de injeção SQL são considerados muito graves.

Estatísticas de Imperva WAF

Todos os dias, o WAF da Imperva mitiga milhões de ataques de injeção sql nos sites que protegemos. Pelo menos 80% dos sites que protegemos são atacados todos os meses. Muitas centenas de nossos sites enfrentam ataques SQLi diariamente.

Abaixo você encontrará estatísticas sobre países, indústrias e ferramentas usadas em ataques que monitoramos.

sqli figure 1

Figura 1: Distribuição da indústria de sites — É bastante interessante que a indústria mais atacada seja a indústria da saúde, mas não surpreendente, já que o relatório de segurança cibernética de 2018 da BakerHostetler afirmou que era a indústria com mais violações de dados.

Não retratados são os bancos de dados mais atacados, que são (em ordem decrescente): Oracle, PostgreSQL, MySQL e MongoDB. Enquanto isso, as plataformas mais atacadas são WordPress, Drupal, Joomla e Quest.

sqli figure 2

Figura 2: País de site atacado vs origem do ataque — não é surpresa ver que os hackers tendem a atacar sites dentro do próprio país. É claro que há uma chance de ser exatamente o oposto – esses resultados podem refletir hackers usando VPNs/proxies que têm um ponto final no país que estão atacando, a fim de evitar o bloqueio geográfico.

Existem muitas explorações públicas SQLi massivamente usadas diariamente. Por exemplo: CVE-2017-8917 e CVE-2015-7858 são vulnerabilidades públicas joomla SQLi que foram usadas em 66.000 incidentes que monitoramos.

sqli figure 3

Figura 3: Principais scanners de vulnerabilidade — devido ao fato de que estamos contando incidentes, não solicitações, o número de cargas que cada scanner gera não tem efeito. Embora o SQLi Dumper leve o bolo, o scanner Joomla não fica muito atrás.

Monitoramos dezenas de milhares de IPs de ataque mensalmente, e usamos análises de ataque para encontrar IPs maliciosos e protegê-los. Reunimos algumas estatísticas interessantes analisando os IPs de ataque durante os últimos meses:

sqli figure 4

Figura 4: IPs que tentaram um ataque SQLi dia após dia. Em azul: a porcentagem de IPs que tentaram um ataque SQLi na corrente e no dia seguinte, fora dos IPs que tentaram um ataque SQLi no dia atual. Em laranja: o percentual de solicitações contendo uma tentativa SQLi enviada por esses IPs de ataque, do total de solicitações que contêm uma tentativa SQLi.

É curioso que, embora, em média, menos de um terço dos IPs ataquem dia após dia (linha azul), seus pedidos constituem mais de 80% das solicitações de SQLi (linha laranja). Isso pode ser devido a varreduras contínuas por vários scanners de vulnerabilidade. Essas ferramentas tendem a bombardear alvos em busca de vulnerabilidades, o que explica a alta relação IP-para-Solicitações.

sqli figure 5

Figura 5: Principais ferramentas de ataque — sendo extremamente genérico e amplamente utilizado como ele é, não é de surpreender que cURL toma uma fatia tão grande. No entanto, uma simulação revelou que a maioria das solicitações suspeitas enviadas com a CURL são, na verdade, check-ups pós-ataque, ou seja, hackers que foram bloqueados e depois usaram cURL para testar se ainda podem acessar o site. cURL é seguido firmemente por Python — arma de escolha do hackere Ruby — o código de idioma usado para escrever Metasploit.

Exemplos de ataque

Aqui estão alguns ataques populares que rastreamos em um mês recente:

VetorIncidentesDescrição
1 e 1=2 título de união selecionar senha de qianbo_admin634,566Tentando consultar senhas
1’A=0125,365Sondagem
N;O=D e 1=1nessus= ou 1=1-CONCAT(‘whs(‘,’)SQLi’)76,155Sondagem por scanners de vulnerabilidade:Veracode, Nessus e WhiteHat Security, respectivamente
‘ união selecionar unhex(hex(versão()) —848,096Tentando descobrir a versão do banco de dados
; ESPERAR POR ATRASO ’00:00:28′;1,226,955Sondagem cega — teste para atraso na resposta

Tabela 1: Exemplo de ataques de injeção SQL

Como proteger sua aplicação contra injeção SQL

Existem muitas maneiras de proteger sua aplicação contra ataques de injeção SQL. Alguns devem ser usados durante o desenvolvimento do aplicativo, outros devem ser usados após a implantação do aplicativo.

Fase de Desenvolvimento:

Use instruções preparadas – uma maneira de “modelar” seu SQL para torná-lo resistente à injeção SQL. Apenas certos valores de entrada podem ser enviados para o banco de dados, impossibilitando a execução de uma declaração diferente das modelada. Os valores que são transmitidos posteriormente usando um protocolo diferente não são compilados como o modelo de instrução. Portanto, a injeção SQL não pode ocorrer.

Aqui estão dois exemplos de código Python, com e sem uma declaração preparada. O código é baseado em um driver conector MySQL:

def add_employee(id: int, e-mail: str):sql = “”Inserir nos funcionários (id, e-mail)VALORES (%s, %s)”””cursor = conexão.cursor (preparado=Verdadeiro)cursor.execute(sql, (id, e-mail))cnx.commit()cursor.close()

Acima está um exemplo de código Python de uma instrução preparada. Os valores são enviados para o “método de execução” separados do texto SQL.

def add_employee(id: int, e-mail: str):sql = f””””INSERT INSERÇÃO EM funcionários (id, e-mail)VALORES ({id}, {email})”””cursor = conexão.cursor()cursor.execute(sql)

Acima está uma amostra de código Python sem uma instrução preparada. O e-mail pode conter instruções de injeção SQL que podem ser executadas pelo mecanismo do banco de dados.

Além das instruções preparadas, aqui estão outras maneiras de prevenir a injeção SQL durante o desenvolvimento e implantação de um aplicativo:

  • Higienização — Livre-se de qualquer caractere, palavra ou frase especial que possa ser maliciosa. Por exemplo, remover as palavras reservadas SELECIONE ou ENTRE EM CONTATO ou remova a frase ESPERAR POR ATRASO OU TABELA DE QUEDA. Esta não é a melhor prática, mas pode ser útil em alguns casos.
  • Escape — Escape personagens que têm um significado especial em SQL. Por exemplo, substitua uma cotação dupla por duas cotações únicas. Esta é uma maneira simples, embora propensa a erros.
  • Escapamento e verificação de padrões — os tipos de dados de parâmetros de número e booleano podem ser validados, enquanto os parâmetros string podem ser restritos a um padrão.
  • Limitações de permissão do banco de dados – Limitar as permissões do usuário aplicável apenas ao que é necessário, pois pode ajudar a reduzir a eficácia do ataque.

Pós-Desenvolvimento – Segurança de aplicativos:

  • Scanners de vulnerabilidade – Estes podem detectar vulnerabilidades de injeção SQL em seu aplicativo, que podem ser corrigidas posteriormente pela equipe de desenvolvimento. Lembre-se de que os aplicativos mudam constantemente – então você deve executar o scanner periodicamente.
  • Firewall de aplicativos web – OS WAFs também podem detectar e bloquear ataques em seu aplicativo.

Embrulhando

É essencial proteger seu produto contra a injeção SQL, tanto para garantir que ele funcione corretamente quanto para evitar vazamentos de dados.
É uma boa prática pensar em proteger contra a injeção SQL desde o seu ponto de vista, quando você escreve código que acessa o banco de dados. Este é o melhor momento para evitar que essas vulnerabilidades aconteçam, em vez de corrigi-las mais tarde. O processo de desenvolvimento deve incluir testes contra injeção SQL, seguidos por scanners externos.

Finalmente, um WAF é uma grande adição à proteção do seu produto. Ele irá protegê-lo contra vulnerabilidades que você perdeu, ao mesmo tempo dando-lhe tempo para corrigi-los o melhor que puder.

FONTE: IMPERVA

POSTS RELACIONADOS