【テクニカル・上級編】 JWTのjti(JWT ID)クレームを用いたリプレイ攻撃の完全防御 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

JWTのjtiクレームで防ぐ「一撃必殺」のリプレイ攻撃：アーキテクトのための防衛論

JWT（JSON Web Token）をステートレスな認証の銀の弾丸だと信じているなら、今すぐその幻想を捨ててほしい。JWTは「発行されたら最後、有効期限が切れるまで誰が持っていようと正当な権利者として振る舞える」という、いわば署名付きの通行手形だ。

特に、中間者攻撃やログ解析によって盗聴されたJWTを悪用される「リプレイ攻撃」は、現代のマイクロサービスアーキテクチャにおける最大の盲点の一つだ。今回は、この脆弱性をjti（JWT ID）クレームという「使い捨ての証紙」を用いて、いかに泥臭く、かつ堅牢に封じ込めるかを論じる。

—

1. なぜ「jti」によるブラックリスト管理が必須なのか

JWT自体は暗号署名によって改ざんを検知できるが、その中身（クレーム）の正当性まで保証するものではない。悪意ある攻撃者がAuthorizationヘッダーをキャプチャし、そのまま再送するだけで、サーバーは「署名が正しいから」という理由で処理を実行してしまう。

これを防ぐための最も直接的で、かつ運用負荷の低い防衛策がjtiの管理だ。jtiはJWTを一意に識別するためのUUIDであり、これをサーバー側のキャッシュ（Redis等）で「使用済みリスト」として管理する。

アーキテクチャ上の留意点

アトミックな検証: jtiの照合と書き込みは、必ずSETNX（Redis）のようなアトミック操作で行うこと。
生存期間の同期: jtiのキャッシュ有効期限（TTL）は、JWTのexp（有効期限）と厳密に同期させる必要がある。

—

2. 実装：Redisを活用した防御層の構築

以下は、リクエストの正当性を検証する際の擬似的なミドルウェア実装だ。ここで重要なのは、jtiの重複チェックが「リクエスト処理の最前線（ゲートウェイ）」で完了していることである。

import redis
import jwt

# Redisクライアントの初期化（接続プールの利用を推奨）
r = redis.Redis(host='localhost', port=6379, db=0)

def verify_token_and_jti(token, secret):
    try:
        # 1. JWTの署名検証とデコード
        payload = jwt.decode(token, secret, algorithms=["HS256"])
        jti = payload.get("jti")
        exp = payload.get("exp")

        if not jti:
            raise Exception("jtiクレームが存在しません")

        # 2. Redisでjtiの存在確認と書き込みをアトミックに実行
        # set(name, value, ex=expire, nx=True) -> セットできればTrue
        is_new = r.set(f"jti:{jti}", "used", ex=exp - int(time.time()), nx=True)

        if not is_new:
            # 既に存在する場合、リプレイ攻撃とみなす
            log_security_event("REPLAY_ATTACK_DETECTED", jti)
            raise Exception("リプレイ攻撃が検出されました")

        return payload

    except jwt.ExpiredSignatureError:
        # 有効期限切れのハンドリング
        pass

—

3. 次世代の脅威を見据える：耐量子暗号とガードレイル

我々が今扱うRSAや楕円曲線暗号（ECC）は、近い将来、Shorのアルゴリズムを用いた量子コンピュータによって、その安全性を根底から覆される。JWTの署名アルゴリズムにRS256やES256を使用している場合、鍵のビット長を増やすだけでは不十分だ。

今後は、JWTのヘッダーにおけるalgを、耐量子暗号（PQC）アルゴリズム（CRYSTALS-Dilithiumなど）へ段階的に移行する計画を立てるべきだ。

生成AI時代におけるガードレイル

また、最近のインシデントで増えているのは、LLMのAPIエンドポイントに対するJWTの悪用だ。攻撃者は、正当なJWTを用いてLLMに不正な指示（プロンプトインジェクション）を送り込む。これに対し、jti管理だけでなく、「トークンの利用用途」をクレームとして埋め込み、サーバー側でポリシーを強制するアーキテクチャが不可欠だ。

{
  "sub": "user123",
  "jti": "uuid-v4-random-string",
  "scope": "read:profile",
  "allow_ai_tools": false 
}

このように、JWTのペイロードにビジネスロジックに直結するガードレイルを記述し、APIゲートウェイ側でその値をパースして実行を拒否する設計が、これからのゼロトラストにおける「正解」となる。

—

4. 最後に：現場のエンジニアへ

セキュリティは「完璧な製品を導入すること」ではなく、「攻撃者の思考プロセスを追い抜き、リスクの表面積を最小化し続ける行為」だ。

jtiによるリプレイ防御を導入することは、単なるコードの追加ではない。分散システムにおける「一意性」を担保し、すべてのリクエストを疑うという、エンジニアとしてのスタンスを表明することに他ならない。

次にこのコードをデプロイする際、ぜひ自問してほしい。「もしこのjtiが衝突した時、ログに何を出力し、誰にアラートを飛ばすべきか？」と。その回答こそが、あなたの組織のセキュリティレベルを決定づけるのだ。