🛡️ CVE-2024-57521 RuoYi-Vue 認証後 SQL インジェクション脆弱性監査ノート

図 1：CVE-2024-57521 SQL インジェクション脆弱性データフロー監査図

0. プロジェクト宣言

本リポジトリはセキュリティ研究および教育目的でのみ使用されます。本文書の技術を利用した未承認の攻撃行為は行わないでください。すべてのテストはローカルの静的コード監査環境で実施されました。

1. 脆弱性概要

CVE番号：CVE-2024-57521
影響コンポーネント：RuoYi-Vue 権限管理システム（ruoyi-generator モジュール）
影響バージョン：<= v4.7.9
脆弱性タイプ：認証後 SQL インジェクション（ブールベースブラインドインジェクション / CWE-89）
CVSSスコア：10.0 (Critical)
監査方式：純粋な静的コード監査（ソースコード分析）

2. データフロー監査分析 (Source → Filter → Sink)

2.1 Source（ユーザー入力入口）

ファイル位置：ruoyi-generator/src/main/java/com/ruoyi/generator/controller/GenController.java

主要コード：

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

分析：バックエンド管理者は、HTTP POST リクエストの sql パラメータを通じて任意のデータベーステーブル作成文を渡すことができます。エントリポイントはユーザー入力を十分に制限せず、そのまま後続のフィルターに渡しています。

スクリーンショットの証拠： 03-SqlUtil-filterKeyword

2.2 Filter（フィルターの致命的な欠陥）

· ファイルの場所：ruoyi-common/src/main/java/com/ruoyi/common/utils/sql/SqlUtil.java

中核となる欠陥コード：

// 第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 + "，可能存在安全风险");
    }
}

脆弱性分析：フィルターはまず replaceAll("\p{Z}|\s", "") を実行して入力内のすべての空白文字を削除します。しかし、ブラックリスト SQL_REGEX 内のキーワード（「and 」「select 」など）には末尾に空白が付いています。このためマッチングは必ず失敗し、攻撃者がキーワードの後に %0b（垂直タブ）を使って空白を置き換えるだけで、ブラックリストチェックを完全にバイパスできます。

スクリーンショットの証拠：

2.3 Sink（危険箇所）

· ファイルの場所：ruoyi-generator/src/main/resources/mapper/generator/GenTableMapper.xml

主要なコード：

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

分析：MyBatis では ${} は安全なプリコンパイル #{} ではなく、文字列を直接連結します。そのため、フィルターを回避した悪意のある SQL がデータベースに送られ実行されます。これは典型的な「ブラックリストフィルタリング + 安全でない連結」の組み合わせ脆弱性です。

スクリーンショットの証拠：

3. PoC のロジックと悪用の考え方

3.1 回避手法

· 方法：攻撃者は %0b（MySQL の垂直タブ文字で、\s のマッチ範囲に含まれる）を SQL 文のスペースの代わりに使用します。

3.2 完全な実行チェーン分析

HTTP で %0b を含む Payload を送信：CREATE table xxx as SELECT%0b111 FROM sys_job WHERE 1=0 AND%0bIF(<条件>, 1, 1/0);
Payload が filterKeyword メソッドに入り、%0b が \s にマッチして除去され、文字列は select111 と andIF になる。
ブラックリストは "select "（スペース付き）であるため、"select111".indexOf("select ") は -1 を返し、ブラックリストのインターセプトを回避することに成功する。
危険なパラメータが MyBatis に入り、${sql} によってデータベースに連結される。
MySQL の解析時、%0b は有効な空白文字と見なされるため、SQL インジェクションが成功して実行される。

3.3 ブラインドインジェクション自動化の考え方

· 検出原理：IF(<条件>, 1, 1/0) をブール型ブラインドインジェクションの検出器として利用します。 · 条件が偽：ゼロ除算エラーが発生し、サーバーは HTTP 500 を返します。 · 条件が真：正常でエラーは発生しません。 · 抽出方法：二分法を用いることで、データベースのデータを1ビットずつ推測できます。

4. まとめと修正の推奨事項

4.1 脆弱性の原因まとめ

この脆弱性は、典型的な「修正が不完全」なことによる回避です。開発者は以前の同種の SQL インジェクションを修正する際にブラックリスト機構を導入しましたが、ブラックリストがスペースに依存していることを見落としました。そして、スペースを除去する前処理ロジックがブラックリストのマッチ条件を破壊し、最終的に新たな回避（CVE-2024-57521）を引き起こしました。

4.2 修正の推奨事項

· ブラックリスト機構の廃止：ブラックリストに依存せず、ホワイトリスト方式こそが安全の基盤です。 · プリコンパイルの使用：MyBatis の ${sql} を #{} のプリコンパイル方式に変更します。どうしても SQL を動的に渡す必要がある場合（テーブル作成、Order By など）は、厳密な抽象構文木（AST）解析や厳密なパラメータ検証を使用すべきです。 · フィルターの改善：どうしてもブラックリストを使用する必要がある場合は、ブラックリストのキーワードの末尾のスペースを除去し、比較前に統一的な正規化（小文字への統一、%0b などをスペースに置換するなど）を行う必要があります。

5. 参考リンク

· NVD - CVE-2024-57521 · RuoYi-Vue Gitee リポジトリ

6. 自動化 PoC スクリプト（エラーベースインジェクションに基づく）

ファイルの場所：poc/poc_boolean.py（注：実際のロジックに合わせて、後でファイル名を poc_error_based.py に変更することを推奨します）
実装原理：extractvalue() 関数を利用して XPath エラーを発生させ、正規表現で XPATH syntax error: '~...~' をマッチさせてデータを抽出します。Payload では /**/ をスペースの代わりに使用し、ブラックリストフィルタリングを回避します。
コア Payload：


CREATE//table//{随机表名}//as//SELECT/**/extractvalue(1,concat(0x7e,({查询语句}),0x7e))

テスト説明：ローカルに構築した RuoYi ターゲット環境でのテストにおいて、%0b による WAF バイパスおよび extractvalue エラーベースインジェクションの実行可能性を検証することに成功しました。スクリプトは MySQL バージョン (5.7.26)、現在のデータベース名 (ry)、およびデータベース接続ユーザー (root@localhost) を安定して抽出できています。

CVE-2024-57521-RuoYi-SQLi

人気