web-dev-qa-db-ja.com

GoogleマップはどのようにAPIキーを保護しますか?似たようなものを作るには?

現在、Googleでは、地図の提供元のドメインに固有のAPIキーを作成する必要があります。 Googleはこれをどのように実施しますか?私も同じことをしたいです。

サービス用のAPIを公開していますが、クライアントがサーバーからだけでなく、JavaScriptを介してAPIへの呼び出しを埋め込むことを許可したいと考えています。ランダムトークンだけでセキュリティを確保できましたが、もちろん、クライアントマシン上のコードを見ている人なら誰でも簡単にこれを偽装できます。

私は常にこの概念は不可能であると理解していましたが、どういうわけかグーグルはそれを実施するのに良い仕事をしています。

編集-結局のところ、Googleは本当に素晴らしいことを何もしていないようです。それらのAPIは、おそらく追跡のためだけのものであり、キーを持つ人が自分のAPIを使用することを保証するものではありません。

73
Vyrotek

私は彼らがREFERER URLを使用して通話の発信元を判断していることを確信しています。ドメインがキーに割り当てられたものと一致しない場合、それは無効なリクエストです。

実用的な例として、PHPを使用すると、$_SERVER['HTTP_REFERER']を使用してドメインをチェックでき、リファラーをチェックできます。ドメインが一致する場合、有効な応答を返します。 401 Unauthorizedまたはその他の応答を返します。

29
Trevor

APIキー自体は、おそらく、キーが関連付けられているドメインの一方向ハッシュであり、Google APIサーバーのみが知っている秘密です。他のいくつかの有名な(もちろんGoogleにとって)情報が含まれている場合があります。そのドメインからリクエストを行うと、APIサーバーはリクエストの送信元のドメインを取得し、同じ一方向のハッシュ計算を行い、2つの値を比較します。

Ajax呼び出しの場合、ほとんどの場合、リファラーを使用してドキュメントホストのドメインを取得します。リファラーはスプーフィングされる可能性がありますが、最終的にはAPIを使用するために、ドキュメント内で実行するGoogle JavaScriptを取得する必要があります。この時点で、このjavascriptは、Ajax API呼び出しを呼び出したドキュメントが実際にターゲットサーバーから発信されたことを確認できます。もちろん、あなた自身のDOM実装を持っているか、スクリプトをその場で修正していれば、これもなりすましです。ただし、このスプーフィングはクライアント側で発生する必要があり、Google APIを使用したいWebサイトがクライアントソフトウェアをスプーフィングできる可能性は非常に小さいです。

APIは基本的に無料であるため、APIへの匿名アクセスも提供できます。どうやらGoogleの意図は、Googleへの不正アクセスを保護することではなく、そのデータ使用量について可能な限り多くのデータを収集し、その使用量をターゲットドメインに関して収集した他のデータに関連付けることができるようにすることです。そのため、APIキーの検証が上記で説明したものよりはるかに複雑になるとは思わないでしょう。より高度なアプローチのROIは低すぎます。

そしてもちろん、APIを介したXSS攻撃の可能性も懸念されています。しかし、彼らのAPIキーが持っている反XSSコードに過度に結び付けられているとは思わない。

65
Franci Penov

私はすべての点に同意します Franci Penovがリストしたこと 他の誰かのAPIキーの使用について少し詳しく説明したいと思います。 key1example.comを登録するとします。

  1. 最初の試行– anothersite.com<script src="http://www.google.com/jsapi?key=key1">がある場合、Googleはそのリファラー(ハッシュスキームを参照)を確認できますが、この場合は不一致があります。多くの人がリファラーがなりすまされる可能性があると述べているので、悪の攻撃者はどのようにこれを克服しますか?これは実際にはここでは当てはまりません。リクエストを行うと任意のヘッダーを送信できますが、悪意のあるハッカーはanothersite.comのユーザーに対してリファラーを偽装しますか?これは一般的に簡単ではありません。フラッシュの古いバージョンはIE 6で、クロスドメインリクエストを行うときに攻撃者が任意のヘッダーを設定できましたが、一般的にこれはスクリプトsrcに対して実行できません。含まれているJavascriptがdocument.locationを検証してこれを防ぐかどうかはわかりません(おそらくそうではありません)。

  2. 2回目の試み–悪意のある攻撃者がmysite.comのページソースからAPIキーのGoogle Javascriptをコピーし、anothersite.comに変更されたjavascriptを埋め込みます。これで、Googleは何もチェックできなくなります(リモートIPはユーザーのコンピューターになり、あなたやGoogleができることはあまりありません)。

したがって、何らかの理由でAPIキーを秘密にしたい場合(1つの理由は、悪意のある人がキーをブラックリストに登録/ブロックする可能性があります)、サーバーを介してクライアントおよびプロキシリクエストにキーを埋め込まないでください(アプリケーションコードにはキー)。

3
mar

私のコメントが言うように:

REFERERはなりすまし可能なため、Googleがそれを検証手段として使用する可能性はほとんどありません。 このウィキペディアのエントリを参照してください。

私の推測では、GoogleはおそらくDNSルックアップとともに発信者のIPアドレスを使用していると思われます。 DNSは偽装されません。なぜなら、あなたのDNSエントリはウェブサイトがあなたに到達するためにも正しいものでなければならないからです。

しかし、それでも問題があります。サーバーがラウンドロビンIPアドレスDNS設定を使用している場合、DNSルックアップを行うときにGoogleが別のIPアドレスにリダイレクトされるためです。

FAQから

http://www.mygooglemapssite.com/ のキーは、このアドレスを使用してサイトにアクセスする場合にのみ受け入れられることに注意してください。 IPアドレス(例: http://10.1.2.3/ )またはエイリアスされたホスト名でサイトにアクセスする場合、受け入れられません。 DNS CNAMEレコードを使用してwww.mygooglemapssite.comにアクセスします。

私の推測では、ページをリクエストするときに送信されるHostヘッダーを使用している可能性があります。これは通常、GoogleがAPIスクリプトをページに直接含めるように要求するように動作します。次に、そのスクリプトは現在のページのヘッダーにアクセスし、それを使用して確認できます。

私の推測は、IPアドレスまたはエイリアスに対して機能しないという事実に裏付けられています。つまり、DNSチェックを行っていないということです。

このメソッドは、ページにアクセスするための正しいヘッダーである必要があるため、なりすましはできません。ただし、これはドメインへのエイリアスが機能しないことを意味します。

ただし、このサーバー側をチェックできないため、コードにアクセスするにはJavascriptライブラリを提供する必要があることも意味します。

3
Tyler Carter