服务端提供各种功能接口供客户端调用，那么怎样才能确保请求是来自合法的客户端，而不是非法的请求呢？
ringa_lee
トークンを検証するか、サーバー側でOAuth2フレームワークを使用します
合法と違法をどのように定義しますか? SSO フレームワークでは、トークンを持っている場合は、必ず appid と appsecret が必要になります。認可が必要な場合は、AccessToken も必要になります。最も簡単な方法は、信頼できる IP のみの通過を許可する IP インターセプターを作成することですが、これは一般的に、相手がトークンまたはアプリ シークレットを提供する場合に使用されます。合法ですよね？
API を設計するとき、RESTful API のセキュリティを確保するには、次の 3 つの主要な側面を考慮する必要があります。
1. 制限付きリソースのログイン認証2. リクエストの ID 認証3. 1. 制限付きリソースのログイン認証 このプロセスはこの記事の焦点ではないため、詳細は説明しません。基本的なプロセスは次のとおりです。
2. リクエストの ID 認証3. 1. 制限付きリソースのログイン認証
クライアントはアカウント情報 (ユーザー名 + パスワード) をサーバーに送信します
サーバーは正常に検証し、ストレージ用に AccessToken をクライアントに返します
2. 認証のリクエスト
URL:schema://domain/path?query&imei×tamp&sign
署名メソッドsign=signature(path?query&imei×tamp&SIGN_KEY)
検証プロセス認証ロジック1. 最初に、サーバーは各アプリバージョンのSIGN_KEYを持ち、クライアントは対応するバージョンのSIGN_KEYを持ちます
3.リクエストを送信するとき、サーバーは、最初にタイムスタンプが有効かどうかを検証します。次に、5 分前のサーバー タイムスタンプを受け取ります。署名を検証するための SIGN_KEY の対応するバージョンは合法ですか? 6. リプレイ攻撃を防ぐために、署名が redis に保存されているかどうかを確認する必要があります。存在しない場合は、redis に保存します (5 分間キャッシュします)。 データの改ざんを防ぐ方法 署名パラメータには元のリクエストのすべてのパラメータが含まれており、パラメータが変更されると、符号の値が異なるため、改ざんすることはできません。 リプレイ攻撃を防ぐ方法署名アルゴリズムにはimei（固有のデバイスID）とタイムスタンプパラメータもあり、署名アルゴリズムは不可逆アルゴリズム（md5やsha1など）であるため、通常のリクエストごとに符号値が繰り返されることはありません。現時点では、サーバーはリプレイ攻撃中の検証とフィルタリングのために 5 分の符号値を保存でき、5 分を超えるリクエストはタイムスタンプ検証によって直接フィルタリングされます。 まとめ
3. 機密データの暗号化
2) 一部の機密データ (アカウント番号 + パスワードなど) のみを暗号化し、データの改ざんを防ぐために暗号化ソルトとして乱数を追加します。
リクエストデータのすべてのパラメータがjsonに変換され、サーバーのRSA証明書を使用してjsonが暗号化され、サーバーの秘密キーが復号化されます。
oauth2 または同様のトークンを使用します
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
トークンを検証するか、サーバー側でOAuth2フレームワークを使用します
合法と違法をどのように定義しますか? SSO フレームワークでは、トークンを持っている場合は、必ず appid と appsecret が必要になります。認可が必要な場合は、AccessToken も必要になります。最も簡単な方法は、信頼できる IP のみの通過を許可する IP インターセプターを作成することですが、これは一般的に、相手がトークンまたはアプリ シークレットを提供する場合に使用されます。合法ですよね？
API を設計するとき、RESTful API のセキュリティを確保するには、次の 3 つの主要な側面を考慮する必要があります。
クライアントはアカウント情報 (ユーザー名 + パスワード) をサーバーに送信します
-
-
URL形式サーバーは正常に検証し、ストレージ用に AccessToken をクライアントに返します
3. 制限されたリソースにアクセスする場合、クライアントは AccessToken を持ち込むことでアクセスできます。
リクエストが署名および認証されていない場合は、fiddler などのツールを使用してデータを簡単に取得し、改ざんして送信し、大規模なバッチ呼び出しを行うことができます。これにより、システムが大量のジャンクデータとシステムリソースが大量に消費され、通常使用することさえできないため（もちろん、GateWay を通じて電流を制限できます）、リクエストに対して署名認証を実行する必要があります。2. 認証のリクエスト
URL:schema://domain/path?query&imei×tamp&sign
パラメータの説明署名メソッド
sign=signature(path?query&imei×tamp&SIGN_KEY)
検証プロセス
2. リクエストを送信する前に、署名メソッドを通じて暗号化して署名を取得します認証ロジック
1. 最初に、サーバーは各アプリバージョンのSIGN_KEYを持ち、クライアントは対応するバージョンのSIGN_KEYを持ちます
3.リクエストを送信するとき、サーバーは、最初にタイムスタンプが有効かどうかを検証します。次に、5 分前のサーバー タイムスタンプを受け取ります。署名を検証するための SIGN_KEY の対応するバージョンは合法ですか? 6. リプレイ攻撃を防ぐために、署名が redis に保存されているかどうかを確認する必要があります。存在しない場合は、redis に保存します (5 分間キャッシュします)。
このように、データの改ざんやリプレイ攻撃を防ぐためにリクエスト認証が実現されますが、アプリキー(SIGN_KEY)の安全な保管を確保する必要があるため、理解と実装が簡単であるという利点があります。欠点は、キーの安全な保管と定期的な更新の負担が必要なことです。データの改ざんを防ぐ方法
署名パラメータには元のリクエストのすべてのパラメータが含まれており、パラメータが変更されると、符号の値が異なるため、改ざんすることはできません。
リプレイ攻撃を防ぐ方法
署名アルゴリズムにはimei（固有のデバイスID）とタイムスタンプパラメータもあり、署名アルゴリズムは不可逆アルゴリズム（md5やsha1など）であるため、通常のリクエストごとに符号値が繰り返されることはありません。現時点では、サーバーはリプレイ攻撃中の検証とフィルタリングのために 5 分の符号値を保存でき、5 分を超えるリクエストはタイムスタンプ検証によって直接フィルタリングされます。
まとめ
1) SSL インフラストラクチャ (つまり HTTPS) を導入し、機密データの送信はすべて SSL に基づいて行われます。3. 機密データの暗号化
2) 一部の機密データ (アカウント番号 + パスワードなど) のみを暗号化し、データの改ざんを防ぐために暗号化ソルトとして乱数を追加します。
リクエストデータのすべてのパラメータがjsonに変換され、サーバーのRSA証明書を使用してjsonが暗号化され、サーバーの秘密キーが復号化されます。
oauth2 または同様のトークンを使用します