A05:2025 Injeção

Contexto

A categoria Injeção caiu duas posições, passando de #3 para #5 no ranking, mantendo sua posição relativa a A04:2025-Falhas Criptográficas e A06:2025-Design Inseguro. Injeção é uma das categorias mais testadas, com 100% das aplicações testadas para alguma forma de injeção. Ela apresentou o maior número de CVEs entre todas as categorias, com 37 CWEs mapeadas. Injeção inclui Cross-site Scripting (alta frequência/baixo impacto), com mais de 30 mil CVEs, e SQL Injection (baixa frequência/alto impacto), com mais de 14 mil CVEs. O número massivo de CVEs relatados para a CWE-79 (Improper Neutralization of Input During Web Page Generation ou 'Cross-site Scripting') reduz o impacto ponderado médio desta categoria.

Tabela de pontuação

CWEs Mapeadas	Taxa Máx. de Incidência	Taxa Méd. de Incidência	Cobertura Máxima	Cobertura Média	Exploit Ponderado Médio	Impacto Ponderado Médio	Total de Ocorrências	Total de CVEs
37	13,77%	3,08%	100,00%	42,93%	7,15	4,32	1.404.249	62.445

Descrição

Uma vulnerabilidade de injeção é uma falha na aplicação que permite que a entrada de um usuário não confiável seja enviada para um interpretador (ex: um navegador, banco de dados, linha de comando) e faz com que o interpretador execute partes dessa entrada como comandos.

Uma aplicação é vulnerável a ataques quando:

Dados fornecidos pelo usuário não são validados, filtrados ou sanitizados pela aplicação.
Consultas dinâmicas ou chamadas não parametrizadas sem escape sensível ao contexto são usadas diretamente no interpretador.
Dados não sanitizados são usados em parâmetros de busca de mapeamento objeto-relacional (ORM) para extrair registros adicionais e sensíveis.
Dados potencialmente hostis são usados diretamente ou concatenados. O SQL ou comando contém a estrutura e os dados maliciosos em consultas dinâmicas, comandos ou procedimentos armazenados (stored procedures).

Algumas das injeções mais comuns são SQL, NoSQL, comandos de SO, Mapeamento Objeto-Relacional (ORM), LDAP e Expression Language (EL) ou Object Graph Navigation Library (OGNL). O conceito é idêntico entre todos os interpretadores. A detecção é melhor alcançada por uma combinação de revisão de código-fonte junto com testes automatizados (incluindo fuzzing) de todos os parâmetros, headers, URL, cookies, JSON, SOAP e entradas de dados XML. A adição de ferramentas de teste de segurança de aplicação estática (SAST), dinâmica (DAST) e interativa (IAST) no pipeline de CI/CD também pode ser útil para identificar falhas de injeção antes da implantação em produção.

Uma classe relacionada de vulnerabilidades de injeção tornou-se comum em LLMs. Estas são discutidas separadamente no OWASP LLM Top 10, especificamente em LLM01:2025 Prompt Injection.

Como prevenir

A melhor maneira de prevenir a injeção requer manter os dados separados dos comandos e consultas:

A opção preferencial é usar uma API segura, que evita totalmente o uso do interpretador, fornece uma interface parametrizada ou migra para ferramentas de Mapeamento Objeto-Relacional (ORMs). Nota: Mesmo quando parametrizadas, as stored procedures ainda podem introduzir SQL Injection se o PL/SQL ou T-SQL concatenar consultas e dados ou executar dados hostis com EXECUTE IMMEDIATE ou exec().

Quando não for possível separar os dados dos comandos, você pode reduzir as ameaças usando as seguintes técnicas:

Use validação de entrada positiva no lado do servidor (allow-list). Esta não é uma defesa completa, pois muitas aplicações exigem caracteres especiais, como áreas de texto ou APIs para aplicações móveis.
Para qualquer consulta dinâmica residual, use escape de caracteres especiais usando a sintaxe de escape específica para aquele interpretador. Nota: Estruturas SQL, como nomes de tabelas, nomes de colunas e assim por diante, não podem sofrer escape e, portanto, nomes de estruturas fornecidos pelo usuário são perigosos. Este é um problema comum em softwares de geração de relatórios.

Aviso: estas técnicas envolvem a análise (parsing) e o escape de strings complexas, o que as torna propensas a erros e pouco robustas diante de pequenas mudanças no sistema subjacente.

Exemplos de cenários de ataque

Cenário #1: Uma aplicação usa dados não confiáveis na construção da seguinte chamada SQL vulnerável:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Um atacante modifica o valor do parâmetro 'id' em seu navegador para enviar: ' OR '1'='1. Por exemplo:

http://example.com/app/accountView?id=' OR '1'='1

Isso altera o significado da consulta para retornar todos os registros da tabela accounts. Ataques mais perigosos poderiam modificar ou excluir dados ou até mesmo invocar procedimentos armazenados.

Cenário #2: A confiança cega de uma aplicação em frameworks pode resultar em consultas que ainda são vulneráveis. Por exemplo, em Hibernate Query Language (HQL):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

Um atacante fornece: ' OR custID IS NOT NULL OR custID='. Isso ignora o filtro e retorna todas as contas. Embora o HQL tenha menos funções perigosas do que o SQL puro, ele ainda permite o acesso não autorizado a dados quando a entrada do usuário é concatenada em consultas.

Cenário #3: Uma aplicação passa a entrada do usuário diretamente para um comando do sistema operacional:

String cmd = "nslookup " + request.getParameter("domain");
Runtime.getRuntime().exec(cmd);

Um atacante fornece example.com; cat /etc/passwd para executar comandos arbitrários no servidor.