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 de segurança por muito tempo e choca muitos que ainda precisamos 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.
Analisamos quantas vulnerabilidades de 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 Security. Sem surpresa, ainda estamos vendo números chocantes de injeção de 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 de SQL, enquanto 10% das vulnerabilidades descobertas em projetos de código fechado foram vulnerabilidades de injeção de SQL. Isso pode não parecer muito, mas é francamente chocante que em 2024 ainda estamos lutando 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 ferramentas SAST e DAST para descobrir SQLi
Um dos elementos mais aterrorizantes do SQLi é que ele é facilmente descoberto por adversários, sendo frequentemente descrito como uma vulnerabilidade de fácil exploração. Parte dessa razão é porque ferramentas como DAST podem descobri-las automaticamente. Isso pode ser usado a nosso favor e podemos introduzir essas ferramentas em nosso processo de desenvolvimento para detectá-las precocemente.
Ferramentas SAST de próxima geração como o Aikido também permitem que você autocorrija os problemas diretamente da plataforma.
4. Implemente um firewall incorporado no aplicativo
Um firewall incorporado no aplicativo monitora 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 ele fica dentro do seu aplicativo e é capaz de tokenizar consultas esperadas e bloquear requisições que alteram a estrutura de comando da consulta.
Propaganda descarada ;) para o novo lançamento do Aikido: Zen, o firewall incorporado no aplicativo para sua tranquilidade em tempo de execução. Obtenha Zen e ele bloqueará automaticamente ataques de injeção críticos e ameaças de dia zero em tempo real, antes que 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.
Nem tudo é desgraça e melancolia (trocadilho intencional), no entanto, estamos vendo melhorias significativas em uma nova geração de ferramentas SAST que são muito mais eficazes na descoberta e correção dessas vulnerabilidades, o que tem a capacidade de mudar drasticamente o cenário de ameaças.
Por enquanto, me despedindo, não se esqueça de:
Descubra e corrija automaticamente injeção de SQL com Aikido AI SAST Autofix
Confira Zen e previna ataques de injeção assim que eles acontecem
Bônus: A História do SQL
Desde que começamos a falar sobre segurança em nossas aplicações, falamos sobre injeção de SQL. Ela foi inclusive destaque no número 7 no primeiro Top 10 OWASP em 2003, em 2010 foi incluída na categoria de injeção e ocupou o primeiro lugar até 2021. Um dos primeiros ataques em larga escala documentados envolvendo injeção de SQL foi quando a empresa de vestuário Guess foi alvo, resultando no vazamento de números de cartão de crédito. Desde então, a injeção de SQL tem sido um convidado regular nas manchetes de segurança.
