🛡️ CVE-2024-57521 RuoYi-Vue SQL-Injection nach Authentifizierung – Audit-Notizen

0. Projekt-Erklärung

Dieses Repository dient ausschließlich Sicherheitsforschung und Bildungszwecken. Nutzen Sie die in diesem Dokument beschriebenen Techniken nicht für unautorisierte Angriffe. Alle Tests wurden in einer lokalen statischen Code-Audit-Umgebung durchgeführt.

1. Schwachstellenübersicht

CVE-Nummer: CVE-2024-57521
Betroffene Komponente: RuoYi-Vue Berechtigungsverwaltungssystem (ruoyi-generator-Modul)
Betroffene Versionen: <= v4.7.9
Schwachstellentyp: SQL-Injection nach Authentifizierung (Blind-Boolean-Injection / CWE-89)
CVSS-Bewertung: 10.0 (Critical)
Audit-Methode: Reines statisches Code-Audit (Quellcode-Analyse)

2. Datenfluss-Audit-Analyse (Source → Filter → Sink)

2.1 Source (Benutzereingabe-Einstiegspunkt)

Dateiposition: ruoyi-generator/src/main/java/com/ruoyi/generator/controller/GenController.java

Relevanter Code:

@PostMapping("/createTable")
public AjaxResult createTableSave(@RequestParam("sql") String sql, @RequestParam("tplWebType") String tplWebType)
{
    try
    {
        SqlUtil.filterKeyword(sql); // Ruft den Filter vor dem Eintritt in die Geschäftslogik auf

Analyse: Ein Backend-Administrator kann über den sql-Parameter einer HTTP-POST-Anfrage beliebige Datenbank-DDL-Anweisungen übergeben. Der Einstiegspunkt schränkt Benutzereingaben nicht ausreichend ein und übergibt sie direkt an den nachfolgenden Filter.

Screenshot-Beleg: 03-SqlUtil-filterKeyword

2.2 Filter (kritischer Fehler des Filters)

· Dateiposition: ruoyi-common/src/main/java/com/ruoyi/common/utils/sql/SqlUtil.java

Kernfehler-Code:

// Zeile 16: Blacklist-Definition, beachten Sie die 【nachgestellten Leerzeichen】 bei den Schlüsselwörtern
public static String SQL_REGEX = "\u0008|%0A|and |extractvalue|updatexml|sleep|information_schema|exec...";

// Zeilen 61-66: Filterlogik
String normalizedValue = value.replaceAll("\\p{Z}|\\s", ""); // Entfernt zunächst alle Leerzeichen aus der Eingabe
String[] sqlKeywords = StringUtils.split(SQL_REGEX, "\\|");
for (String sqlKeyword : sqlKeywords)
{
    if (StringUtils.indexOfIgnoreCase(normalizedValue, sqlKeyword) > -1)
    {
        throw new UtilException("请求参数包含敏感关键词" + sqlKeyword + "，可能存在安全风险");
    }
}

Fehleranalyse: Der Filter führt zuerst replaceAll("\p{Z}|\s", "") aus und entfernt damit alle Whitespace-Zeichen aus der Eingabe. Die Schlüsselwörter in der Blacklist SQL_REGEX (wie "and ", "select ") enthalten jedoch nachgestellte Leerzeichen. Dadurch schlägt die Übereinstimmung zwangsläufig fehl. Solange der Angreifer nach dem Schlüsselwort %0b (vertikaler Tabulator) anstelle eines Leerzeichens verwendet, kann er die Blacklist-Prüfung perfekt umgehen.

Screenshot-Belege:

2.3 Sink (gefährlicher Punkt)

· Dateiposition: ruoyi-generator/src/main/resources/mapper/generator/GenTableMapper.xml

Relevanter Code:

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

Analyse: In MyBatis verkettet ${} Zeichenketten direkt, anstatt die sichere Vorcompilierung #{} zu verwenden. Dadurch wird die bösartige SQL, die den Filter umgangen hat, zur Ausführung an die Datenbank übergeben. Dies ist eine typische kombinierte Schwachstelle aus „Blacklist-Filterung + unsicherer Verkettung".

Screenshot-Beleg:

3. PoC-Logik und Ausnutzungsansatz

3.1 Umgehungstechnik

· Methode: Der Angreifer verwendet %0b (MySQLs vertikaler Tabulator, der zum \s-Muster gehört) anstelle von Leerzeichen in der SQL-Anweisung.

3.2 Analyse der vollständigen Ausführungskette

HTTP übergibt Payload mit %0b: CREATE table xxx as SELECT%0b111 FROM sys_job WHERE 1=0 AND%0bIF(, 1, 1/0);
Die Payload gelangt in die filterKeyword-Methode, %0b wird durch \s erfasst und entfernt, die Zeichenkette wird zu select111 und andIF.
Da die Blacklist "select " (mit Leerzeichen) lautet, gibt "select111".indexOf("select ") -1 zurück, die Blacklist-Abfangung wird erfolgreich umgangen.
Der gefährliche Parameter gelangt in MyBatis, ${sql} verkettet ihn in die Datenbank.
Bei der MySQL-Analyse wird %0b als gültiges Whitespace-Zeichen betrachtet, die SQL wird erfolgreich injiziert und ausgeführt.

· Erkennungsprinzip: IF(, 1, 1/0) dient als Detektor für die Blind-Boolean-Injection. · Bedingung falsch: Löst einen Division-durch-Null-Fehler aus, der Server gibt HTTP 500 zurück. · Bedingung wahr: Normal, keine Fehlermeldung. · Extraktionsmethode: Mit der Binärsuche können Datenbankdaten bitweise erraten werden.

4. Zusammenfassung und Behebungsempfehlungen

4.1 Zusammenfassung der Schwachstellenursache

Diese Schwachstelle ist eine typische Umgehung, die durch „unvollständige Behebung" entsteht. Der Entwickler führte bei der Behebung früherer gleichartiger SQL-Injections einen Blacklist-Mechanismus ein, übersah jedoch, dass die Blacklist von Leerzeichen abhängt und die vorgelagerte Logik zum Entfernen von Leerzeichen die Übereinstimmungsbedingung der Blacklist zerstört, was schließlich zu einer neuen Umgehung (CVE-2024-57521) führte.

4.2 Behebungsempfehlungen

· Blacklist-Mechanismus abschaffen: Verlassen Sie sich nicht auf Blacklists, der Whitelist-Mechanismus ist die sichere Grundlage. · Vorcompilierung verwenden: Ändern Sie ${sql} in MyBatis zu #{} (Vorcompilierung). Wenn SQL dynamisch übergeben werden muss (z. B. bei Tabellenerstellung, Order By), sollten eine strikte Abstract Syntax Tree (AST)-Analyse oder eine strenge Parameterprüfung verwendet werden. · Filter verbessern: Falls eine Blacklist unvermeidbar ist, müssen die nachgestellten Leerzeichen der Blacklist-Schlüsselwörter entfernt und vor dem Vergleich eine einheitliche Normalisierung durchgeführt werden (z. B. einheitliche Umwandlung in Kleinbuchstaben, Ersetzen von %0b usw. durch Leerzeichen).

5. Referenzlinks

· NVD - CVE-2024-57521 · RuoYi-Vue Gitee-Repository

Beliebteste

CVE-2024-57521-RuoYi-SQLi