1

まず最初に、これはサービス アクセス制御に関する他の多くの質問と非常によく似ていると認識していますが、以下のすべての点に関連する 1 つの回答を見つけることができないようです。そのため (おそらく) もう一度質問します.

背景: カスタム フォーム認証の実装によって保護されている .NET を使用して Web アプリケーションを構築しています。この同じアプリ (同じドメイン内) は、JavaScript/jQuery 内からのデータ管理に関連するいくつかの REST サービスを活用する必要があります。これは、アプリの機能の多くがフォームでのポストバック使用に適していないためです。

アプリが最初にアクセスされたときにサーバー側で行われた認証に基づいて、REST サービスのアクセス制御を実装する最も安全な方法を決定しようとしています。

以下は、私が説明しているものの使用例です。

  1. ユーザーはフォーム認証を使用して asp.net サイトにログインし、認証が成功すると、ユーザーはアプリケーションのランディング ページに移動します。
  2. ユーザーは、ランディング ページのリンクから ~/Users.aspx のページにアクセスすることを選択します。これは、ステップ 1 の認証によって作成された Cookie に基づいてフォーム認証が許可されます。
  3. users.aspx は、空のテーブルや、ページの読み込み時に生成されるトークン (GUID) を含む隠しフィールドなど、いくつかの基本的な HTML 要素を読み込みます。非表示フィールドのトークンは、JavaScript がデータを取得してテーブルに入力する REST サービスにアクセスするために使用されます。トークンは、定義済みの有効期限でデータベースに保存されます。
  4. トークンを使用して REST サービスが呼び出されると、トークンの有効期限がチェックされ、呼び出しを行うユーザーを特定し、データベースからアクセスされるデータに承認を与えるために使用されます。ユーザーがデータへのアクセス/更新を承認されている場合、サービスはサービス操作を要求し、トークンの有効期限を延長して、応答を返します。

送信の暗号化に SSL が使用されていない限り、トークンはネットワーク上の要求/応答を盗聴している誰かに見えることを知っているので、これに対抗するために SSL が使用されます。

私の質問は:

  1. サービスが脆弱になる他の攻撃はありますか?
  2. サービスに静的に割り当てられたトークン以外に、サーバー側のログインに基づいて REST サービスの承認とユーザー識別を処理するより良い方法はありますか? 静的に割り当てられたユーザー トークンは、悪意のあるユーザーによって取得された場合にサービスへの無限のアクセスを許可するため、安全性が低くなるように思えます。
  3. #2への答えが「いいえ」であると仮定すると、トークンをクライアントに送信し、JavaScript/jQueryからアクセスできる必要があることを知って、ページの使用期間中そこに保存するより良い方法はありますか?
4

0 に答える 0