APPとWebサーバーの間のインターフェースでのトークン検証について質問がありますか?

パケット キャプチャを通じて api_token、user_token などのすべてのパラメーターとヘッダーを取得すると、短時間で取得したパラメーターを直接取得でき、検証ルールは引き続きこのインターフェイスを使用できます。 ? 考えられる唯一の方法は、トークンの検証時間を短縮することです。 マスターたちはこの問題をどうやって解決したのだろうか？

返信内容:

これがトークンの役割です...トークンは単にあなたが使用するために設計されたものではありませんか?トークンの設計の主な目的は、ユーザーのユーザー名とパスワードを長期間保存することではないため、ランダムなコードに変換されます。このコード自体がユーザー名とパスワードを置き換える機能を備えているため、一度漏洩すると、当然の結果は深刻なものになるだろう。
現在、セキュリティレベルの高い API は一般に HTTPS のみを使用できます。この方法では、接続上のコンテンツをパスの途中からキャプチャすることはできないため、トークンが他の人に漏洩することはありません。両端については、1 つは本来ユーザーであり、もう 1 つは自分のサーバーです。このトークンは、両者間で共有されるべきコンテンツです。
過去には、api_key と Secret_key の 2 つの値を使用する別の設計がありました。この場合、api_key は HTTP のクリア テキストで送信されますが、secret_key は HTTP クリア テキストには表示されませんが、MD5 ハッシュの一部として参加し、一般に正規化されます。 URL パラメーター全体 (パラメーター名でソートし、一律に小文字に変換し、URL を正しくエンコードします)、次に Secret_key を追加し、MD5 を計算し、パッケージがキャッチされた場合でも MD5 を追加の sig パラメーターとして HTTP 経由で渡します。真ん中の場合は api_key のみが表示されます。 Secret_key が表示されない場合は、このインターフェイスを自由に使用することはできません。しかし、この設計には、パラメータを自由に再結合することはできませんが、以前に取得したパラメータを再利用することはできますが、これはまだ安全ではありません。さらに、 Secret_key を端末に安全に配布する手段が不足しています。したがって、実際には HTTPS を直接使用する方が効率的です。

参考として、OAuth 2.0 の設計を見てみましょう。OAuth 2.0 は、ユーザー、認証センター、およびサードパーティ アプリケーション間の関係に関係する、より複雑な問題を抱えています。トークンを取得し、漏洩してはいけない相手へのトークンの漏洩を防ぐ方法:

1. OAuth サーバーとサードパーティ サーバーは同時に同じ api_key、secret_key を知っています
2. ユーザーとサードパーティのサーバーは同時に api_key を知っています (通常はサードパーティのアプリケーションまたは Web ページが保持します)
3. ユーザーと OAuth サーバーは同じユーザー名とパスワードを同時に知っており、サードパーティのサーバーは同じユーザー名とパスワードを同時に知っています。パーティ アプリケーションは知りません
4. ユーザーがサードパーティ ログインを申請する場合、api_key を使用して OAuth サーバー ログイン インターフェイスを呼び出し (通常はサードパーティ アプリケーションによってガイドされます)、OAuth サーバー ページでユーザー名とパスワードを入力します。 OAuth サーバーは auth_code を返します。これは一時的なトークンと見なすことができます。この手順では、ユーザー名とパスワードが盗まれないように https を使用する必要があります。
5. ユーザーは auth_code を使用してサードパーティ アプリケーションのインターフェイスを呼び出します (通常、コールバック メカニズムによって自動的に完了します)。このステップでは HTTP を使用できるため、auth_code が漏洩する可能性があります。
6. サードパーティ アプリケーションは auth_code + api_key を使用します。 + Secret_key は、OAuth サーバーのログインの 2 番目のステップを呼び出し、公式トークンである access_token を取得するインターフェイスです。 auth_code は漏洩する可能性がありますが、攻撃者は Secret_key を取得できないため、auth_code をトークンの代わりに使用することはできません。この手順では、secret_key が漏洩しないように HTTPS を使用する必要があります。

この時点で、サードパーティアプリケーションはaccess_tokenの取得に成功しており、このaccess_tokenはOAuthサーバーとサードパーティサーバー間でのみ共有され、ユーザーを含む第三者に漏洩することはありません。このプロセスは主に HTTPS の暗号化機能に依存して、最も重要なデータ (ユーザー名、パスワード、secret_key) が漏洩しないようにしていることがわかります。さらに、セキュリティ レベルが異なるトークンには異なるタイムアウトを設定する必要があります。たとえば、auth_code のタイムアウトは非常に短く、access_token のタイムアウトは比較的長くなります。

インターフェイスは https を使用しており、キャプチャされたパケットはすべて文字化けしています。しかし、仲介業者のふりをする方法もあるのでしょうか？ ご招待ありがとうございます...
最も極端な方法:
各トークンは 1 回だけ有効です...

もちろん、これには多くの読み取りおよび書き込み操作が含まれます。
だから…普段はこんなことしないんですが… md5 署名には乱数、トークン、タイムスタンプが使用され、署名、乱数、タイムスタンプが一緒にサーバーに送信されます。 これは当てはまりません。セッションは最初にサーバー側で判断される必要があり、それに合格した後でのみ、作成したトークン検証に入ることができます。 1: https;
2: 認証モジュールは独立しており、トークンはセッションに入力され、再度検証されます。
3: トークンはビジネスの重要性に応じて頻繁に変更されます。

上記の個人的な意見は厳密ではないかもしれません