2

REST サービスがスムーズに作成され、json の結果が返されたとします。

また、ユーザーがサービスと通信するための API キーも実装しました。

その後、A社が私のサービスを使い始めたので、APIキーを渡しました。

次に、APIキーを公開しないように（ここでの用語はわかりません）HttpHandler forブリッジを作成しました（正しい方法かどうかもわかりません）。

たとえば、サービスの URL が次のようになっているとします。

www.myservice.com/service?apikey={key_comes_here}

会社Aは、以下のようにクライアント側からこのサービスを使用しています:

www.companyA.com/services/service1.ashx

その後、クライアント側で使用を開始します。

A社はここでAPIキーを保護しました。それはいいです。

しかし、ここで別の問題があります。他の誰かがまだwww.companyA.com/services/service1.ashxURL を取得して、私のサービスを使い始めることができます。

他の人がそうするのを防ぐ方法は何ですか？

記録として、REST サービスを作成するために WCF Web API を使用しています。

アップデート ：

A 社の HttpHandler (2 番目のリンク) は、ホスト ヘッダーのみを調べて、それが送信元かどうかを確認しますwww.companyA.com。しかし、簡単に偽造できると思います。

更新 2:

URL のトークンを実装する既知の方法はありますか。たとえば、www.companyA.com/services/service1.ashxHttpHandler がリクエストが正しいかどうかを確認するために、TOKEN を表すクエリ文字列パラメーターを運ぶとしましょう。

しかし、ここには考えるべきことがたくさんあると思います。

4

3 に答える 3

1

HTTP 基本認証またはカスタム スキームを使用して、常にクライアントに認証を要求することができます。クライアントがユーザーにログインを要求する場合、少なくとも一般のwww.companyA.com/services/service1.ashx人が URL を取得することを制限できます。

公式クライアントに正当にアクセスできる人による意図しない使用から URL を保護しようとすると、さらに困難になります。サービスパスワードを定期的に変更し、それに合わせてクライアントを更新してみてください。そうすれば、ブラウザ内のクライアントを更新すると新しいパスワードが取得されますが、カスタム コードを作成した人は時代遅れになります。もちろん、真に決心したユーザーは、パスワードが変更されたときにプログラムによってクライアント JS からパスワードを取得するコードを作成することもできますが、少なくとも偶然の侵害者から保護することはできます。

更新 2 で言及した URL トークンのアイデアに関しては、次のように機能する可能性があります。毎月、www.companyA.com/services/service1.ashxURL が機能するために新しいトークンが必要になると想像してみてくださいwww.companyA.com/services/service1.ashx?token=January。2 月になると、「1 月」は機能しなくなります。サーバーは当月のみを受け入れることを知る必要があり、クライアントはトークンを送信することを知る必要があります (クライアント Web ページがサーバーからブラウザに読み込まれるときに決定されます)。

(C# とどの JS フレームワークを使用するかわからないため、すべて疑似コードです)

サーバー側コード:

if (request.urlVars.token == Date.now.month) then
   render "This is the real data: [2,5,3,5,3]"
else
   render "401 Unauthorized"

クライアント コード (サービスによって提供される動的バージョン) www.companyA.com/client/myajaxcode.js.asp

var dataUrl = 'www.companyA.com/services/service1.ashx?token=' + <%= Date.now.month %>
// below is JS code that does ajax call using dataUrl
...

これで、現在の月のみをトークンとして受け入れるサービス コードと、ブラウザーで更新したときに最新のトークンを取得するクライアント コード (現在の月として動的に設定) ができました。このスキームは実際に予測可能であり、ハッキングされる可能性があるため、残りのステップはトークンをソルトハッシュして、それがどうなるか誰も推測できないようにすることです。 

if (request.urlVars.token == mySaltedHashMethod(Date.now.month)) then

と

var dataUrl = 'www.companyA.com/services/service1.ashx?token=' + <%= mySaltedHashMethod(Date.now.month) %>

これにより、次のような URL がwww.companyA.com/services/service1.ashx?token=gy4dc8dgf3f残り、毎月トークンが変更されます。

おそらく、月の代わりにエポック時間を使用して、毎月よりも早く期限切れにすることもできます。

誰かが何らかの暗号化されたクライアント コードでこれを解決したかどうかを知りたいです!

于 2011-10-21T13:41:29.110 に答える
1

あなたが説明しているものは、一般に「プロキシ」と呼ばれます.companyAの公開ページは誰でも利用でき、舞台裏でシステムに適切な呼び出しを行います. アプリケーションがセキュリティを回避するためにプロキシを使用することは珍しくありません。たとえば、同一生成元ポリシーは、JavaScript が Amazon などに対して Ajax 呼び出しを行うことができないことを意味します。これを回避できます。

これを防ぐための技術的な方法は本当に考えられません。サービスからデータを取得したら、そのデータを好きなように使用できます。もちろん、合法的な選択肢があります。プロキシが許可されていないことを利用規約にし、準拠していない場合は API キーを取得できます。しかし、TOS にまだそれを含めていない場合は、おそらく、サービスのサブスクリプションの更新などを待つ必要があります。

おそらく、サービスに対してサーバー側の HTTP リクエストを作成している場合、それらのリクエストはすべて同じ IP アドレスから送信されているため、そのアドレスをブロックできます。あなたはおそらく最初に彼らに伝えたいと思うでしょう。

于 2011-10-21T13:36:47.737 に答える
0

Company AI によって公開された 2 番目のリンクでは、多くのことができるとは思えません。私が理解しているように、着信要求が会社 A からのものであるかどうかを確認することしかできません。

しかし、www.companyA.com/.. に対して発行された各リクエストは、A 社からの元のリクエストと区別できません。

于 2011-10-21T13:35:30.833 に答える