13

サーバーとの通信に多くの AJAX を使用する Web ページに取り組んでいます。サーバーには、Web クライアントによって呼び出されるさまざまな操作を公開する広範な REST/JSON API があります。

この Web サイトは、匿名ユーザーと認証済みユーザーの両方によって使用されます。ご想像のとおり、認証されたユーザーによって発行された Web サービスの呼び出しには認証が必要であるため、権限のないユーザーやアプリケーションから保護されます。

ただし、Web サイトには認証を必要としない多くの機能があり、それらのいくつかは匿名 Web サービスを利用しています。部外者がこの Web サービスを呼び出すのを防ぐために私が使用している唯一の方法は、CSRF トークンを使用することです。CSRF トークンは、この点ではあまり役に立ちません...しばらく時間があれば、CSRF トークンを使用している場合でも、Web サービスを使用する方法を理解できます。

もちろん、CAPTCHA を使用して、アプリケーションやボットが Web サービスを自律的に使用するのを防ぐことができます。しかし、どんな人間でもそれを使うことができます。

一方、クライアントとサーバーの間で秘密鍵を共有しても意味がありません。これは、部外者が Web ページのソース コードからそれを読み取ることができるためです。

これらの Web サービスをサード パーティ アプリケーションからできるだけ呼び出しにくくしたいと考えています。CSRF トークンを使用する以外に何をしますか? 少しばかげているように聞こえますが、ちょっとばかげているのかもしれません。時間を無駄にしているだけです。

注: このアプリケーションはクライアントとして「実行可能ファイル」ではなくブラウザを使用するため、この質問は議論とは関係ありません。サーバーとクライアントの間でシークレットを使用できません (少なくとも私の知る限り)

4

5 に答える 5

2

私はいくつかのステップを踏みます。

  • サイトで https を強制します。着信 http リクエストを https リクエストに自動的にリダイレクトします (これには RequireHttps 属性が便利です)。
  • 各ページは、ページに使用するために、1 回限りのトークンをクライアントに送信する必要があります (安全に、したがって https)。クライアントで実行されているスクリプトは、これをページ メモリに保持できます。戻ってくるリクエストは、ナンスソルトとともに、ハッシュ化およびソルト化されたレスポンスを送信します。サーバーは、保存されたトークン + ソルトとハッシュを使用して手順を繰り返し、リクエストを確認できます。(上記の explunit の回答によく似ています) (クライアントからの安全な要求は、ユーザー アカウントから認証されているのではなく、ページ全体と共に送信されたトークンであることに注意してください。)
  • ワンタイムの定義は、セキュリティと利便性の好みに応じて、セッションまたはページの読み込みのいずれかになります。攻撃者を苛立たせるために、トークンは長く、かなり早く失効する必要があります。

SSL + Hash(token + nonce) で十分です。

于 2013-02-11T08:03:39.600 に答える
2

これは面白い。以下はクレイジーな提案です。あなたの質問も同様にクレイジーであることを忘れないでください。

Web サイトをブラウザーで開くと、長いポーリング接続が生成されるはずです (Comet プログラミング)。これにより、ブラウザとサーバーの間に一意のセッションが作成されます。あなたの JS が ajax 呼び出しを行っているとき、長いポーリング スレッドを介してトークン (毎回一意のトークン) をサーバーに送信します。AJAX にも同じトークンを送信させます。サーバーで、AJAX トークンを取得し、長いポーリング セッションで同様のトークンがあるかどうかを確認します。はいの場合は、要求を実行します。どんなコーダーでもこれを破ることができます。しかし、それは簡単ではありません。フリーボーダーは、これらのコメット コードの 2 番目の部分にさえ気付かない可能性があります。検出や理解が容易ではない方法でコメット コードを実装できます。彼らがあなたのサービスを呼び出すときは、「サービスを利用できません」というメッセージを送信します。彼らは混乱するでしょう。コメットコードもhttpsにしてください。

また、長いポーリング スレッドが開いている時間を確認することもできます。セッションを開いた直後に ajax 呼び出しが発生した場合、それはサード パーティの呼び出しであると見なすことができます。それはあなたのウェブサイトの流れに依存します。ページ読み込みの 1 秒後に ur Ajax 呼び出しが発生した場合は、サーバー側でそのパターンを確認できます。

パブリック API のコーディングを行う人は、1 つか 2 つの秘密のチェックを行いますが、それは彼らが知らないことであり、たとえ知っていたとしても、彼らがしなければならないすべての余分なコーディングによって落胆するかもしれません。

于 2013-02-11T18:12:45.087 に答える
1

ユーザーにバイナリを配布する必要がないため、リンクされた質問で説明されている問題よりも簡単な問題が発生する可能性があります。アプリがオープン ソースであっても、HMAC/署名キー (その回答の「署名の要求」の部分にある) は、環境/構成設定によって制御できます。

要約する：

  1. 秘密鍵は、実際にはクライアントとサーバーの間で送信されません。むしろ、リクエストに署名するために使用されます
  2. 同じ API データに対する 2 つのリクエストが同一にならないように、リクエストに一意/ランダムな要素 (おそらく CSRF キーで十分) が含まれていることを確認してください。
  3. 秘密鍵でリクエストに署名し、署名をリクエストに追加します。PHP の質問にリンクしましたが、使用している言語が明確ではありません。.Net では、 HMACSHA256などのHMACクラスを使用します。
  4. API サーバー側では、同じ HMAC オブジェクトを使用して、リクエストが同じ秘密鍵で署名されていることを確認します。
于 2012-10-12T15:21:48.453 に答える
1

これは、RSA の概念に基づいた単なるアイデアであり、システムに不正検出を配置することもできます。許可されたユーザーによるリスクは最小限ですが、Web サービスに対して匿名の呼び出しを試みることもできます。

UN-Authorized ユーザーの場合: Web サービス呼び出しごとに、RSA を使用してトークンを生成します。このトークンは、しばらくすると変更されます (30 分と設定できます)。このようにして、コードの予測が最小限に抑えられます。今までRSA衝突について聞いたことがありません。ブラウザ セッションのために、このトークンをユーザーに送り返します。セキュリティを強化するために、セッション ID を RSA トークンに添付することをお勧めします。セッション ID は一意であるため、新しい匿名呼び出しには新しいセッション ID が必要です。

呼び出しは、監査メカニズムを使用して追跡できます。また、Web サービスごとに異なる RSA セットアップが存在する可能性があります。不正検出のアルゴリズムがどのように機能するかは、それ自体が課題です。

許可されたユーザーの場合: すべてのユーザーは、ヘッダー ブロックを使用して IP アドレスで追跡する必要があります。RSA トークンの原則を適用できます。

解決策は非常に曖昧ですが、検討する価値があります。

于 2013-02-07T21:02:26.270 に答える
1

会話を追跡するためにカウンターを使用できるかもしれません。会話の次の繰り返しを予測できるのは、サーバーとクライアントだけです。このようにして、サードパーティのアプリケーションが誰かになりすますのを防ぐことができると思います（ただし、アイデアです）。

最初は、ある反復で話し始めます (i=0たとえば、 )。

  • クライアントが何かを要求するたびに、サーバー側とクライアントの両方でカウンターが数値ずつ増分されます ( i=i+some_number)。

  • そして、数分間通信がなかった後、両者はカウンターをリセットする必要があることを認識しています ( i=0)。

于 2013-02-06T22:29:11.363 に答える