5

私は、「顧客」が登録し、実行する特定の検索に対して使用ごとの料金を支払うことを可能にする新しいサービスを設計しています。このサービスは、RESTFul および SOAP インターフェースを使用して公開されます。通常、Web サービスは顧客の Web サイトと統合されてから「パブリック」に公開され、誰でも顧客の Web サイトを使用して、私の Web サービス機能 (顧客は料金を支払いますが、モデレートを完全に制御できます) を利用できます。要求が多すぎないようにします)。

統合を最適化してできるだけシンプルにするサービスを設計したいと考えています。Web サービス API は変更されるため、内部プロキシを作成して Web サービスを一般に公開することは、場合によっては顧客にとって非常に批判的なものになります。したがって、私が見ている問題は、認証、セキュリティ、および統合のバランスをとる Web サービスを作成することです。

理想

  1. OAuth を使用しない
  2. 私が既に持っているのと同じ Web サービス API を再公開する内部プロキシの作成を顧客に強制することは避けてください。
  3. 安全であること (トークンのユーザー名/何でも渡し、ssl)
  4. お客様の Web サイトに JavaScript ライブラリを埋め込む - これは、統合手順をさらに簡単にするクライアント Javascript ライブラリになります。
  5. Javascript ライブラリは、一般ユーザーが資格情報を簡単に取得して自分で再利用できないように、十分に安全である必要があります。
  6. 可能であれば、ハックしすぎないようにしてください。そうすれば、Firefox 87 が出てきて (できるだけ多くの分でリリースされる予定です)、それを混乱させることにした場合でも、Web サービスを再構築する必要はありません。

これを機能させるには、ある種の 3 方向認証プロセスが必要なようです。つまり、特定のクライアント (パブリック)、Web サービス (顧客)、および Web サービスを認証します。

似たようなものを実装した人はいますか?このような状況にどのように取り組みましたか?

また、実行できることとクロスドメイン セキュリティに違反することの間にはバランスがあることも理解しています。そのため、JSONP データを返す別の GET 専用インターフェイスによって Web サービス全体が公開される可能性があります。

/**追記**/

それ以来、私が探していることを実行する Web サービスを発見しました。ただし、実装の詳細を完全に理解しているとは言えません。ですから、誰かが私の考えを詳しく説明してくれるかもしれません。

私が発見した Web サービスは、サービス側で Javascript をホストしているようです。次に、顧客は JavaScript タグに Javascript を含めることで Web サイトをサービス側に統合しますが、そのためのキーを提供します。

どういうわけか、スクリプトを自分の Web サイトに追加しても機能しません。したがって、どこかでトークンを特定の顧客ドメインに登録する必要があり、「client-lib.js」は実際にはサーブレットまたは同様のものであり、入ってくる「パブリック」からのユーザーが実際に発信されたことを何らかの方法で検出できます「顧客」ドメイン。

私の考えは正しいですか？この方法で使用できる http ヘッダーはありますか? それは安全ですか？

乾杯

4

2 に答える 2

3

まず第一に、昨日回答した別の SO 質問へのリンクを提供させてください。これは、同様の質問セットに対してかなり広範な回答を提供するためです。

検索元のサイトの所有者に料金を請求するつもりであり、検索元の個々のユーザーが誰であるかはあまり気にしないと想定しています。それが正しくない場合は、明確にしてください。それに応じて回答を更新します。

明らかに、どのような場合でも、まず最初に行う必要があるのは、各要求でこれがどのクライアントであるかを確認することです。そして、あなたが言ったように、クロスサイト攻撃やユーザーのキーを盗む人々から身を守ることも必要です.

考えられるのは、次のようなものです。

  1. あなたの側で秘密鍵を作成します - あなたのサービスだけが知っています。
  2. 新しい消費者サイトがあなたのアカウントを作成するときはいつでも、あなたと彼らだけが知っている新しい共有キーを作成してください. 秘密鍵をパスワードとして使用してこの鍵を作成し、この特定のユーザーを識別できるようにする何らかの識別子を暗号化することをお勧めします。
  3. 登録プロセスの一環として、コンシューマー サイトに、スクリプトを使用する URI を通知させます。

これで、追跡と認証の両方を行う方法がかなり簡単になります。

FF が更新されるたびに更新する必要のない JS ライブラリを提供すると述べました。jQuery、または同様にサポートされているクロスブラウザー JS 基礎ライブラリーを使用してそのライブラリーを構築し、それで AJAX をラップすることをお勧めします。

ただし、クライアント サイトがスクリプトを要求した場合は、次のようなものを提供してもらいます。

http://www.yourdomain.com/scripts/library.js?key={shared key}

お客様側で、このリクエストを受け取ったら、次の点を確認してください。

  1. 秘密鍵を使用して共有鍵を復号化するとき、意味不明になるべきではありません。もしそうなら、それは彼らの鍵が何らかの方法で変更されているためであり、有効ではありません. これにより、エラーが発生するはずです。401: Unauthorized
  2. キーを復号化し、これがどのクライアント サイトであるかがわかったら(それがキーに含まれているため)、クライアントが登録したのと同じ URI からリクエストが送信されていることを確認します。これにより、誰かがキーを盗んで別の Web サイトに挿入するのを防ぐことができます。
  3. 上記が一致する限り、ファイルをダウンロードしてもらいます。

これで、JS ファイルを提供するときに、キーをそのファイルに挿入する方法で提供できるため、共有キーにアクセスできます。各 AJAX リクエストにそのキーを含めて、このリクエストがどのクライアントからのものかを識別できるようにします。RESTful 環境では、実際にはセッションがあってはならないため、投稿ごとにこのレベルの認証が必要です。クッキーとして含めることをお勧めします。

サーバー側では、後続のリクエストごとにキーのチェックを繰り返すだけで、多くのオーバーヘッドなしでかなり厳しいセキュリティを構築できます。

とはいえ、大量のトラフィックが予想される場合は、これに戻って、将来的にさらに深いセキュリティ プロセスを調査することをお勧めします。独自のセキュリティ マトリックスを展開すると、予期しない穴が残る可能性があるからです。しかし、それは良いスタートであり、あなたを軌道に乗せるでしょう.

必要に応じて、お気軽に質問してください。それに応じて回答を更新します。

于 2012-11-02T16:14:53.347 に答える
1

それを行う最善の方法は次のようなものです（サーバーでホストされているjavascriptを使用し、インクルード部分をできるだけシンプルにしたい場合）：

*ユーザーがあなたのウェブサイトに登録すると、ドメインのトークンを受け取ります

*ユーザーは、サーバーを指す js ファイルを含めることができます。js ファイルは次のようになります。

<script type="text/javascript" src="http://your.server.com/js.php?token=###&widget=xxx"></script>

また

<script type="text/javascript" src="http://your.server.com/js.js?token=###&widget=xxx"></script>

.htaccess を使用してリダイレクトする場合

*phpファイルで、トークンがリクエストドメインと一致するかどうかを確認し、一致する場合はjs libをエコーアウトし、一致しない場合はエラーまたは何かをスローします

* js では、サービスへの ajax 呼び出しと、HTML を操作するためのものを作成する必要があります (ウィジェット ホルダーの作成、データの表示など)。

*また、すべての呼び出しにトークンが必要です。同じロジックを使用して、token==サーバー アドレスかどうかを確認できます。

編集：

REFERER はクライアントのブラウザによって HTTP プロトコルの一部として送信されるため、実際には信頼できません。

リクエストがあなたのサイトから来ているかどうかを確認したい場合、それはできませんが、ユーザーがあなたのサイトにアクセスしたこと、および/または認証されたことを確認することはできます。Cookie は AJAX リクエストで送信されるため、信頼できます。ただし、これは oAuth のようなものを使用する必要があることを意味します

この方法を使用する場合でも、リファラーをチェックして CSRF en.wikipedia.org/wiki/Cross-site_request_forgery を防ぐ必要があります。

理想的には、CSRF 攻撃を防ぐために、セッションごと、ユーザーごと (パラノイアの場合はリクエストごと) に一意のトークンを使用する必要があります。リファラーのチェックは、難読化による単なるセキュリティであり、実際の解決策ではありません。

于 2012-09-19T17:47:34.083 に答える