オープンAPIインターフェースの署名検証により、インターフェースが裸で実行されなくなります。

Javaテクノロジスタック

www.javastack.cn

より質の高い記事を読むためにフォロー

インターフェースのセキュリティ問題

リクエストされた身元は合法ですか？
リクエストパラメータが改ざんされていませんか？
リクエストは一意ですか？

AccessKey＆SecretKey（オープンプラットフォーム）

本人確認

AccessKey（一意性を確保するための開発者ID）とSecretKey（インターフェースの暗号化に使用され、網羅的でなく、生成アルゴリズムが容易に推測できないようにする）を開発者に割り当てます。

改ざんを防ぐ

パラメータの署名

空でない要求パラメーター（AccessKeyを含む）を要求パラメーター名の昇順のアルファベット順に配置し、URLのキーと値のペアの形式（つまり、key1 = value1＆key2 = value2 ...）を使用して、文字列stringAにスプライスします。
stringAの最後で、Secretkeyを接合して文字列stringSignTempを取得します。
stringSignTempでMD5操作を実行し、取得した文字列のすべての文字を大文字に変換して、符号値を取得します。

リクエストにはパラメーターAccessKeyとSignが含まれており、正当なID AccessKeyと正しい署名がある場合にのみ解放できます。

これにより、本人確認とパラメータの改ざんの問題が解決されます。リクエストパラメータがハイジャックされた場合でも、SecretKeyは取得できず（ローカル暗号化のみで、ネットワーク送信には関与しません）、正当なリクエストを偽造することはできません。

リプレイ攻撃

リクエストパラメータが改ざんされるという隠れた危険は解決されますが、セカンダリリクエストを偽造するためにリクエストパラメータを繰り返し使用するという隠れた危険は依然としてあります。

timestamp + nonceスキーム

Nonceは、署名された各要求を識別するために使用される一意のランダム文字列を指します。各リクエストに一意の識別子を提供することにより、サーバーはリクエストが複数回使用されることを防ぐことができます（使用されたすべてのナンスを記録して、再度使用されるのを防ぎます）。

ただし、受信したすべてのナンスを永続的に保存するコストは、サーバーにとって非常に高くなります。タイムスタンプを使用して、ナンスのストレージを最適化できます。

クライアントとサーバーの間に最大15分の時間差があり、サーバーに記録されたノンスセットが追跡されると仮定します。

新しいリクエストが届いたとき、最初にキャリータイムスタンプが15分以内かどうかを確認し、タイムレンジを超えている場合は拒否し、キャリーナンスをクエリします。既存のセットがある場合は拒否します。

それ以外の場合は、ナンスを記録し、コレクション内のタイムスタンプが15分を超えるナンスを削除します（redisの有効期限を使用し、ナンスを追加して、タイムアウトの有効期限を15分に設定できます）。Redisシリーズの記事の乾物については、公開番号のJavaテクノロジースタックを参照して読むことができます。

成し遂げる

请求接口：http://api.test.com/test?name=hello&home=world&work=java

クライアント

現在のタイムスタンプtimestamp = nowおよび一意のランダム文字列nonce = randomを生成します
空でないリクエストパラメータ（AccessKeyを含む）をリクエストパラメータ名のアルファベット順に昇順に並べ替えます
stringA="AccessKey=access&home=world&name=hello&work=java&timestamp=now&nonce=random";
スプライシングキーSecretKey
stringSignTemp="AccessKey=access&home=world&name=hello&work=java&timestamp=now&nonce=random&SecretKey=secret";
MD5と大文字に変換
sign=MD5(stringSignTemp).toUpperCase();
最終リクエスト
http://api.test.com/test?name=hello&home=world&work=java&timestamp=now&nonce=nonce&sign=sign;

サーバ

Token＆AppKey（APP）

APPオープンAPIインターフェースの設計では、ほとんどのインターフェースにユーザーの個人情報と製品の機密データが含まれているため、これらのインターフェースは認証される必要があります。セキュリティ上の理由から、ユーザーはプレーンテキストのパスワードをできるだけ少なく公開する必要があります。ただし、クライアントとサーバー間の対話は、要求間でステートレスです。つまり、ユーザーの状態になると、各要求は認証情報を提供する必要があります。

トークン認証

ユーザーはログインし、サーバーに認証情報（アカウント番号やパスワードなど）を提供します。認証が成功すると、サーバーはトークンをクライアントに返します。
クライアントはトークンをローカルに保存し、後続のリクエストを行うときにこのトークンを保持します。
サーバーはTokenの有効性をチェックし、有効な場合はトークンを解放し、無効な場合（トークンが間違っているか期限切れ）は拒否します。

セキュリティ上のリスク：トークンが乗っ取られ、リクエストが偽造され、パラメータが改ざんされています。「安全な外部インターフェースの設計」も読むことをお勧めします。

Token + AppKey署名検証

上記の開発プラットフォームの検証方法と同様に、クライアントにはAppKey（インターフェースの暗号化に使用され、送信には関与しない）が割り当てられ、AppKeyとすべての要求パラメーターがソース文字列に結合され、署名アルゴリズムに従って署名値が生成されます。署名値は検証のためにサーバーに送信されます。

このようにして、トークンがハイジャックされた場合でも、相手はAppKeyと署名アルゴリズムを知らず、リクエストを偽造してパラメーターを改ざんすることはできません。上記の再送信攻撃ソリューションと組み合わせると、リクエストパラメータがハイジャックされたとしても、2回目のリクエストを繰り返すことはできません。