【テクニカル・上級編】 JWT(JSON Web Token)の署名アルゴリズム ‘none’ 脆弱性の回避 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

攻撃者の嗤い声が聞こえるか？ JWT ‘none’ アルゴリズム、その静かなる時限爆弾

諸君、サイバーセキュリティの最前線に立つ者として、私は常に攻撃者の呼吸を感じ取ろうと努めている。彼らは私たちのシステムの盲点、プロトコルの隙間、そして何よりも「人間が犯すであろうミス」を嗅ぎつける。今日、私が語りたいのは、一見すると些細な、しかしその本質を理解すれば背筋が凍るような脆弱性、JSON Web Token (JWT) の ‘none’ アルゴリズムに関するものだ。

教科書的なガイドラインや一般的なセキュリティ勧告の羅列は時間の無駄だ。我々が知るべきは、攻撃者がどこに目をつけ、どのようにしてシステムを突破するのか、その深層にあるロジックと、それを封じるための最高峰の防御戦略だ。

JWT：ステートレス認証の諸刃の剣

JWTは、APIベースのサービスやマイクロサービスアーキテクチャにおいて、ステートレスな認証・認可を実現する強力なツールだ。その構造はシンプルだが、だからこそ攻撃者はそのシンプルさの中に潜む脆弱性を狙う。

JWTは3つのパートから構成される。

1. Header (ヘッダー): トークンのタイプ（typ）と署名アルゴリズム（alg）を指定する。
2. Payload (ペイロード): ユーザーID、ロール、有効期限など、任意のクレーム（情報）を格納する。
3. Signature (署名): ヘッダーとペイロードの内容が改ざんされていないことを検証するための署名。

これらはBase64Urlエンコードされ、ドット (.) で連結される。{base64UrlEncode(Header)}.{base64UrlEncode(Payload)}.{base64UrlEncode(Signature)}

攻撃者はまず、このHeaderに目を付ける。特に、alg（アルゴリズム）フィールドだ。

{
  "alg": "HS256", // 署名アルゴリズムを指定
  "typ": "JWT"
}

このフィールドは、サーバーがトークンを検証する際に「どのアルゴリズムで署名を検証すべきか」を指示する役割を持つ。ここにこそ、攻撃者が仕掛ける巧妙な罠が存在するのだ。

‘none’ アルゴリズム：プロトコルの「意図」と「実装」の乖離

JWTの仕様（RFC 7519）には、デバッグや特定のユースケースのために「署名なし」を意味する alg: "none" という値が許容されている。本来、これを受け入れるべきは、署名が不要な（あるいは別の方法で完全性が保証されている）ごく限られた状況のみだ。

しかし、多くのJWTライブラリやフレームワークの実装において、サーバーがクライアント（攻撃者）から提供された alg ヘッダーを無条件に信頼し、その値に基づいて署名検証ロジックを動的に切り替えてしまうという致命的な欠陥が散見された。

攻撃者はこれを見逃さない。彼らは合法的なJWTを傍受し、ペイロードを自由に改ざんする。そして、その改ざんされたペイロードを含むJWTのヘッダーを以下のように変更する。

{
  "alg": "none", // 攻撃者が指定
  "typ": "JWT"
}

署名部分には何も入力せず、空の文字列か、あるいは適当な値を Base64Url エンコードして設定する。サーバーは、この alg: "none" を読み込むと、「あ、署名がないから検証は不要なんだな」と解釈し、署名検証をスキップしてしまうのだ。

これは、プロトコル仕様の「意図」（デバッグ用途）と、実装者の「解釈」（無条件な信頼）の間に生じた、あまりにも深く、そして破壊的な乖離だ。

深層分析：なぜこれは深刻なのか？

この脆弱性の根本原因は、信頼の境界線 (Trust Boundary) の破綻にある。本来、クライアントから送られてくるデータはすべて「信頼できない」ものとして扱われ、サーバー側で厳格に検証されるべきだ。しかし、このケースでは、サーバーがクライアントからの「検証方法の指示」を無条件に受け入れている。

低レイヤの視点から見れば、これは単なる論理エラー以上の意味を持つ。

1. メモリへの不正データロード: 署名検証がスキップされた結果、改ざんされたペイロード（例えば、"isAdmin": true に書き換えられたクレームや、不正なユーザーID）がそのままサーバーのメモリ空間にロードされ、アプリケーションロジックによって処理される。これにより、権限昇格、他のユーザーデータへのアクセス、あるいはシステム設定の変更といった、あらゆる種類の攻撃が成立しうる。これは、SQLインジェクションが不正なクエリ文字列をDBに送り込むのと同等か、それ以上に広範な影響を持つ可能性がある。

2. プロトコル仕様の「柔軟性」の悪用: JWTの柔軟性は強力な反面、誤用されるリスクも孕む。alg フィールドは、まさにこの「柔軟性」が攻撃の足がかりとなった典型例だ。通信プロトコルは多くの場合、様々な状況に対応できるよう柔軟な設計がなされるが、その柔軟性が実装におけるセキュリティホールを生み出すことがある。TCP/IPスタックの脆弱性やHTTPプロトコルの仕様上の曖昧さが攻撃に悪用されるのと同様の構図だ。

3. CVE事例の示唆: 過去には、様々なJWTライブラリやフレームワークでこの種の脆弱性（例: CVE-2015-2922）が報告されてきた。これは、単一のライブラリの問題ではなく、分散型システムにおける「認証トークンの検証」というセキュリティの根幹に関わる、アーキテクチャレベルの課題なのだ。

最高峰の防御戦略：許可リスト (Allow List) 原則の徹底

この脆弱性を回避するための防御戦略は、極めてシンプルでありながら、最も強力な原則に則っている。それは「許可リスト (Allow List) 原則」の徹底だ。

サーバーは、クライアントが指定する alg フィールドを決して信頼してはならない。代わりに、サーバー自身が「どのアルゴリズムのみを許可するか」を明示的に設定し、それ以外のアルゴリズムが指定された場合は問答無用で拒否する必要がある。

理想的なJWT検証ロジックは以下のようになるべきだ。

1. クライアントからJWTを受け取る。
2. JWTのヘッダーをパースし、alg フィールドの値を取得する。
3. サーバー側で予め定義された「許可するアルゴリズムのリスト」に、クライアントが指定した alg が含まれているかを厳格にチェックする。
4. もし含まれていなければ、即座に検証エラーとしてトークンを拒否する。
5. 許可リストに含まれており、かつ alg: "none" でない場合は、指定されたアルゴリズムとサーバーの秘密鍵/公開鍵を用いて署名を検証する。
6. alg: "none" が許可リストに含まれていることは、本番環境では絶対にありえない。もし含まれていれば、それは設定ミスであり、即座に修正すべきだ。

実用的なコード例

以下に、主要な言語での実装例を示す。

Python (PyJWT)

import jwt
from jwt.exceptions import InvalidSignatureError, InvalidAlgorithmError

# サーバー側で許可するアルゴリズムのリストを厳格に定義
ALLOWED_ALGORITHMS = ["HS256", "RS256", "ES256"] # 本番環境で「none」を含めてはならない！

# 秘密鍵（HS256の場合）または公開鍵（RS256/ES256の場合）
SECRET_KEY = "your-secret-key-that-is-at-least-256-bits-long" 
PUBLIC_KEY = """-----BEGIN PUBLIC KEY-----
...
-----END PUBLIC KEY-----"""

def verify_jwt_token(token: str) -> dict:
    """
    JWTトークンを検証し、ペイロードを返す関数。
    許可リスト方式でアルゴリズムを厳格にチェックする。
    """
    try:
        # jwt.decode() の algorithms パラメータで許可リストを明示的に指定
        # これにより、クライアントが指定したalgが許可リストにない場合、InvalidAlgorithmErrorが発生する
        payload = jwt.decode(
            jwt=token,
            key=SECRET_KEY, # または PUBLIC_KEY
            algorithms=ALLOWED_ALGORITHMS, # サーバー側で許可するアルゴリズムを明示的に指定
            options={"require": ["exp", "iat"]} # 例: 有効期限と発行時刻のクレームを必須とする
        )
        print("JWT検証成功:", payload)
        return payload
    except InvalidAlgorithmError as e:
        # 不許可なアルゴリズムが指定された場合の処理
        print(f"エラー: 不許可な署名アルゴリズムが使用されました - {e}")
        raise ValueError("Invalid JWT Algorithm")
    except InvalidSignatureError as e:
        # 署名が不正な場合の処理
        print(f"エラー: JWT署名が不正です - {e}")
        raise ValueError("Invalid JWT Signature")
    except Exception as e:
        # その他のJWT関連エラー
        print(f"エラー: JWT検証中に予期せぬエラーが発生しました - {e}")
        raise ValueError("JWT Verification Failed")

# --- 使用例 ---
# 攻撃者が改ざんしたJWTを模倣 (alg: "none"を指定し、署名なし)
# 実際のトークンは base64UrlEncode(header) + "." + base64UrlEncode(payload) + "."
# header = {"alg": "none", "typ": "JWT"}
# payload = {"user_id": 123, "isAdmin": True}
# 攻撃者が作成したトークン (署名部分は通常空か適当な値)
attacker_jwt_none = "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyX2lkIjoxMjMsImlzQWRtaW4iOnRydWV9."

# 許可されたアルゴリズムで正しく署名されたJWT (例: HS256)
# 実際のトークン生成はjwt.encode()を使用
valid_jwt_hs256 = jwt.encode(
    {"user_id": 456, "isAdmin": False, "exp": jwt.helpers.time.time() + 3600},
    SECRET_KEY,
    algorithm="HS256"
)

print("\n--- 攻撃者の 'none' トークンを検証 ---")
try:
    verify_jwt_token(attacker_jwt_none)
except ValueError as e:
    print(f"結果: {e} (正しく拒否されました)")

print("\n--- 正しいHS256トークンを検証 ---")
try:
    verify_jwt_token(valid_jwt_hs256)
except ValueError as e:
    print(f"結果: {e} (検証失敗)") # 署名検証は成功するが、ここではエラーが発生しないことを確認

Node.js (jsonwebtoken)

const jwt = require('jsonwebtoken');

// サーバー側で許可するアルゴリズムのリストを厳格に定義
const ALLOWED_ALGORITHMS = ['HS256', 'RS256', 'ES256']; // 本番環境で「none」を含めてはならない！

// 秘密鍵（HS256の場合）または公開鍵（RS256/ES256の場合）
const SECRET_KEY = 'your-secret-key-that-is-at-least-256-bits-long';
const PUBLIC_KEY = `-----BEGIN PUBLIC KEY-----
...
-----END PUBLIC KEY-----`;

/**
 * JWTトークンを検証し、ペイロードを返す関数。
 * 許可リスト方式でアルゴリズムを厳格にチェックする。
 * @param {string} token - 検証するJWTトークン
 * @returns {Promise<object>} - 検証成功時のペイロード
 * @throws {Error} - 検証失敗時のエラー
 */
async function verifyJwtToken(token) {
    try {
        // jwt.verify() の algorithms パラメータで許可リストを明示的に指定
        // これにより、クライアントが指定したalgが許可リストにない場合、JsonWebTokenErrorが発生する
        const payload = await jwt.verify(
            token,
            SECRET_KEY, // または PUBLIC_KEY
            {
                algorithms: ALLOWED_ALGORITHMS, // サーバー側で許可するアルゴリズムを明示的に指定
                // ignoreExpiration: false, // 有効期限を無視しない（デフォルト）
                // audience: 'your_audience', // 例: オーディエンスの検証
                // issuer: 'your_issuer',     // 例: 発行者の検証
            }
        );
        console.log('JWT検証成功:', payload);
        return payload;
    } catch (error) {
        // JsonWebTokenError は、署名不正、アルゴリズム不正、有効期限切れなどを含む
        if (error.name === 'JsonWebTokenError') {
            if (error.message.includes('algorithm not allowed')) {
                console.error(`エラー: 不許可な署名アルゴリズムが使用されました - ${error.message}`);
                throw new Error('Invalid JWT Algorithm');
            } else {
                console.error(`エラー: JWT署名が不正または無効です - ${error.message}`);
                throw new Error('Invalid JWT Signature or Expired');
            }
        } else {
            console.error(`エラー: JWT検証中に予期せぬエラーが発生しました - ${error.message}`);
            throw new Error('JWT Verification Failed');
        }
    }
}

// --- 使用例 ---
// 攻撃者が改ざんしたJWTを模倣 (alg: "none"を指定し、署名なし)
// 実際のトークンは base64UrlEncode(header) + "." + base64UrlEncode(payload) + "."
// header = {"alg": "none", "typ": "JWT"}
// payload = {"user_id": 123, "isAdmin": true}
// 攻撃者が作成したトークン (署名部分は通常空か適当な値)
const attackerJwtNone = "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyX2lkIjoxMjMsImlzQWRtaW4iOnRydWV9.";

// 許可されたアルゴリズムで正しく署名されたJWT (例: HS256)
// 実際のトークン生成はjwt.sign()を使用
const validJwtHs256 = jwt.sign(
    { user_id: 456, isAdmin: false },
    SECRET_KEY,
    { algorithm: 'HS256', expiresIn: '1h' }
);

(async () => {
    console.log('\n--- 攻撃者の \'none\' トークンを検証 ---');
    try {
        await verifyJwtToken(attackerJwtNone);
    } catch (e) {
        console.log(`結果: ${e.message} (正しく拒否されました)`);
    }

    console.log('\n--- 正しいHS256トークンを検証 ---');
    try {
        await verifyJwtToken(validJwtHs256);
    } catch (e) {
        console.log(`結果: ${e.message} (検証失敗)`); // 署名検証は成功するが、ここではエラーが発生しないことを確認
    }
})();

これらのコード例が示すように、algorithms オプションに許可するアルゴリズムのリストを明示的に渡すことが、この脆弱性に対する最も堅牢な防御策となる。

多層防御と監査の観点

この問題は、単にコード修正で解決するだけでなく、より広範なセキュリティ戦略の中で位置づける必要がある。

  • 脅威モデリング: システム設計段階で、JWTの認証フローにおける「認証スキップ」「権限昇格」といった攻撃シナリオを具体的に想定し、その対策を盛り込むべきだ。特に、信頼の境界線を明確にし、それぞれの境界を越えるデータは厳格に検証されるべきであることを徹底する。
  • コードレビューと静的解析: CI/CDパイプラインに、JWTライブラリの使用方法をチェックする静的解析ツールや、セキュリティ専門家によるコードレビューを組み込む。特に、jwt.decode() や jwt.verify() 関数に algorithms パラメータが適切に設定されているか、"none" が意図せず許可リストに含まれていないかを重点的に確認する。
  • ライブラリの選定と更新: 信頼できる、活発にメンテナンスされているJWTライブラリを選定し、常に最新バージョンに保つ。これは、ライブラリ自身のバグ修正だけでなく、セキュリティベストプラクティスの変更にも対応するためだ。
  • ログ監視と異常検知: JWT検証エラー、特に InvalidAlgorithmError や JsonWebTokenError が頻発する場合、それは攻撃の兆候である可能性がある。これらのログを収集し、SIEM (Security Information and Event Management) システムなどで異常検知ルールを設定し、速やかにアラートを発動できるようにしておく。

未来を見据えて：量子時代とAI時代のJWT防御

我々ホワイトハッカーは、常に次の脅威を見据えなければならない。JWTの署名アルゴリズムの選択と検証は、未来の脅威に対してもその重要性を増すばかりだ。

耐量子暗号への移行

今日の公開鍵暗号（RSA、楕円曲線暗号 ECC）は、将来的な量子コンピュータの登場により破られる可能性がある。これにより、現在のJWTの署名アルゴリズムもいずれは耐量子暗号 (Post-Quantum Cryptography, PQC) に置き換えられるだろう。

この移行期において、alg フィールドはさらに複雑な意味を持つようになる。レガシーなアルゴリズムとPQCアルゴリズムが混在する期間、サーバーはより厳格なアルゴリズムの許可リストを維持し、誤って脆弱なレガシーアルゴリズムを受け入れてしまわないよう、二重三重のチェックが必要となる。これは、単にアルゴリズム名を変更するだけでなく、鍵管理、証明書チェーン、そして検証ロジック全体を見直す大規模な作業となるだろう。

生成AIによる攻撃の自動化と防御層の強化

生成AIは、すでにプロンプトインジェクションのような新たな攻撃手法を生み出している。将来、AIが自律的に脆弱性を探索し、JWTの改ざんパターンを生成し、ターゲットシステムに自動的に攻撃を仕掛けるようになる可能性は否定できない。

このようなAI駆動型攻撃の時代には、JWTの署名検証ロジックは、あたかも生成AIに対する「ガードレール」のように機能しなければならない。AIが生成した不正な alg フィールドや改ざんされたペイロードを、サーバー側の厳格な許可リストと検証ロジックが確実にブロックする。これは、ユーザー入力に対するサニタイズやバリデーションと同様に、AIが生成したデータ（この場合はJWTのヘッダーやペイロード）に対しても、徹底した「疑う」姿勢と「防御層」を構築する必要があることを意味する。

結び：セキュリティは常に「疑う」ことから始まる

JWT ‘none’ アルゴリズムの脆弱性は、サイバーセキュリティの根源的な原則を改めて我々に突きつける。それは「クライアントからの入力は決して信頼してはならない」という、シンプルだが最も重要な教訓だ。

攻撃者は常に、システムが「信頼」しているであろう盲点を狙う。彼らが嗤い声を上げないよう、我々は常にシステムを疑い、プロトコルの隅々まで検証し、最高の防御層を構築し続ける必要がある。この教訓を胸に刻み、諸君のシステムが常に堅牢であることを願う。

スポンサーリンク

コメント

タイトルとURLをコピーしました