リプレイ攻撃を回避するにはHTTPSで十分ですか？

モバイルアプリ用のサーバーでいくつかのRESTメソッドを公開しています。

ユーザーが（モバイルアプリから）HTTPメソッドを構築する方法を傍受し、サーバーに再度送信することを避けたいと思います。例：

• モバイルアプリがリクエストを送信する
• ユーザーはプロキシを使用して、ネットワークで何が起こっているかを確認できます
• ユーザーは、モバイルが送信したリクエストを確認して保存します
• =>ユーザーがそのリクエストを手動で送信できないようにしたい

HTTPS経由でサーバーを保護するのに十分ですか？

サーバーがrfc2246セクションF.2に従ってTLSプロトコルのみを許可するように構成されている場合、HTTPSはサーバーをリプレイ攻撃（同じメッセージが2回送信される）から保護するのに十分です。

送信データは、送信前にMACで保護されます。メッセージの再生または変更攻撃を防ぐために、MACはMACシークレット、シーケンス番号から計算されます[...]

HTTPSは、転送されるデータが暗号化され、クライアントとサーバーだけが暗号化を解除できることを意味します（理想的な世界では、MITM攻撃などについて話さない）。

そのため、プロトコルにはリプレイ攻撃の発生を止めるものはありません。

アプリケーションが再生攻撃に対して脆弱でないことを確認するために、何らかの種類の再生攻撃回避メカニズム（有効期限切れのトークン、またはプロセスの終了後に無効になるトークンなど）を組み込む必要があります。このメカニズムは、通常のHTTPで使用できます。