2

サーバー側認証のない API を構築しています。セッション用に一意のキー (キーが非常に長く、推測できないと想定) が生成されますが、クライアントには Cookie が設定されません。クライアントは、AJAX を使用する Web ブラウザー、CURL を使用する PHP スクリプト、またはデスクトップ アプリケーションです。私が想像している通常の取引プロセスは次のようになります。

最初の出会い

  1. クライアントは start_session メソッドを呼び出して最初のリクエストを行います
  2. サーバーはキーを生成し、それをいくつかの初期データとともに返します
  3. クライアントは、後で使用するためにキーを保存します (たとえば、JavaScript はキーを使用して Cookie を設定します)。

次のリクエスト

  1. クライアントはサーバーに再度リクエストし、set_data メソッドを呼び出して元のセッション キーを提供し、クレジット カード番号や訴訟に関する情報などのプライベート データをロードします。
  2. サーバーが応答し、 が成功メッセージで応答します

別のリクエスト

  1. クライアントはサーバーに再度要求し、元のセッション キーを提供して get_data メソッドを呼び出します。
  2. サーバーは、すべてのプライベート データを何らかの形式 (XML、JSON など) で応答します。

セッション キーは、使用しないと 20 分で期限切れになり、すべての API URI で SSL が必要になります。

私の懸念/質問は: クライアントがセッションキーを漏らしたかどうかについて心配する必要がありますか? 認証がなければ、元のリクエスタがセッション キーを非公開にしていると信じています。これは一般的/安全な慣行ですか?

4

1 に答える 1

1

全体で HTTPS を使用しない限り、 Firesheep のような HTTP スニッフィングに対して脆弱です。

SSL を使用している場合でも、クライアント ページが SSL でないか、非 SSL Javascript (または同じドメイン内の非 SSL フレーム) を含んでいる場合は、依然として脆弱です (そして、それに対してできることは何もありません)。

あなたが述べた質問に答えるには、それはあなたの状況に完全に依存します.
編集: キーを正しく処理するために、ドキュメント ページでクライアント (開発者) に警告する必要があります。
それを超えて、それはクライアントの平均的なスキルレベルに依存します.
なんらかの免責事項があるはずです (私は弁護士ではありません)。

たぶん大丈夫です。

于 2010-11-29T01:22:10.843 に答える