{OCR最近のリーダーシップはそう、支払インターフェースリプレイ攻撃があるかどうか、研究を行うために、同社のビジネスクラスのインターフェイスを支払うために私に尋ねました。。。。。}

また、リプレイ攻撃、リプレイ攻撃として知られているAPIのリプレイ攻撃（リプレイ攻撃）、。彼の原則は、受信者にそのままタップする前にデータを再送信することです。HTTPSは、データ送信は暗号化されているものの、盗聴者が正確な定義データを得ることができない、このような攻撃を防ぐことはできませんが、受信者のアドレスからこれらのデータ要求の影響を分析することができます。例えば、攻撃者がパスワードを盗聴することはできませんが、それは暗号化されたパスワードを傍受して、それを再生することができ、非常に効果的な攻撃のためにこのようものの、ユーザーのログ要求。

いわゆるリプレイ攻撃は、攻撃者は、リプレイ攻撃がハッカーの攻撃で使用され、世界のコンピュータの一つである宛先ホストが主に身元の認証プロセスに使用されるシステムを欺くの目的を達成するためのパケットを介して受信した送信です。

HTTPリクエスト、中間受信機へのリクエスタからのデータがルータやスイッチの数を通過するように、攻撃者は、要求をインターセプトすることができます。オンライン預金システム、ユーザーが預金を引き出すことを示すメッセージを仮定し、攻撃者が預金を盗むために、このメッセージを複数回送信することができます。

セキュリティのインターフェイスに対応するAPIを持っていない場合、再生は2番目のリクエストである、可能性が非常に深刻な影響が発生します。

以下の主なポイントを持っている共通のセキュリティインタフェースAPI：

防止、SQLインジェクション
防止XSS攻撃
リクエストパラメータは、改ざんを防止しています
防ぎリプレイ攻撃

主な予防措置は2点に集約することができます。

検証のための要求の有効性には
要求されたデータの検証

一度だけのために要求することを確認する必要があり、リプレイ攻撃を防ぐために
それを運ぶために必要が一意要求本体に現在の要求を識別し、改ざんを防止するために署名されています。
だから、リプレイ攻撃が一番上にある署名の改ざんを防ぐために基づきする必要が防ぎます。

リクエストパラメータ不正防止

平文伝送を使用してHTTPSプロトコルを暗号化することができますが、まだハッカーはデータパケットの送信、さらに鍛造リクエストリプレイ攻撃を横取りすることもできます。通信に偽造証明書を使用して、要求元のデバイスを有効にするために特別な手段を使用してハッカー場合は、HTTPS暗号化されたコンテンツも復号化されます。
また、当社は、APIインターフェースHTTPS通信のためのプロトコルが、また、暗号化と復号化メカニズムの独自のセットを持っている必要があり、改ざんから保護リクエストパラメータを使用します。
次のようにプロセスは以下のとおりです。

クライアントはよく一致暗号化された伝送パラメータに秘密鍵を使用して、署名の署名値が得られ、かつ要求へのパラメータの署名値は、サーバーにリクエストを送信します

その後、クライアントの要求を受信し、サーバは、署名値のサインを得るために、再び署名（署名を除く）リクエストパラメータの良好な一致に秘密鍵を使用します。

比較サーバとサイン署名値、及び比較は、正当なリクエストとして認識、一致している場合。比較が矛盾している場合は、説明のパラメータは、改ざん、不正な要求として識別されます。

ハッカーが傍受された要求データ、リクエストパラメータを改ざんしても、署名秘密鍵を知らないが、パラメータに署名することはできませんので、パラメータは、署名値署名を変更することはできません。
私たちは多くのプログラム、対称暗号化または非対称暗号化を使用することができます署名鍵を使用することができます。

防ぎリプレイ攻撃

タイムスタンプベースのスキーム

各HTTPリクエストは、あなたはタイムスタンプのパラメータを追加する必要があり、その後、タイムスタンプや電子署名の他のパラメータを一緒に行きました。サーバから送信された通常のHTTPリクエストは、一般的に到達するためのHTTPリクエストを受信した後、サーバは、最初に現在時刻が60秒を超えると比較して、タイムスタンプパラメータを決定するように超えては違法であると考えられる場合は、60代を超えませんリクエスト。

一般的には、はるかに多くの60代以上の再生キャプチャ要求を消費するからハッカーは、ので、この場合には、パラメータ要求のタイムスタンプの有効期限が切れています。
ハッカーは現在のタイムスタンプタイムスタンプのパラメータを変更する場合は、ハッカーが署名鍵を知らないので、デジタル署名に対応する署名パラメータは無効となり、新しいデジタル署名を生成する方法はありません。

このアプローチは一度だけの要求を保証することはできませんので、しかし、このアプローチは、それが動作しない、60年代後のリプレイ攻撃ならば、明らか抜け穴です。

ノンスベースのソリューション

唯一のランダムな文字列いったん有効であるナンスの手段は、各要求に必要な、確保するために、異なるパラメータ、直接進数のタイムスタンプ実用化には、ここでは便宜上、一般的にタイムスタンプに関連するパラメータそうクライアントは、ナンスパラメータとしてハッシュするIPアドレス、MACアドレスやその他の情報の後に追加することができるとき。
パラメータナンス我々の要求は、「コレクション」に格納されるたびにデータベース形式またはJSONキャッシュに格納することができます。
HTTPリクエストのプロセスが最初に不正な要求があると考えられている場合は、「コレクション」でナンスパラメータを要求したかどうかを決定するたびに。

ナンスのパラメータ最初の要求は、サーバー上の「セット」に格納されている場合、再送信要求を識別し、拒否されます。
ナンスのパラメータは、デジタル署名の一部として、ハッカーがトークン知っているので、それは新しい符号を生成することはできません、改ざんすることはできません。

このアプローチは、あること、「コレクション」時間のかかる中でナンス「コレクション」の存在を確認するために、ますます大規模なストレージナンスパラメータとなり長く、長くなっされるも大きな問題です。私たちは、定期的に「コレクション」をクリーンアップする必要があり、一回だけの「コレクション」無限を任せることはできないが、「コレクションは」クリーンアップすることになると、我々はナンスパラメータがアップクリアするために確認することはできません。それ攻撃を再生することができませんでしたが、一度きれいにする「コレクション」の平均1日と仮定して、我々は、URLにクロールされていますが、私たちは一日一回リプレイ攻撃することができます。そして、ストレージの24時間以内に、すべての「ナンス」パラメータ要求は、小さなオーバーヘッドではありません。

ベースのタイムスタンプとノンスプログラム

1回の問題は60年代のタイムスタンプパラメータを解くことができるナンス、タイムスタンプが成長している問題は、パラメータ「コレクション」nonceを解決することができます。
船やリプレイ攻撃を防ぐには、図に示すように、リクエストパラメータの改ざんが一緒にやる、ヘッダは、データを要求しないようにするためです。

我々は唯一の60年代のナンスパラメータに「コレクション」を格納する必要があるので、60代以上の要求のためのtimstampパラメータは、我々は、その不正な要求を同意するので、我々は、タイムスタンプ、プラスナンスパラメータに基づいて計画しています。
検証プロセスインタフェースAPI：

//取得トークン
文字列トークン= request.getHeader（「トークン」）。
//タイムスタンプを取得します
ストリングタイムスタンプ= request.getHeader（「タイムスタンプ」）。
//ランダムな文字列を取得します。
ストリングnonceStr = request.getHeader（ "nonceStr"）。
//要求アドレスを取得します。
文字列のURL = request.getHeader（ "URL"）;
署名を取得します//
ストリング署名= request.getHeader（「署名」）。

それが空であるかどうかを//チェック
IF（StringUtils.isBlank（トークン）|| StringUtils.isBlank（タイムスタンプ）|| StringUtils.isBlank（nonceStr）|| StringUtils.isBlank（URL）|| StringUtils.isBlank（署名））{
    //不正な要求
    リターン;
}

//有効性トークンを検証し、ユーザーが情報を入手します
UserTokenInfo userTokenInfo = TokenUtils.getUserTokenInfo（トークン）。

IF（userTokenInfo == NULL）{
    //トークン認証失敗（偽造トークンを防ぐため）
    リターン;
}

// urlパラメータ要求が正しい場合
（！request.getRequestURI（）。等号（URL））であれば{
    //不正な要求（クロスドメイン攻撃を防ぐために）
    リターン;
}

//時間が60秒よりも大きいか否かを判定する
IF（DateUtils.getSecond（） -  DateUtils.toSecond（タイムスタンプ）> 60）{
    //は、（リプレイ攻撃を防ぐために）タイムアウトを要求します
    リターン;
}

//ユーザーがRedisの中nonceStrパラメータを有しているか否かを判定する
IF（RedisUtils.haveNonceStr（userTokenInfo、nonceStr））{
    //（リプレイ攻撃に短い時間を防止するために）一度だけ有効な要求
    リターン;
}

//リクエストヘッダパラメータ署名
文字列の列B = SignUtil.signature（トークン、タイムスタンプ、nonceStr、URL、リクエスト）。

//署名は検証に合格しない場合
もし（！のsignature.equals（列B））{
    //不正な要求（パラメータを改ざんを防止するための要求）
    リターン;
}

//ユーザの要求nonceStr耐えるRedisののパラメータが自動的に60秒で削除しました
RedisUtils.saveNonceStr（userTokenInfo、nonceStr、60）。

//正当な要求の処理を開始

上記の溶液に基づいて、受信したパラメータをAPIリクエストを改ざんし、リプレイ攻撃を防止することができるAPIを防ぐために行うことができます。

オリジナルリンク：https://blog.csdn.net/weixin_39997829/article/details/89083139

改ざんを防止するためのAPIインタフェースパラメータとリプレイ攻撃

リクエストパラメータ不正防止

防ぎリプレイ攻撃

タイムスタンプベースのスキーム

ノンスベースのソリューション

ベースのタイムスタンプとノンスプログラム

おすすめ