O Estado da Injeção SQL

SQL injection (SQLi) tem uma história mais antiga que o Internet Explorer (que, segundo a Geração Z, foi o início da civilização). Milhares de violações foram causadas por SQL injection e há uma quantidade infinita de boas práticas e ferramentas bem documentadas para ajudar a preveni-lo. Então, certamente, certamente aprendemos a lição com essas violações e SQLi não é mais um problema.

Temos monitorado o número de injeções de SQL descobertas em projetos de código aberto e fechado para verificar se estamos melhorando. Com as notícias recentes de que dados roubados da falha de injeção de SQL do MOVEit estão sendo vendidos para empresas como a Amazon, decidimos dar a você uma prévia do nosso próximo relatório 'Estado da Injeção' para 2025.

Spoiler: descobrimos que ainda somos péssimos em prevenir SQL injection.

O que é injeção de SQL?

SQLi é uma vulnerabilidade que ocorre quando um programa utiliza entrada de usuário não confiável diretamente em uma consulta a um banco de dados SQL. Um  usuário malicioso pode então inserir seu próprio código e manipular a consulta, permitindo-lhe acessar dados privados, contornar a autenticação ou excluir dados. O exemplo abaixo mostra como uma consulta SQL insegura para uma página de login de usuário é vulnerável a um ataque de bypass de autenticação por SQLi.

Existem muitos tipos diferentes de ataques de injeção, como injeção de código ou cross-site scripting. Mas o SQLi, especificamente, tem desempenhado um papel proeminente em violações há muito tempo e é um choque para muitos que ainda precisemos discutir isso em 2024.

Como um ataque SQLi acontece

1. Consulta vulnerável
Exemplo de uma consulta vulnerável onde a entrada do usuário é usada diretamente na consulta

2. Ataque de injeção SQL
SQL é injetado no campo de entrada do usuário de uma página de autenticação

3. Consulta executada com payloadO payload comenta a verificação de senha para que a consulta ignore esta etapa

SQL injection em números:

• 6,7% de todas as vulnerabilidades encontradas em projetos de código aberto são SQLi
• 10% para projetos de código fechado!
• Um aumento no número total de injeções de SQL em projetos de código aberto (CVE’s que envolvem SQLi) de 2264 (2023) para 2400 (2024) é esperado.
• Como porcentagem de todas as vulnerabilidades, a injeção de SQL está se tornando menos popular: uma diminuição de 14% e 17% para projetos de código aberto e código fechado, respectivamente, de 2023 a 2024.
• Mais de 20% dos projetos de código fechado escaneados são vulneráveis a SQL injection quando começam a usar ferramentas de segurança
• Para organizações vulneráveis a injeção de SQL, o número médio de locais de injeção de SQL é de quase 30 pontos separados no código.

Analisámos quantas vulnerabilidades SQLi foram descobertas em pacotes de código aberto em 2023 e até agora em 2024. Em seguida, comparamos isso com projetos de código fechado que foram descobertos pela Aikido . Sem surpresa, continuamos a ver números chocantes de injeção SQL em projetos de código fechado e aberto. 6,7% de todas as vulnerabilidades descobertas em projetos de código aberto em 2024 são vulnerabilidades de injeção SQL, enquanto 10% das vulnerabilidades descobertas em projetos de código fechado eram vulnerabilidades de injeção SQL. Isso pode não parecer muito, mas é francamente chocante que, em 2024, ainda estejamos a lutar para lidar com algumas das vulnerabilidades mais básicas que conhecemos.

A única boa notícia que temos é que este número representa uma diminuição de 14% em relação a 2023 em projetos open-source e uma redução de 17% em projetos closed-source como porcentagem de todas as vulnerabilidades encontradas. No entanto, o número total de SQLi encontrados deve aumentar de 2264 em 2023 para mais de 2400 até o final de 2024 em projetos open-source.

Prevenindo SQL injection

Aparentemente, ainda não há informações suficientes na internet sobre como prevenir injeção de SQL, então aqui está uma visão geral das opções disponíveis em 2025:

1. Use Declarações Preparadas e Consultas Parametrizadas

No exemplo no início deste post do blog, mostramos um código vulnerável porque ele recebe entrada de usuário não confiável e a utiliza diretamente em uma consulta. Para evitar isso, devemos usar prepared statements, o que significa definir sua consulta primeiro e depois adicionar a entrada do usuário. Isso separa o fluxo de comando e dados, resolvendo o problema completamente. Uma ótima solução, mas nem sempre possível ou utilizada!

import sqlite3
conn = sqlite3.connect('example.db')
cursor = conn.cursor()
user_id = 5  # Exemplo de entrada segura
# Consulta segura usando query parametrizada

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id))

2. Validação de entrada/esquema no lado do servidor

A validação de entrada pode ser eficaz na prevenção de SQLi. Por exemplo, se sua API espera um endereço de e-mail ou um número de cartão de crédito, é fácil adicionar validação para esses casos.

3. Use DAST SAST DAST para descobrir SQLi

Um dos elementos mais assustadores do SQLi é que ele é facilmente descoberto por adversários, sendo frequentemente descrito como uma vulnerabilidade fácil de explorar. Parte do motivo é que ferramentas como DAST descobri-las automaticamente. Isso pode ser usado a nosso favor e podemos introduzir essas ferramentas no nosso processo de desenvolvimento para detectá-las antecipadamente.

SAST de última geração, como Aikido permitem corrigir automaticamente os problemas diretamente na plataforma.

4. Implementar um firewall incorporado no aplicativo

Um firewall incorporado no aplicativo o tráfego e a atividade dentro do seu aplicativo e pode detectar ataques, incluindo injeção e SQLi. Isso é mais eficaz do que um WAF tradicional, pois fica dentro do seu aplicativo e é capaz de tokenizar consultas esperadas e bloquear solicitações que alteram a estrutura de comando da consulta.

Propaganda descarada ;) para o novo lançamento Aikido: Zen, o firewall incorporado no aplicativo tranquilidade durante a execução. Obtenha o Zen e ele bloqueará automaticamente ataques críticos de injeção e ameaças de dia zero em tempo real, antes que eles cheguem ao seu banco de dados.

5. Evite SQL Dinâmico Sempre que Possível

A geração dinâmica de SQL por meio de concatenação de strings é altamente vulnerável a injeção de SQL. Sempre que possível, atenha-se a consultas estáticas e predefinidas e a stored procedures que não dependam de conteúdo gerado pelo usuário para a estrutura SQL.

6. Listagem de permissões e escape

Em alguns casos, você não pode evitar o SQL Dinâmico, como ao consultar tabelas dinâmicas ou quando deseja ordenar por uma coluna e direção definidas pelo usuário. Nesses casos, você não tem outra opção senão confiar na allowlisting de expressões regulares ou no escaping. Escaping é pegar a entrada do usuário que contém caracteres perigosos usados no código, como '>' e transformá-los em uma forma segura. Seja adicionando barras invertidas antes deles ou transformando-os em um código de símbolo. Observe que isso é diferente não apenas para cada tipo de banco de dados, mas também pode depender das configurações de conexão, como o charset.

Veremos o fim do SQLi?

Embora haja alguma promessa no fato de termos visto uma diminuição um tanto significativa no número de vulnerabilidades SQLi encontradas, ainda é desanimador ver que uma vulnerabilidade que antecede o jogo DOOM ainda é uma ameaça tão significativa para o cenário. A verdade é que não vejo isso melhorando muito. À medida que introduzimos mais ferramentas para nos ajudar a codificar mais rápido, os desenvolvedores estão perdendo contato com os princípios fundamentais de codificação, e essas ferramentas de IA são notoriamente ruins em sugerir código vulnerável com vulnerabilidades de injeção incluídas.

No entanto, nem tudo é desgraça e tristeza (trocadilho intencional), pois estamos a observar melhorias significativas numa nova geração de SAST que são muito mais eficazes na deteção e correção dessas vulnerabilidades, tendo a capacidade de mudar drasticamente o panorama das ameaças.

Por enquanto, me despedindo, não se esqueça de:

Descubra e corrija automaticamente injeções SQL com Aikido AI SAST

Confira Zen e previna ataques de injeção assim que eles acontecem

Bônus: A História do SQL

Desde que começámos a falar sobre segurança nas nossas aplicações, temos falado sobre injeção SQL. Ela chegou a ocupar o 7.º lugar no primeiro Top 10 OWASP em 2003 e, em 2010, foi incluída na categoria de injeção, ocupando o 1.º lugar até 2021. Um dos primeiros ataques em grande escala documentados envolvendo injeção SQL foi quando a empresa de vestuário Guess foi alvo de um ataque que resultou na fuga de números de cartões de crédito. Desde então, a injeção SQL tem sido um tema recorrente nas manchetes sobre segurança.

Bônus Parte 2 - Confira Ataques de Injeção 101 para ter uma introdução a injeções SQL, injeções de código e XSS