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.
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.
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.
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:
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.
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:
Vetor | Incidentes | Descrição |
1 e 1=2 título de união selecionar senha de qianbo_admin | 634,566 | Tentando consultar senhas |
1’A=0 | 125,365 | Sondagem |
N;O=D e 1=1nessus= ou 1=1-CONCAT(‘whs(‘,’)SQLi’) | 76,155 | Sondagem por scanners de vulnerabilidade:Veracode, Nessus e WhiteHat Security, respectivamente |
‘ união selecionar unhex(hex(versão()) — | 848,096 | Tentando descobrir a versão do banco de dados |
; ESPERAR POR ATRASO ’00:00:28′; | 1,226,955 | Sondagem 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