16

スクリプトインクルードを使用したGoogleマップのAPIの使用方法は気に入っていますが、心配しています。

私のAPIは「セミプライベート」です。つまり、インターネット経由でアクセスできますが、データの安全な送信とある種の認証が可能になるはずです。データはネットワーク上で非公開のままにする必要があり、ある消費者が別の消費者のデータを取得できないようにする必要があります。

SSLとある種の認証を使用してデータを安全に保ちながら、サーバー側のプロキシを必要としないプレーンなHTMLページから「水平方向に」アクセスするにはどうすればよいですか。キーを管理する必要がありますか？キーは傍受されることなくサーバーにどのように投稿されますか？OpenId（または他のサードパーティ認証）を使用してAPIユーザーを認証できますか、それとも独自の認証メカニズムを作成する必要がありますか？私はグーグルのいたるところにいて、APIを安全に設計してデプロイするための良いガイドを見つけることができません。

現在、RESTとAJAXを使用してそれらを使用していますが、クロスドメイン呼び出しは不可能です。どんな助けや正しい方向へのポインタも大歓迎です。

4

5 に答える 5

10

おそらく、公開鍵暗号化されたクエリ文字列に鍵を含むSSLURLで動的に生成されたスクリプトタグを使用します。サーバーは秘密鍵を使用してクエリ文字列パラメーターを復号化し、関連情報を含むスクリプトを返します（または、鍵が無効な場合はそうではありませんでした）。またはそれらの線に沿った何か。しかし、私は実際にそれをする必要がなかったことを認めます。

アマゾンのS3サービスのような先行技術も探したいです。

それで：

  1. ユーザーが秘密を提供する
  2. クライアント側のコードは公開鍵を使用して秘密を暗号化します
  3. JavaScriptはscript、URLを含むタグを追加します
  4. サーバーはスクリプト要求を処理し、シークレットを復号化してチェックし、関連する応答を送り返します。

サーバーへの要求が中間者攻撃を介して再利用される可能性があるため、2サイクルが必要になる場合があります。それは次のようになります：

  1. JavaScriptはscript、一意のキーを要求するタグを追加します（おそらく、ソースIPやランダムな追加キーなどの交絡情報が含まれます）
  2. サーバーは、そのIPに関連付けられたワンタイムキーで応答します
  3. ユーザーが秘密を提供する
  4. クライアント側のコードは、公開鍵を使用して秘密を暗号化します。これには、＃1の一意の鍵も含まれます。
  5. JavaScriptはscript、URLを含むタグを追加します
  6. サーバーはスクリプト要求を処理し、シークレットを復号化してチェックし、関連する応答を送り返します。
  7. 応答は、＃1に含まれているランダムキーを使用して（ある程度）暗号化できます。

私が実際に行ったことはありません。（または私がいますか？BWAa-ha-ha-ha ...） FWIW。

于 2010-10-30T22:36:22.410 に答える
0

OAuthは、ユーザーにサードパーティアプリケーションにログインさせ、xhrリクエストを行うときにリクエストトークンを使用して、アプリケーションがサードパーティに代わってサードパーティにアクセスできるようにすることで、この状況を支援する場合があります。http://oauth.net/documentation/getting-started/

========

サーバー側プロキシを使用する理由は、Webブラウザに組み込まれている同一生成元ポリシーに要約されます。http：//en.wikipedia.org/wiki/Same_origin_policy

基本的に、ブラウザはページの送信元のアドレスに対してのみリクエストを行うことを許可します（たとえば、facebook.comはfacebook.com URIに対してのみリクエストを行うことができます）。サーバー側プロキシは、現在のオリジン外のサーバーにリクエストを送信することでこの問題を解決します。サーバー側プロキシも、このようなリクエストを行うためのベストプラクティスです。

于 2010-11-07T19:17:44.550 に答える
0

オープンソースのjavascriptForgeプロジェクトをチェックしてください。これは、安全なクロスドメインxhrリクエストを可能にするjavascriptTLS実装を提供します。それはあなたに役立つかもしれません：

http://digitalbazaar.com/2010/07/20/javascript-tls-1/

http://digitalbazaar.com/2010/07/20/javascript-tls-2/

https://github.com/digitalbazaar/forge

1つの潜在的な解決策：

  1. サイトを実行するためにApacheサーバーをセットアップします。
  2. サイトのSSL証明書を取得します。
  3. Forgeに付属のapachemodをインストールして、他のサイトが自分のサイトにアクセスできるようにするクロスドメインポリシーを設定します。
  4. サイトでのHostForgeのTLS実装と、PEM形式のサイトの証明書。
  5. 他のサイトに、自分のサイトのjavascriptを含め、それを使用して自分のサイトに安全な呼び出しを行い、やりたいことを何でもするように伝えます。
于 2010-11-08T16:48:56.543 に答える
0
  1. （サードパーティ）ページは、OAUTHまたは同様のものを使用して、ユーザーを認証し、サーバーからトークンを取得します。
  2. ページはSSLを介してサーバーからIFRAMEをロードし、認証のためにトークンを渡します。
  3. IFRAMEはSSLを介してサーバーと安全に通信できます
  4. 作成した制限付きのRPCまたはソケットのようなAPIを使用して、easyXDMまたは同様のものを使用してIFRAMEとサードパーティのページの間で通信します。

または、サードパーティを本当に信頼していない場合は、iframe内で認証を行い（oauthは必要ありません。プレーンなhtmlフォームを使用してください）、easyXDMを使用して外部ページがユーザーについて知る必要があることをすべて伝えます。

于 2010-11-11T11:35:40.260 に答える
0

質問が正確に何であるかはよくわかりませんが、[http://regular.com]でデータを処理/表示するために、[https://secure.com]に対してjsonpのような呼び出しを行おうとしていると思います。 ]？

2つのサーバーは相互に通信できますか？このようなものはどうですか：

  1. ユーザーは[https://secure.com]にログインします

  2. 認証時に、secure.comはトークンを生成し（syntokenと呼びます）、それをregular.com（サーバー間）に直接渡します。これは、session_id、任意のメッセージ、およびotp暗号（syncipherと呼びます）のようになります。 。

  3. Broswerはsession_idcookieを受信し、Secure.comはブラウザをhttp://regular.com/setcookieandredirect?session_id=blabla&otpencryptedsynmessage=blablaにリダイレクトします。

  4. Regular.comは、session_idをキーとして使用してotp暗号を検索し、otpencryptedmessage「blabla」を復号化します。

  5. 復号化されたメッセージがシントークンの元のメッセージと一致する場合、ユーザーが[regular.com]にログインし、regular.comが別のトークン（acktoken、lolzと呼びます）を生成し、それを[secure.com]に直接渡すことを確認できます。 session_id、任意のackメッセージ、および別のotp暗号（ackcipherと呼びます）。

  6. 次に、Regular.comは、otpencryptedackmessageで構成されるCookieをブラウザに送信します（このCookieに「verified_session」という名前を付けましょう）。

  7. ページの読み込みを終了します。

そこから、jsonpのような呼び出しを行うことができます

https://secure.com/getscript.js?query=dataname&verifiedtoken=(verified_sessions_cookie_value）

ここで、secure.com / getscript.jsはverifiedtokenを取得し、[secure.com]から送信された元のCookie session_idに基づいてackcipherを検索し、otpencrypedackmessageを復号化します。復号化されたメッセージがackメッセージと一致する場合は、スクリプトファイルをレンダリングします。

3ウェイハンドシェイクのようなものです。秘密のソースは、秘密鍵を個別に渡すために、サーバーが互いに直接通信できる必要があるということです。両方のサーバーに同じsession_idを使用する必要はありません。私は、syn /ackotp暗号にアクセスする方法を見つけるための簡単な参照ポイントとしてそれを使用していました。暗号は完全に公開されていない必要があります。

于 2010-11-13T12:06:01.637 に答える