// シス担のミカタ
ネットワーク攻撃

リプレイ攻撃 りぷれいこうげき

認証セッションハイジャックトークンタイムスタンプノンス中間者攻撃
リプレイ攻撃について教えて

簡単に言うとこんな感じ！

一度使った「正規の合言葉」を盗み録りして、後でこっそり再利用する攻撃だよ！「本人が送った本物の通信」をそのままコピーして送りつけるから、システムは「正規ユーザーだ」と勘違いして信じてしまうんだ。

リプレイ攻撃とは

リプレイ攻撃（Replay Attack） とは、正規ユーザーとサーバー間でやり取りされた通信データを攻撃者が盗み取り、そのデータをそのまま再送信することで、不正にアクセスや操作を成功させるサイバー攻撃の手法です。

たとえば、あなたがネットバンキングで「1万円を振り込む」というリクエストを送ったとします。攻撃者がその通信をコピーして保存しておき、後から同じリクエストを再送すると、サーバーは「また正規ユーザーが振り込み指示を出してきた」と判断して、二重に振り込んでしまう可能性があります。内容を改ざんしなくてもいいのがこの攻撃の巧妙なところです。

リプレイ攻撃は、暗号化されていても防げないという点で危険視されています。暗号化はデータの「中身を読めなくする」技術ですが、「そのまま再送する」だけなら中身を解読する必要がないからです。対策には、使い捨てのトークンやタイムスタンプなど、「同じデータを2度使えなくする仕組み」が必要になります。

リプレイ攻撃の仕組みと流れ

① 正規ユーザーがサーバーへ認証リクエストを送信
   [ユーザー] ──── 認証データ ────▶ [サーバー] ✅ ログイン成功

② 攻撃者が通信を盗み聞きしてコピー
   [ユーザー] ──── 認証データ ────▶ [サーバー]
                       ↑
               [攻撃者] こっそりコピー！

③ 攻撃者が同じデータをそのまま再送
   [攻撃者] ──── 同じ認証データ ──▶ [サーバー] ✅ ログイン成功 😱

攻撃の流れを段階的に整理すると、以下のようになります。

ステップ攻撃者の行動サーバーの判断
1. 傍受正規の通信パケットをキャプチャして保存（気づかない）
2. 待機適切なタイミングを見計らう（気づかない）
3. 再送信保存したパケットをそのままサーバーへ送りつける正規リクエストと誤認
4. 侵害成功不正ログイン・二重送金・権限取得などを達成リクエスト承認

覚え方：「録画した合言葉をドアに叫ぶ」

「開けゴマ！」という合言葉を言った瞬間を録音して、後で自分がドアの前で再生すれば、ドアは本人だと思って開いてしまいます。リプレイ攻撃はまさにこれと同じ構造です。「本物かどうか」ではなく「過去に使われた本物のデータかどうか」を検知できないと防げません。

狙われやすいシステムの特徴

歴史と背景

  • 1980年代〜 ：ネットワーク認証プロトコルの設計議論の中でリプレイ攻撃の脅威が認識され始める
  • 1988年 ：MITが認証プロトコル Kerberos を発表。リプレイ攻撃への対策としてタイムスタンプとチケットの有効期限を組み込んだ最初期の本格的な実装
  • 1990年代 ：インターネットの普及とともにHTTP通信への応用が広がり、Webアプリケーションでの被害事例が増加
  • 2000年代 ：ネットバンキングやECサイトの拡大により、二重送金や不正決済を狙ったリプレイ攻撃が社会問題化
  • 2010年代〜 ：OAuth 2.0やJWT（JSON Web Token）など、ノンス（nonce） や署名を組み込んだ現代的な認証標準が普及し、対策が標準化へ

主な対策と関連技術

リプレイ攻撃を防ぐための技術は「同じデータを2度使えなくする」という発想が基本です。

リプレイ攻撃の主な対策技術 タイムスタンプ方式 リクエストに現在時刻を 埋め込み、一定時間外の リクエストは拒否する 例: 5秒以上前のデータは 無効として弾く ノンス（Nonce）方式 サーバーが使い捨ての ランダム値を発行し、 一度使ったら無効化する 例: OAuthの stateパラメータ シーケンス番号方式 通信ごとに連番を付与し 同じ番号が来たら拒否 もしくは順序異常を検知 例: TLSの シーケンス番号管理 ワンタイムパスワード（OTP） ログインのたびに新しいパスワードを生成・使用。 一度使ったパスワードは二度と有効にならないため、 盗んでも再利用できない。銀行のトークンや スマホ認証アプリ（Google Authenticatorなど）に採用。 「使い捨てのチケット」なので再利用不可能！

各対策技術を比較するとこうなります。

対策手法仕組み採用例注意点
タイムスタンプ時刻のズレで不正を検知Kerberos、AWS署名送受信側の時刻同期が必要
ノンス（nonce）使い捨ての乱数で検証OAuth 2.0、OpenID Connectサーバー側で管理コスト発生
シーケンス番号連番で二重受信を検知TLS、IPsec番号の管理と同期が必要
OTP毎回新しいパスワードを生成銀行トークン、TOTPユーザーの操作が増える
セッションの短命化セッションIDに短い有効期限Webアプリ全般頻繁な再認証が必要になる

関連する規格・RFC

規格・RFC番号内容
RFC 4120Kerberosネットワーク認証サービス（タイムスタンプ・チケット有効期限によるリプレイ対策を規定）
RFC 6749OAuth 2.0認証フレームワーク（stateパラメータによるCSRF・リプレイ対策）
RFC 6238TOTP（Time-Based One-Time Password）アルゴリズムの標準仕様
RFC 4301IPsecセキュリティアーキテクチャ（アンチリプレイウィンドウ機構を含む）
RFC 8446TLS 1.3（シーケンス番号管理とリプレイ対策の強化）

関連用語

  • 中間者攻撃 — 通信の盗聴・改ざんを行う攻撃。リプレイ攻撃の「傍受」ステップと組み合わせて使われることが多い
  • ノンス — 一度しか使えない使い捨ての乱数値。リプレイ攻撃対策の代表的な手段
  • [ワンタイムパスワード](./one-time-password