【テクニカル・上級編】 JWTの有効期限(exp)と発行時刻(iat)の検証によるリプレイ攻撃対策 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

JWTの「寿命」という幻想：リプレイ攻撃を封殺する堅牢な検証アーキテクチャ

多くの開発者がJWT（JSON Web Token）を単なる「便利なセッション管理ツール」と誤解している。だが、現場の最前線に立つ我々にとって、JWTは「時限爆弾」そのものだ。exp（有効期限）やiat（発行時刻）の検証を疎かにすることは、玄関の鍵をかけずに家の中に警備員を立たせているに等しい。

今回は、単なるRFCの解説ではなく、攻撃者がどうこの「時間軸」を歪めてリプレイ攻撃を仕掛けてくるのか、そしてそれを防ぐためのアーキテクチャ設計について深く掘り下げよう。

1. 「時間」という脆弱性：攻撃者はどこを突くか

JWTにおけるリプレイ攻撃の根本原因は、トークンが「ステートレス」であるという設計思想と、サーバー側の「検証ロジックの甘さ」にある。

攻撃者は、盗聴やローカルストレージからの流出によって入手したJWTを、expが切れるまでの間、執拗に使い回す。もしサーバー側がトークンの「発行時刻(iat)」と「現在時刻」の差分を厳密にチェックせず、単に「expが未来かどうか」だけを見ていれば、盗まれたトークンは悪意のあるアクターの手に渡ったその瞬間から、正規のユーザーとして振る舞い続けることになる。

ここで重要なのは、「有効期限内であっても、発行から不自然に時間が経過しているトークンは拒否すべき」というゼロトラストの原則だ。

2. 実装：検証ロジックの「ガードレイル」

単に token.exp > now を見るのは最低ラインだ。我々が求めるのは、以下の要素を組み合わせた多層防御である。

iatの検証: 未来の日付ではないか？
nbf（Not Before）の遵守: トークンが「有効になる前」に使われていないか？
許容範囲（Clock Skew）の管理: サーバー間の時刻のズレを考慮した厳密な判定。

以下に、Node.js環境での堅牢な検証ロジックのサンプルを示す。

const jwt = require('jsonwebtoken');

/**
 * 厳格なJWT検証関数
 * @param {string} token - ユーザーから送られてきたJWT
 * @param {string} secret - 署名検証用キー
 */
function verifyTokenStrict(token, secret) {
  try {
    const decoded = jwt.verify(token, secret, {
      // 許容される時刻のズレ（ミリ秒）: ネットワーク遅延や同期誤差を考慮
      clockTolerance: 30, 
      // 厳密なアルゴリズム指定: 'none'攻撃やRSA/HMAC混同攻撃を防ぐ
      algorithms: ['RS256'] 
    });

    // ここからが真の防御ロジック
    const now = Math.floor(Date.now() / 1000);

    // 1. 未来の発行時刻(iat)をチェック（改竄、あるいはPC時刻の操作）
    if (decoded.iat > now) {
      throw new Error('未来のトークンは受理できません');
    }

    // 2. トークン寿命の最大値を強制制限（長寿命トークンの排除）
    // 例えば、発行から1時間以上経過したものは、expに関わらず無効とする
    const maxTokenAge = 3600; 
    if (now - decoded.iat > maxTokenAge) {
      throw new Error('トークンの生存期間が制限を超えています');
    }

    return decoded;
  } catch (err) {
    // ログには詳細を出すが、クライアントには汎用的なエラーを返す（情報漏洩対策）
    console.error(`[Security Alert] JWT Validation Failed: ${err.message}`);
    throw new Error('認証プロセスでエラーが発生しました');
  }
}

3. 次世代の防衛：耐量子暗号とガードレイル

今、我々はRSAやECC（楕円曲線暗号）が量子コンピュータの脅威に晒される過渡期にいる。NISTが推奨する耐量子暗号（PQC）への移行を考慮するなら、JWTの署名アルゴリズムを将来的に EdDSA や将来のポスト量子署名へ切り替える準備をしておく必要がある。

また、生成AI時代の「プロンプトインジェクション」のように、APIサーバー側が受け取るペイロード自体が攻撃の媒介になるケースが増えている。JWTのクレーム（Claims）に、そのトークンが「どのデバイスから発行されたか」を示す jti（JWT ID）を含め、サーバーサイドのRedisで「一度使用されたjtiは即座に無効化する」という「ワンタイムトークン的運用」を組み合わせるのが、現代における最強の防衛だ。

4. まとめ：エンジニアに求める「疑う力」

技術とは、常に「信頼のコスト」を最適化するプロセスだ。JWTのexpを過信せず、常に「これは本当に今この瞬間に有効であるべきか？」を問い続けろ。

alg: none を許容するな: 必ずアルゴリズムを明示的に固定する。
jti を使え: リプレイ攻撃を無効化する最後の砦は、ステートフルなブラックリスト管理だ。
時刻同期を徹底せよ: NTPサーバーの設定ミスが、結果としてセキュリティホールの入り口になる。

セキュリティとは、完璧な製品を導入することではなく、脆弱性が生まれる構造を理解し、それを泥臭く塞ぎ続ける執念のことである。君たちのコードが、次に狙われる場所になる。その自覚を持って、アーキテクチャを設計してほしい。