リプレイ攻撃とは

この記事は約 2 分で読めます

リプレイ攻撃 (Replay Attack) とは、正規の通信データを傍受し、そのデータをそのまま再送信することで不正アクセスを試みる攻撃手法です。攻撃者は暗号を解読する必要がなく、正規の認証済みデータを「録画して再生する」だけで攻撃が成立する点が特徴です。中間者攻撃と組み合わせて実行されることが多く、認証トークン、API リクエスト、金融取引データなど、あらゆる通信が標的になりえます。シンプルな原理でありながら、適切な対策がなければ通信の暗号化だけでは防げない厄介な攻撃です。

攻撃の仕組み

1. 傍受
正規通信をキャプチャ

2. 保存
データをそのまま記録

3. 再送信
サーバーに同一データ送信

4. 受理
サーバーが正規と誤認

重要なのは、攻撃者がデータの中身を理解する必要がないという点です。暗号化されたデータであっても、そのまま再送すればサーバーは正規のリクエストとして処理してしまいます。TLS による暗号化は盗聴を防ぎますが、正規のセッション内でキャプチャされたデータの再利用は防げません。

セッションハイジャックとの違い

リプレイ攻撃とセッションハイジャックは混同されがちですが、攻撃のメカニズムが異なります。

リプレイ攻撃

過去の通信データを再送信
元のセッションは終了済みでも可
データの改変は不要
対策: ノンス、タイムスタンプ

セッションハイジャック

アクティブなセッションを乗っ取る
セッションが有効な間のみ有効
セッション ID の窃取が必要
対策: セッション固定化防止、再認証

対策技術

リプレイ攻撃への対策は、「同じデータを 2 回使えなくする」仕組みの導入に集約されます。

ノンス (Nonce)一度だけ使用可能なランダム値をリクエストに含め、サーバー側で使用済みノンスを記録して再利用を拒否するタイムスタンプリクエストに現在時刻を含め、一定時間 (例: 5 分) を超えた古いリクエストを拒否するチャレンジ-レスポンスサーバーが毎回異なるチャレンジを送り、クライアントがそれに基づく応答を返す。過去の応答は再利用不可シーケンス番号通信に連番を付与し、番号の重複や逆行を検知して拒否する

FIDO/WebAuthn がリプレイ攻撃に強い理由

FIDO/WebAuthn プロトコルは、リプレイ攻撃への耐性を設計段階から組み込んでいます。認証のたびにサーバーがランダムなチャレンジを生成し、クライアントはそのチャレンジに対して秘密鍵で署名を行います。署名にはチャレンジ値、オリジン (接続先のドメイン)、認証器のカウンター値が含まれるため、過去の署名を再送してもチャレンジの不一致で即座に拒否されます。セッションハイジャック対策やセッショントークン窃取対策とあわせて、認証フロー全体の堅牢化を図ることが重要です。

Kerberos のチケット有効期限

Active Directory 環境で広く使われる Kerberos 認証プロトコルも、リプレイ攻撃対策を内蔵しています。認証チケット (TGT) には有効期限 (デフォルト 10 時間) が設定されており、期限切れのチケットは拒否されます。さらに、各リクエストにタイムスタンプを含め、サーバーとクライアントの時刻差が 5 分以内であることを検証します。この時刻同期の要件は、Kerberos 環境で NTP サーバーの運用が必須とされる理由でもあります。

リプレイ攻撃は古典的な手法ですが、IoT デバイスや API 通信の増加に伴い、対策が不十分なシステムは今なお多く存在します。二要素認証の導入と組み合わせることで、認証の堅牢性をさらに高められます。ネットワークセキュリティの専門書 (Amazon)でプロトコルレベルの対策を深く学ぶことを推奨します。