🛡️ CVE-2024-57521 Notas de auditoria da vulnerabilidade de injeção SQL pós-autenticação no RuoYi-Vue

0. Declaração do projeto

Este repositório destina-se exclusivamente a fins de pesquisa de segurança e educação. Não utilize as técnicas contidas neste documento para realizar ataques não autorizados. Todos os testes foram realizados em ambiente local de auditoria estática de código.

1. Visão geral da vulnerabilidade

ID CVE: CVE-2024-57521
Componente afetado: Sistema de gerenciamento de permissões RuoYi-Vue (módulo ruoyi-generator)
Versões afetadas: <= v4.7.9
Tipo de vulnerabilidade: Injeção SQL pós-autenticação (blind SQL injection booleana / CWE-89)
Pontuação CVSS: 10.0 (Critical)
Método de auditoria: Auditoria puramente estática de código (análise de código-fonte)

2. Análise de fluxo de dados na auditoria (Source → Filter → Sink)

2.1 Source (ponto de entrada de dados do usuário)

Localização do arquivo: ruoyi-generator/src/main/java/com/ruoyi/generator/controller/GenController.java

Código principal:

@PostMapping("/createTable")
public AjaxResult createTableSave(@RequestParam("sql") String sql, @RequestParam("tplWebType") String tplWebType)
{
    try
    {
        SqlUtil.filterKeyword(sql); // 在进入业务前调用过滤器

Análise: um administrador do backend pode passar qualquer instrução SQL de criação de tabela através do parâmetro sql de uma requisição HTTP POST. O ponto de entrada não impõe restrições suficientes à entrada do usuário e a encaminha diretamente para o filtro subsequente.

Evidência em captura de tela: 03-SqlUtil-filterKeyword

2.2 Filter (falha crítica do filtro)

· Localização do arquivo: ruoyi-common/src/main/java/com/ruoyi/common/utils/sql/SqlUtil.java

Código do defeito central:

// 第16行：黑名单定义，注意关键词带有【尾随空格】
public static String SQL_REGEX = "\u0008|%0A|and |extractvalue|updatexml|sleep|information_schema|exec...";

// 第61-66行：过滤逻辑
String normalizedValue = value.replaceAll("\\p{Z}|\\s", ""); // 先清空了输入里的所有空格
String[] sqlKeywords = StringUtils.split(SQL_REGEX, "\\|");
for (String sqlKeyword : sqlKeywords)
{
    if (StringUtils.indexOfIgnoreCase(normalizedValue, sqlKeyword) > -1)
    {
        throw new UtilException("请求参数包含敏感关键词" + sqlKeyword + "，可能存在安全风险");
    }
}

Análise do defeito: o filtro primeiro executa replaceAll("\p{Z}|\s", "") para remover todos os caracteres de espaço em branco da entrada. No entanto, as palavras-chave na lista negra SQL_REGEX (como "and ", "select ") possuem espaço à direita. Isso faz com que a correspondência falhe inevitavelmente; basta o atacante usar %0b (tabulação vertical) no lugar do espaço após a palavra-chave para contornar perfeitamente a verificação da lista negra.

Evidência em captura de tela:

2.3 Sink (ponto perigoso)

· Localização do arquivo: ruoyi-generator/src/main/resources/mapper/generator/GenTableMapper.xml

Código principal:

<update id="createTable">
    ${sql}
</update>

Análise: no MyBatis, ${} concatena a string diretamente, em vez de usar a pré-compilação segura #{} . Isso faz com que o SQL malicioso que já contornou o filtro seja enviado ao banco de dados para execução. Esta é uma vulnerabilidade típica da combinação "filtragem por lista negra + concatenação insegura".

Evidência em captura de tela:

3. Lógica do PoC e ideias de exploração

3.1 Técnica de contorno

· Método: o atacante usa %0b (a tabulação vertical do MySQL, que está dentro do escopo de correspondência de \s) para substituir os espaços na instrução SQL.

3.2 Análise da cadeia de execução completa

Enviar via HTTP um Payload com %0b: CREATE table xxx as SELECT%0b111 FROM sys_job WHERE 1=0 AND%0bIF(<condição>, 1, 1/0);
O Payload entra no método filterKeyword, %0b é correspondido por \s e removido, e a string se torna select111 e andIF.
Como a lista negra contém "select " (com espaço), "select111".indexOf("select ") retorna -1, contornando com sucesso a interceptação da lista negra.
O parâmetro perigoso entra no MyBatis, e ${sql} o concatena ao banco de dados.
Ao analisar, o MySQL considera %0b um caractere de espaço em branco válido, e o SQL é injetado e executado com sucesso.

· Princípio de detecção: usar IF(<condição>, 1, 1/0) como detector de blind SQL injection booleana. · Condição falsa: dispara erro de divisão por zero, o servidor retorna HTTP 500. · Condição verdadeira: normal, sem erro. · Método de extração: usar busca binária para adivinhar os dados do banco de dados bit a bit.

4. Resumo e recomendações de correção

4.1 Resumo da causa da vulnerabilidade

Esta vulnerabilidade é um contorno típico causado por "correção incompleta". Ao corrigir uma injeção SQL semelhante anterior, os desenvolvedores introduziram um mecanismo de lista negra, mas ignoraram que a lista negra depende de espaços, e a lógica prévia de remoção de espaços quebra as condições de correspondência da lista negra, resultando em um novo contorno (CVE-2024-57521).

4.2 Recomendações de correção

· Abolir o mecanismo de lista negra: não dependa de listas negras; o mecanismo de lista branca é a base da segurança. · Usar pré-compilação: alterar ${sql} no MyBatis para o modo de pré-compilação #{} . Se for necessário passar SQL dinamicamente (como criação de tabela, Order By), deve-se usar análise estrita de árvore de sintaxe abstrata (AST) ou validação estrita de parâmetros. · Aprimorar o filtro: se for indispensável usar lista negra, é preciso remover os espaços à direita das palavras-chave da lista negra e realizar normalização unificada antes da comparação (como converter tudo para minúsculas e substituir %0b etc. por espaços).

5. Links de referência

· NVD - CVE-2024-57521 · Repositório RuoYi-Vue no Gitee

Mais Populares

CVE-2024-57521-RuoYi-SQLi