A injeção de SQL (SQLi) tem uma história mais antiga do que o Internet Explorer (que, segundo a Geração Z, foi o início da civilização). Houve milhares de violações causadas por injeção de SQL e uma quantidade infindável de boas práticas e ferramentas bem documentadas para ajudar a evitá-las. Portanto, certamente, certamente aprendemos a lição com essas violações e a injeção de SQL já não é um problema.
Temos vindo a monitorizar o número de injecções SQL descobertas em projectos de código aberto e de código fechado para ver se estamos a melhorar. Com a recente notícia de que os dados roubados da violação de injeção SQL do MOVEit estão a ser vendidos a empresas como a Amazon, decidimos dar uma espreitadela ao nosso relatório State of Injection para 2025.
Spoiler, acontece que continuamos a ser péssimos a prevenir a injeção de SQL.
O que é a injeção de SQL?
A SQLi é uma vulnerabilidade que ocorre quando um programa utiliza dados não fidedignos do utilizador diretamente numa consulta a uma base de dados SQL. Um utilizador malicioso pode então inserir o seu próprio código e manipular a consulta, permitindo-lhe aceder a dados privados, contornar a autenticação ou apagar dados. O exemplo abaixo mostra como uma consulta SQL insegura para uma página de login do utilizador é vulnerável a um ataque de desvio de autenticação SQLi.
Existem muitos tipos diferentes de ataques de injeção, como injeção de código ou XSS (cross-site scripting). Mas a injeção de SQL tem desempenhado um papel proeminente nas violações de segurança desde há muito tempo e é um choque para muitos o facto de ainda termos de discutir este assunto em 2024.
Como ocorre um ataque SQLi
1. Consulta vulnerável
Exemplo de uma consulta vulnerável em que a entrada do utilizador é utilizada diretamente na consulta
2. Ataque de injeção de SQL
A SQL é injectada no campo de entrada do utilizador de uma página de autenticação
3. A consulta é executada com o payloadO payloadcomenta a verificação da palavra-passe, pelo que a consulta ignora este passo
Injeção SQL em números:
- 6,7% de todas as vulnerabilidades encontradas em projectos de código aberto são SQLi
- 10% para projectos de código fechado!
- Prevê-seum aumento do número total de injecções de SQL em projectos de código aberto (CVE que envolvem SQLi) de 2264 (2023) para 2400 (2024) .
- Em percentagem de todas as vulnerabilidades, a injeção de SQL está a tornar-se menos popular: uma diminuição de 14% e 17% para projetos de código aberto e de código fechado, respetivamente, de 2023 a 2024
- Mais de 20% dos projectos de código fechado analisados são vulneráveis à injeção de SQL quando começam a utilizar ferramentas de segurança
- Para as organizações vulneráveis à injeção de SQL, o número médio de locais de injeção de SQL é de quase 30 localizações separadas 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, comparámos esse número com o de projectos de código fechado que foram descobertos pela Aikido Security. Sem surpresa, continuamos a ver números chocantes de injeção de SQL em projectos fechados e de código aberto. 6,7% de todas as vulnerabilidades descobertas em projectos de código aberto em 2024 são vulnerabilidades de injeção de SQL, enquanto 10% das vulnerabilidades descobertas em projectos de código fechado são vulnerabilidades de injeção de SQL. Pode não parecer muito, mas é francamente chocante que em 2024 ainda estejamos a lutar para fazer face a 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 projectos de código aberto e uma redução de 17% em projectos de código fechado como percentagem de todas as vulnerabilidades encontradas. No entanto, espera-se que o número total de SQLi encontrados aumente de 2264 em 2023 para mais de 2400 até ao final de 2024 em projectos de código aberto.
Prevenir a injeção de SQL
Aparentemente, ainda não existe informação suficiente na Internet sobre como evitar a injeção de SQL, pelo que aqui está uma visão geral das opções disponíveis em 2025:
1. Utilizar Prepared Statements e Parameterized Queries
No exemplo no início desta publicação do blogue, mostrámos código vulnerável porque pega em dados do utilizador não confiáveis e utiliza-os diretamente numa consulta. Para evitar isso, devemos usar instruções preparadas, o que significa definir a consulta primeiro e adicionar a entrada do usuário depois. Isto separa o comando e o fluxo de dados, resolvendo completamente o problema. Uma óptima 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 consulta parametrizada
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id))
2. Validação do esquema/entrada do lado do servidor
A validação de entrada pode ser eficaz na prevenção de SQLi. Por exemplo, se a sua API espera um endereço de correio eletrónico ou um número de cartão de crédito, é fácil adicionar validação para esses casos.
3. Utilizar as ferramentas SAST e DAST para descobrir SQLi
Um dos elementos mais aterradores da SQLi é o facto de ser facilmente descoberta pelos adversários, sendo muitas vezes descrita como uma vulnerabilidade de baixo risco. Parte desta razão deve-se ao facto de ferramentas como a DAST poderem descobri-las automaticamente. Este facto pode ser utilizado em nosso proveito e podemos introduzir estas ferramentas no nosso processo de desenvolvimento para as detetar precocemente.
As ferramentas SAST de última geração, como o Aikido, também permitem a correção automática dos problemas diretamente a partir da plataforma.
4. Implementar uma firewall in-app
Uma firewall in-app monitoriza o tráfego e a atividade dentro da sua aplicação e pode detetar ataques, incluindo injeção e SQLi. Isto é mais eficaz do que um WAF tradicional, uma vez que se encontra dentro da sua aplicação e é capaz de tokenizar as consultas esperadas e bloquear os pedidos que alteram a estrutura de comando da consulta.
Plug sem vergonha ;) para o novo lançamento do Aikido: Zena firewall in-app para uma maior tranquilidade em tempo de execução. Adquira o Zen e ele bloqueará automaticamente ataques de injeção críticos e ameaças de dia zero em tempo real, antes que eles cheguem ao seu banco de dados.
5. Evitar a SQL dinâmica sempre que possível
A geração dinâmica de SQL através da concatenação de cadeias de caracteres é altamente vulnerável à injeção de SQL. Sempre que possível, utilize consultas estáticas e predefinidas e procedimentos armazenados que não dependam de conteúdo gerado pelo utilizador para a estrutura SQL.
6. Permitir a introdução de listas e fugas
Em alguns casos, não é possível evitar a SQL dinâmica, por exemplo, ao consultar tabelas dinâmicas ou quando se pretende ordenar por uma coluna e direção definidas pelo utilizador. Nesses casos, não tem outra opção senão confiar na listagem de permissões de expressões regulares ou na fuga. A fuga consiste em pegar na entrada do utilizador que contém caracteres perigosos utilizados em código como '>' e transformá-los numa forma segura. Ou adicionando barras invertidas antes deles ou transformando-os num código de símbolos. Note-se que isto é diferente não só para cada tipo de base de dados, mas também pode depender das definições de ligação, como o conjunto de caracteres.
Será que alguma vez veremos o fim da SQLi?
Embora haja alguma promessa no facto de termos visto uma diminuição 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 panorama. A verdade é que não consigo ver isto a melhorar muito. À medida que introduzimos mais ferramentas para nos ajudar a codificar mais rapidamente, os programadores estão a ficar menos em contacto com os princípios fundamentais da codificação e estas ferramentas de IA são notoriamente más a sugerir código vulnerável, incluindo vulnerabilidades de injeção.
No entanto, nem tudo é desgraça e tristeza (trocadilho intencional), estamos a assistir a melhorias significativas numa nova geração de ferramentas SAST que são muito mais eficazes na descoberta e correção destas vulnerabilidades e que têm a capacidade de alterar drasticamente o panorama das ameaças.
Por agora, vou-me embora, mas não se esqueçam:
Descubra e corrija automaticamente a injeção de SQL com o Aikido Correção automática AI SAST
Finalizar compra Zen e evitar ataques de injeção à medida que acontecem
Bónus: História da SQL ao longo da história
Desde que começámos a falar de segurança nas nossas aplicações, temos falado de injeção de SQL. Em 2010, foi incluída na categoria de injeção e ocupou o primeiro lugar até 2021. Um dos primeiros ataques em grande escala documentados envolvendo injeção de SQL foi quando a empresa de vestuário Guess foi visada, resultando na fuga de números de cartões de crédito. Desde então, a injeção de SQL tem sido um convidado regular nas manchetes de segurança.
Bónus Pt 2 - Veja Injection Attacks 101 para obter uma introdução às injecções de SQL, injecções de código e XSS
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)