6

AJAX 経由でリクエストを行う Web アプリを作成していて、それらの呼び出しをロックダウンしたいと考えています。少し調査した後、何らかの形式のランダム トークン (文字列) を使用して、要求と共に返すことを検討しています (GUID?)。私のアルゴリズムの重要な部分は次のとおりです。

  1. トークンを JavaScript 変数 (サーバー側で生成) に割り当てます。
  2. また、そのトークンを DB に保存し、有効な期間 (つまり 10 分) を与えます。
  3. トークンがまだ使用されておらず、有効な時間枠内にある場合は、呼び出しを許可します。
  4. 有効な場合は要求された情報を返します。そうでない場合は、要求をログに記録して無視します。

セキュリティに目を向けると、これは理にかなっていますか? トークンの場合、GUID は機能しますか?それは別のものにする必要がありますか? リクエストで変数を暗号化する良い方法はありますか?

編集：

これらの AJAX リクエストが真に「安全」ではないことは理解していますが、私が作成しようとしているサービスを他のユーザーが使用できないようにするという意味で、基本的なセキュリティを追加したいと考えています。このランダムなトークンは、嫌がらせ電話に対する基本的な最前線の防御になります。要求されるデータ (およびそのようなデータを生成するために送信されるデータ) が繰り返される可能性はほとんどありません。

GUID の使い方が間違っているのかもしれません... ランダムに生成された文字列 (トークン) はどうですか?

4

3 に答える 3

5

クライアント ブラウザに送信したコードを信頼するためにこれを行っている場合は、方向を変えてください。ブラウザーに送信した js からの呼び出しを含むユーザー入力を信頼したくはありません。サーバー上のロジックは、そこから何の問題も起こらないようにする必要があります。そうは言っても、asp.net は signed フィールドを使用します。絶対に必要な場合は、その方法を使用することをお勧めします。

少し拡張: Asp.net は、(構成に応じて) html 隠しフィールドとして送信されるビューステートの改ざん防止を行います。参照としてより良いリンクがあると確信していますが、少なくともこれには言及されています: http://msdn.microsoft.com/en-us/library/ms998288.aspx

検証。これは、ViewState およびフォーム認証チケットの改ざんを防止するために HMAC を生成するために使用されるハッシュ アルゴリズムを指定します。この属性は、ViewState 暗号化に使用される暗号化アルゴリズムを指定するためにも使用されます。この属性は、次のオプションをサポートしています。

  • SHA1–SHA1 は、ViewState の改ざん防止と、構成されている場合はフォーム認証チケットの改ざんに使用されます。検証属性に SHA1 が選択されている場合、使用されるアルゴリズムは HMACSHA1 です。

そのアルゴリズムの .net クラスへのリンクhttp://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx。

更新 2: 改ざん防止のために、データに署名する (暗号化しない)。一般的に暗号化を使用する場合は、カスタム実装またはアルゴリズムの使用を避ける必要があることに注意してください。手順に関しては、次のことに固執します。

  • トークンを JavaScript 変数 (サーバー側で生成) に割り当てます。リクエストを識別するための情報と、リクエストが発行された正確な日時を含めます。署名は、サーバー側アプリケーションがデータを発行したことを検証します。
  • 必要に応じて、二重提出を特定します。

そうは言っても、asp.net がデフォルトでビューステートを検証する理由は、開発者が、アプリケーションによってのみ処理されるべきではないときに、そこに入ってくる情報に依存しているためです。おそらくシナリオにも同じことが当てはまりますが、このメカニズムに依存しないでください。誰かが何かを実行できるかどうかを評価したい場合は、認証と承認を使用します。ajax 呼び出しが有効なオプションのみを送信していることを知りたい場合は、それらを検証します。アクションを適切に承認できる粒度レベルよりも細かいレベルで API を公開しないでください。このメカニズムは、何かが滑った場合の特別な手段であり、実際の保護ではありません。

Ps。上記の HMACSHA1 では、固定キーでインスタンス化します

于 2009-03-17T02:45:13.613 に答える
1

それは、セキュリティによって何を達成しようとしているかに大きく依存します。HTTP エンドポイントの不正使用を防止する場合、ユーザーは呼び出しに使用される HTML と JavaScript に完全にアクセスできるため、できることはほとんどありません。

誰かが AJAX リクエストのデータを傍受できないようにする場合は、SSL を使用します。

あなたが提案している方法で使用されるGUIDは、実際にはセッションID Cookieを再発明するだけです。

于 2009-03-17T02:38:11.633 に答える
1

「保護」というのは、あいまいな用語です。正確に何を達成しようとしていますか？GUID を使用することは、同じ要求の重複送信を防ぐのに最適な方法ですが、それだけです。

クライアントとサーバーの間でやり取りされる情報が本当に機密性の高いものである場合は、HTTPS 経由で行う必要があります。実際の通信を保護することに関する限り、それが本当に唯一の答えです。

編集: GUID が「正しい」方法であるかどうかに関する質問に答えるには、提案していることを行う正しい方法はありません。GUID であろうと独自に作成したものであろうと、任意のトークンを使用しても、同じ要求の重複送信を防ぐ以外には何の効果もありません。それでおしまい。

于 2009-03-17T02:38:06.410 に答える