リプレイ攻撃（Replay Attack）とは？認証トークンを再利用する手口と企業が取るべき対策をわかりやすく解説

「認証を強化したはずなのに、不正ログインが止まらない」──そんな声を現場でよく耳にします。ブルートフォース攻撃への対策は整えたが、それとは全く別の経路で忍び込んでくる攻撃手法の一つが、今回解説する「リプレイ攻撃」です。

リプレイ攻撃は、ネットワーク上を流れる正規の認証トークンや通信データを攻撃者が傍受し、そのまま再送することでシステムへの不正アクセスを試みる攻撃手法です。パスワードを「解読」するわけではなく、正規の認証データを丸ごとコピーして流用するため、強いパスワードやMFA（多要素認証）だけでは防ぎきれないケースがあります。

この記事では、リプレイ攻撃の仕組み・実際の攻撃手口・企業が今日から取れる対策まで、現場で使えるレベルで解説します。

リプレイ攻撃とは？（概要・なぜ重要か）

リプレイ攻撃（Replay Attack）とは、通信上で傍受した正規のデータ（認証トークン・セッションクッキー・APIリクエストなど）を攻撃者がそのまま再送し、正規ユーザーになりすます攻撃手法です。日本語では「再送攻撃」とも呼ばれます。

通常の認証攻撃（ブルートフォース、フィッシングなど）は「正しいパスワードを得ること」を目的としますが、リプレイ攻撃は「正規の認証済み通信データを手に入れること」が目的です。攻撃者がパスワードを知らなくても、認証済みのトークンを入手さえすれば攻撃が成立します。

リプレイ攻撃が重要視される理由は以下の2点です。

・暗号化通信でも成立する可能性がある: データの中身は読めなくても、暗号化されたパケットをそのまま再送するだけで認証が通るシステムが存在します
・ログには正規ユーザーとして記録される: 正規の認証情報が使われるため、不正アクセスとしての検知が難しいケースがあります

攻撃の仕組み（敵を知る）

リプレイ攻撃が成立するプロセスを順番に見ていきましょう。

1. 通信の傍受（スニッフィング）

攻撃者はまず、ターゲットと認証サーバーの間の通信を傍受します。狙われやすい機会は、暗号化されていないHTTP通信、設定の甘い公共Wi-Fi、内部ネットワーク上でのARPスプーフィング（中間者攻撃）などです。傍受したデータには、認証トークン・Cookieのセッション情報・APIリクエストのヘッダーなどが含まれます。

2. トークンの記録と再送

傍受した認証データを保存し、後でそのままサーバーへ送信します。サーバー側が「このトークンは有効期限内の正規トークンだ」と判断すれば、攻撃者は認証を突破できます。

この仕組みが成立する背景には、多くのシステムが「正しいトークンを持っている＝正規ユーザー」という前提で動いていることがあります。

【具体例1】JWTトークンの再利用

REST APIで広く使われるJWT（JSON Web Token）は、有効期限（expクレーム）の設定が任意です。有効期限を設定していないJWT、または有効期限が極端に長いJWTが傍受されると、期限が切れるまで攻撃者に繰り返し使われます。

JWTの脆弱性と安全な実装については、JWTの脆弱性と安全な実装方法で詳しく解説しています。

【具体例2】Kerberos認証環境でのリプレイ

Active Directory環境で使われるKerberos認証は、タイムスタンプを使ったリプレイ対策をもともと備えています。しかし、時刻同期（NTP）がずれている環境では、タイムスタンプの検証が機能しなくなります。また、ゴールデンチケット攻撃のような高度な手法では、取得したチケットを長期間再利用されるリスクもあります。

セッション固定化攻撃との違い

セッション固定化攻撃も「セッションの乗っ取り」という意味では似た概念ですが、攻撃の方向性が異なります。

具体的な防御手順

1. ノンス（Nonce）を使ったワンタイム検証

ノンス（Nonce: Number used once）は、認証のたびに生成される使い捨てのランダム文字列です。サーバーは発行したノンスの使用状況を記録し、同じノンスが再送された場合は拒否します。これにより、傍受された認証データをそのまま再送しても「このノンスは使用済み」として検知できます。

# ノンスを使った認証フロー（擬似コード）
# Step 1: クライアントが認証要求 → サーバーがnonceを発行
nonce = generate_random_token(32)
cache.set(nonce, expires_in=60)     # 60秒で自動失効

# Step 2: クライアントがnonceを含めてリクエスト送信

# Step 3: サーバー側検証
if not cache.exists(nonce):
    return 401   # 使用済みまたは期限切れ → リプレイ攻撃を検知
cache.delete(nonce)                  # 使用済みにして再利用を防ぐ
proceed_authentication()

2. タイムスタンプ＋有効期限の厳格化

認証トークンに発行時刻（iat）と有効期限（exp）を埋め込み、期限切れトークンを必ず拒否します。

・JWTの場合: expクレームを必ず設定する。アクセストークンは5～15分、リフレッシュトークンは1日程度が一般的な設計です
・Kerberos認証の場合: NTP（時刻同期）の設定を徹底する。Kerberosのデフォルト許容差は±5分以内のため、NTPセキュリティ設定との組み合わせが重要です

3. TLS 1.3への移行で通信自体を保護

リプレイ攻撃の前提は「通信の傍受」です。TLS 1.3への移行により、通信の傍受リスクそのものを大幅に低減できます。

ただし、TLS 1.3の「0-RTT（ゼロラウンドトリップタイム）」モードはリプレイ攻撃に脆弱なため、機密性の高いAPIでは0-RTTを無効化することを推奨します。

# Nginx での 0-RTT 無効化設定（nginx.conf）
ssl_early_data off;    # デフォルト: on（TLS 1.3 0-RTTを無効化）

LinuxサーバーへのTLS設定の詳細手順は、姉妹サイトLinuxMaster.JPのSSL/TLS関連記事も参考になります。

4. HSTSとHTTPS強制で傍受の機会を封じる

HTTP通信は傍受が容易です。HTTPSへの強制リダイレクトに加え、HSTS（HTTP Strict Transport Security）を設定してブラウザが常にHTTPSで接続するよう強制します。

SSLストリッピング攻撃（HTTPSをHTTPに格下げする手口）とHSTSの詳細は、SSLストリッピング攻撃とHSTSによる対策をご覧ください。

中小企業でも今日からできること

大規模なシステム改修が難しい環境でも、以下の確認・対策から着手できます。

・JWTの有効期限を確認する: 自社システムで発行しているJWTにexpクレームが設定されているかを確認し、未設定の場合は即対応する
・APIログで異常なアクセスを確認する: 同一トークンが短時間に大量リクエストで使われていないかを定期的にチェックする
・TLS設定のバージョンを確認する: 無料ツール「SSL Labs」でサーバーを診断し、TLS 1.0/1.1を使っていれば無効化する
・業務ネットワークと来客Wi-Fiを分離する: 同一ネットワーク上での傍受リスクを下げるため、VLANまたは別回線で分離する
・Kerberos環境のNTP設定を確認する: Active Directory環境では時刻同期のずれがリプレイ攻撃の窓口になるため、NTP設定を定期確認する

よくある誤解と注意点

・「HTTPSを使っているから安全」という誤解: TLS 1.3の0-RTTモードではリプレイリスクが残ります。暗号化は傍受を難しくしますが、攻撃を不可能にするわけではありません
・「有効期限を設定すれば十分」という誤解: 有効期限内であれば何度でも再送されるリプレイ攻撃には、ノンスの併用が必要です
・「MFAで防げる」という誤解: プッシュ通知型MFAのトークンを傍受・再送するリプレイ攻撃が実証されており、MFAだけで完全には防げないケースがあります。FIDO2/パスキーはリプレイ耐性が高い認証方式として注目されています

本記事のまとめ

リプレイ攻撃は「正規の認証データを丸ごと再利用する」というシンプルな原理に基づいていますが、防御には複数の仕組みの組み合わせが必要です。

まず取り組みやすいのは、JWTの有効期限設定とHSTSの導入です。次のステップとして、TLS 1.3への移行とノンスの実装を進めることで、リプレイ攻撃への耐性を大幅に高められます。「正しく知って、正しく備える」という積み重ねが、見えにくい攻撃を防ぐ確実な方法です。