12

JSON Web API を設計しており、使用状況を監視し、悪意のある/不正なクライアントをブロックするために、一意の ID でクライアントを区別したいと考えています。API は JavaScript ライブラリにカプセル化されておらず、Web アプリ専用ではありません。あらゆる種類のクライアント (デスクトップ、電話など) で使用できます。

問題は、Web アプリ (公式 Web サイト) も API 自体のクライアントであるため、その API キーを公開する必要があることです。その結果、一部のユーザーは、独自のキーを生成する代わりに、ページ上の JavaScript からキーを抽出して使用することができました。

より優れた/よりスマートな設計を選択して、この問題を何らかの形で軽減することは可能ですか? または、悪意を持って API を使用している誰かがこれを悪用できるという事実を受け入れなければなりませんか?

私はフロントエンド アプリ (EmberJS) とバックエンド サーバー (Go) を 100% コントロールしているので、代替案を提案することができます。

  • セッション/IP ごとのレート制限を使用して、その場合に備えて追加の保護レイヤーを追加しています
  • twitter.com ページはかつて、独自の API のクライアントでもありました。彼らはどのようにそれを解決しましたか?

注: 問題は、認証やセキュリティ自体に関するものではなく、認証に加えて (!) API キーの使用をサード パーティ ユーザーに要求する方法です!

4

3 に答える 3

6

Web クライアントと非 Web クライアントを区別する必要があります。Web 用のアクセス キーは、非 Web では使用できず、その逆も同様です。Web クライアントの場合、リファラー チェックなどを実行できます。また、アプリケーションのアクセス キーを動的に作成し、それらを毎日 (またはセッションごとに) 自動的に変更することもできます。また、難読化された JS によって計算される追加のキーなど、アプリのみに特別な検証を追加することもできます。

悪意のあるユーザーがブラウザーをエミュレートし、JS を実行し、それを操作して、悪いことをするのを防ぐことはできませんが、努力する価値がないと判断するほど迷惑をかけることはできます。パーミッションなどの本当に重要なことは、明らかにサーバー側でチェックする必要があるため、API を悪用してもそれほど問題にはなりません。IP ブロックなど、通常の Web アプリの悪用と同じように、サイトの API キーを使用して API の悪用を処理する必要があります。

非 Web クライアントの API キーは秘密にしておく必要があります。これは、クライアント開発者の手に委ねることができる難読化によってのみ、信頼性の低い方法で行うことができます。彼らの鍵が漏洩して悪用された場合、あなたがそれを取り消すと、彼らはそれを修正するよう動機づけられます.

OAuth 2.0を見てください。それらは、あなたにとって役立つ多くの機能を実装しています。使いたくない場合でも、インスピレーションを得ることができます。OpenStreetMap は、Flash ベースのエディタに OAuth (1 か 2 かは不明) を使用しています。ログインしたユーザーによって同じオリジンから呼び出される限り、OAuth パーミッションの付与は自動的に行われます。サードパーティ アプリの場合、ユーザーは手動で行う必要があります。あなたはそれをチェックしたいかもしれません。

于 2013-01-28T13:35:44.890 に答える
5

単一の API キーを使用するだけでは、API を安全にすることはできません。説明しているAPIキーは基本的に公開鍵であり、安全な識別/認証とそれを配信するメカニズムのために、ある種の秘密鍵が必要になります。

あなたは、Twitter がこの問題をどのように回避したかを尋ねました。彼らはOath 1.0aを使用しています。以下は、 Twitter 開発者 FAQの API キーにどのように関連付けられているかについての簡単な説明です。

API とのほとんどの統合では、API キーを使用して Twitter に対してアプリケーションを識別する必要があります。Twitter プラットフォームでは、「API キー」という用語は通常、OAuth コンシューマー キーと呼ばれるものを指します。この文字列は、API にリクエストを行うときにアプリケーションを識別します。OAuth 1.0a では、"API キー" は、このコンシューマ キーと "コンシューマ シークレット" の組み合わせを参照する場合があります。これは、Twitter へのリクエストを安全に "署名" するために使用される文字列です。Twitter へのほとんどのリクエストには、アプリケーション コンテキストに加えてユーザー コンテキストが必要です。ユーザー コンテキストは、「アクセス トークン」と呼ばれる別の種類のトークン/キーを使用して提示されます。詳細については、アクセス トークンの取得を参照してください。

Apigee.com では、API の設計に関する優れたリソースを多数見つけることができます。彼らは、認証/承認にOAuth 2.0を使用することを推奨しています。

ここでは、 HMAC 認証を使用して Web API を保護する方法について説明します。

API キーのみを使用する API を使用しなければならなかったときに、Web アプリケーションの回避策を使用しました。Web アプリケーションのクライアント側部分 (つまり、Web ブラウザーの JavaScript) から API に直接アクセスすることはありません。代わりに、API サーバー側にアクセスし、暗号化された API キーを安全な構成ファイルに保存します。オリジナルの API に Facade を提供し、独自のセキュリティ メソッドを使用して、アプリケーションの種類に依存する Facade API を保護します。

于 2013-01-29T16:04:25.187 に答える
-2

一般的な API ワークフロー:

  1. クライアントがリクエストを送信
  2. リクエストは認証および承認されています
  3. データが返送される

Web サイト - ログイン

  1. ユーザーは、ユーザー名とパスワードを入力してログインします
  2. シークレットが作成され、Cookie に保存されます

Web サイト - API アクセス

  1. クライアントがリクエストを送信
  2. リクエストは、Cookie のシークレットに基づいて認証および承認されます (Cookie はリクエストと共に送信されます)。
  3. データが返送される

非 WEB クライアント - API KEY (長いランダムな英数字の文字列) の取得

  1. オプション 1 - ユーザーがクライアントを Web サイトに登録し、API キーを取得してクライアントに保存します。
  2. オプション 2 - ユーザーがユーザー名とパスワードをクライアントに入力し、クライアントがユーザー名とパスワードを含む API キーを要求すると、キーが返されてクライアントに保存されます。ユーザー名とパスワードはクライアントに保存されません。

非WEBクライアント - API通信

  1. クライアントは API KEY でリクエストを送信します
  2. リクエストは API-KEY に基づいて認証および承認されます
  3. データが返送される

キーがオプション 2 で生成されると、クライアント (オペレーティング システム、ブラウザ) から生成されるため、いくつかの追加データを取得できます。この場合、API-KEY をチェックするときに、ユーザーが OS またはブラウザを変更した場合、ユーザーに強制的に新しいキーを生成させることができます。

重要な点は、API が 2 つの方法でリクエストを認証することです。Cookie のシークレットまたは API KEY を使用する。したがって、Web サイトで API-KEY を公開する必要はありません。

API-KEY を使用するクライアントの場合、セッションは関与しないことに注意してください。各リクエストは、API-KEY によってのみ認証されます。したがって、これらのクライアントは非 WEB アプリと見なされます。

于 2013-01-29T11:44:07.060 に答える