0

社内の他の Web/モバイル サイト プロジェクトで使用される 2 つの Web API プロジェクトを構築します。

  • Web API は公開されています
  • SSLなし
  • jquery ajax呼び出しで使用可能
  • データ自体はプライベート/機密データではありません。

Web API 呼び出しは、フロント ページのトラフィックの多いサイトで使用されます [例: ホームページのドロップダウンリストに入力する]

したがって、Web API 呼び出しを会社のプロジェクトのみに制限する何らかのメカニズムが必要です。少なくとも、誰かが私のパブリック Web API を使用してサイトを作成したり、[リプレイなど] の攻撃を行ったりすることを禁止します。

ここに私が考えたいくつかの方法があります

  1. すべての Web API 呼び出しをイントラネット内でのみアクセスできるようにする [サーバー側のコードを介してのみ Web API にアクセスする]。そうなると、ajax を介してアクセスする利便性が失われます。
  2. すべてのリクエストでユーザー名パスワードを使用しますが、当社のサイトでは HTTPS を使用しません。だからそれは目的を破る
  3. Nonce を使用することを考えましたが、公開ページで Nonce の有効期限が切れるとどうなりますか? どういうわけかページを更新する必要がありますか? ページはユーザー認証されていないため、ユーザーに何かを依頼することはできません。
  4. OAuth を使用して認証します。非常に複雑に見え、リクエストごとに認証が必要であり、パフォーマンスに影響を与えるのではないかと心配しています [サイトのトラフィックが多いため]
  5. uniqueID を使用して、ドメインの送信元を確認してください。願わくば、大きなことが起こらないことを願っています

私は5で行こうと考えています。あなたの提案を教えてください。前もって感謝します。

EDIT 私たちのサイトは https ではなく、ReadOnly リクエストのみです。私の主な関心事はパフォーマンスです。Public WebAPI は、社内の多くの Web プロジェクトで呼び出されるため、複雑なセキュリティ手順によって速度が低下することは望ましくありません。

4

2 に答える 2

2

免責事項 - ご自身で調査を行ってください (おそらく、さらに 2、3 の回答をお待ちください)。私はセキュリティの専門家ではありません。

これをオープン API にする計画

正直なところ、ものを保護するのは非常に困難です。最善を尽くすことはできますが、実際には、JavaScriptを介して誰でもAPIにアクセスできるようにすることについて話しているため、完全に保護する可能性はあまりありません. この API を作成する際のすべての決定は、誰でもアクセスできるという考えに基づいている必要があります。実際の認証スキーム (カスタムのものではないなど) を実装しない限り、プライベート データを送信しないでください。

データがそれほど重要でない場合は、十分に保護されていなくても問題ありません。

これに取り組む次の人は、機能を実現する最も簡単な方法を見つけるかもしれません.多くのセキュリティの脆弱性は、元の計画を完全に理解していないときにシステムを更新することで発生します.

トークンベースの認証

API の使用が許可されている各サイトは、一意の ID (GUID) を元のサイト、クライアント IP、および有効期限と共にデータベースに挿入します。ページのライフサイクルによっては、これはおそらくかなり早く期限切れになる可能性がありますが、より多くの費用がかかります。

JavaScriptがAPIにアクセスすると、このトークンが渡され、APIはデータベース内のトークンとIPを単純にチェックし、有効期限が切れていないことを確認します。

ASP.NET のような暗号化された Cookie を潜在的に使用して、何らかの標準形式の認証を使用できればさらに良いでしょう。ただし、クロスドメインの場合、これが可能だとは思いません。

IP をチェックすることは、別のサイトがユーザーに API の使用を許可しようとする中間者攻撃を防ぐのに役立ちます。

API のレートを制限して、他のサイトが API を使用してユーザーに情報を提供するのを防ぐことができます。これは、トークンを発行する頻度と、各トークンが実行できるリクエストの数を制限するだけで実現できます。

CORS

http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

クロスドメイン ajax 呼び出しを使用している可能性があるため、おそらく CORS と呼ばれるものを調べる必要があります。これにより、互換性のあるブラウザがクロス ドメイン リクエストを作成できるようになります。これをサポートしていないブラウザでは、おそらく jsonp にフォールバックする必要があります。これは、クロスサイト スクリプティング攻撃をサポートするブラウザーでのクロスサイト スクリプティング攻撃の排除にも役立つはずです。私の知る限り、これはサーバー テクノロジではなく (http ヘッダーを除いて) ブラウザ テクノロジであるため、このルールで適切に動作しないクライアントを防ぐことはできませんが、ユーザーを保護するのに役立ちます。

CSRFに対する保護

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF )

データの更新を許可する場合は、クロスサイト リクエストの偽造防止メカニズムの使用を検討することを強くお勧めします。おそらく、MVC のようなトークンが提供され、(API から) Cookie に一意の値を指定し、API への投稿で値を返す必要があります。サーバーとクライアントの両方に実装するのは非常に簡単で、サーバーはこれを行うためにセッションに何かを保存する必要はありません。つまり、Cookie が生きている限り機能します。これにより、悪意のある第三者が他の誰かに API へのリクエストを実行させることが非常に困難になります。ajax の代わりにフォームを使用してポストバックを行っている場合は、トークンがポストバック値に追加されていることを確認する必要があります。これは認証方法ではなく、CSRF を防ぐためのものであることを忘れないでください。

これを認証トークンと組み合わせることができるかもしれませんが、Cookie の送信に依存しているため、これはおそらく不可能です。

DOS攻撃

また、大量の CPU 時間を使用する DOS 攻撃を阻止するために、API メソッドが高価でないことを確認してください。もちろん、誰かがあなたのサイトを本当に削除したいのであれば、おそらくまだ削除できるでしょう。あなたの仕事は、彼らの手段を制限することです.

于 2012-10-02T07:29:23.330 に答える
0

If you're still looking, what you need is a lightweight message authentication method that will verify the authenticity of the message. Using a hash key in a fairly lightweight but still secure algorithm like SHA-1 you can compute a hash value for every request that you'll always authenticate on the server side before honouring the request. Avoid MAC-ing with constant bits of data like server or hostname. Instead, Use a component of the data being sent so that if it's modified in transit, validation fails. See this answer for the step-by-step

Number 5 is an Okay solution, but I always strongly caution against solutions that depend on the goodness and mercy of the web client to your application/api. Most people out there just want to hurt your app and will forge anything, including the host/referer http header with minimum effort.

于 2012-10-09T04:22:39.583 に答える