現在、Google では、マップが提供されるドメインに固有の API キーを作成する必要があります。Google はこれをどのように実施していますか? 私も同じことをしたいです。
サービスの API を公開していますが、クライアントがサーバーからだけでなく、javascript を介して API への呼び出しを埋め込めるようにしたいと考えています。ランダムなトークンだけでセキュリティを確保できましたが、もちろん、これはクライアント マシンのコードを見れば誰でも簡単になりすますことができます。
私は常にこの概念が不可能であることを理解していましたが、どういうわけか Google はそれを強制するのにうまくやっています。
編集 - 結局のところ、Google は本当に何も驚くべきことをしていないように思えます。彼らの API はおそらく追跡のためだけのものであり、キーを持っている人が API を使用することを実際に保証するものではありません。
API キー自体は、おそらくキーが関連付けられているドメインの一方向ハッシュであり、Google API サーバーだけが知っている秘密です。これには、(もちろん Google にとって) よく知られている他の情報が含まれている場合があります。そのドメインからリクエストを行うと、API サーバーはリクエストの送信元のドメインを取得し、同じ一方向ハッシュ計算を行い、2 つの値を比較します。
Ajax 呼び出しの場合、ほとんどの場合、リファラーを使用してドキュメント ホストのドメインを取得します。リファラーはスプーフィングされる可能性がありますが、最終的に API を使用するには、ドキュメント内で Google JavaScript を実行する必要があります。この時点で、この JavaScript は、Ajax API 呼び出しを呼び出したドキュメントが実際にターゲット サーバーから発信されたことを確認できます。独自の DOM 実装またはスクリプトのオンザフライ変更がある場合、これはもちろんスプーフィングも可能です。ただし、このスプーフィングはクライアント側で行う必要があり、Google API を使用したい Web サイトがクライアント ソフトウェアをスプーフィングできる可能性は非常に低いです。
API は基本的に無料であるため、API への匿名アクセスも提供できたはずです。どうやら Google の意図は、それへの不正アクセスを保護することではなく、そのデータの使用に関するできるだけ多くのデータを収集し、その使用をターゲット ドメインについて収集した他のデータと関連付けることができるようにすることです。そのため、API キーの検証が上記で説明したものよりもはるかに複雑になるとは思いません。より高度なアプローチの ROI は低すぎます。
もちろん、API を介した XSS 攻撃の可能性も懸念されます。しかし、彼らの API キーが、彼らが持っているアンチ XSS コードに結び付けられすぎているとは思いません。
REFERER URL を使用して、電話の発信元を特定していることは間違いありません。ドメインがキーに割り当てられたものと一致しない場合、それは無効な要求です。
実用的な例として、PHP を使用$_SERVER['HTTP_REFERER']してリファラーを確認するためにドメインを確認できます。ドメインが一致する場合は、有効な応答を返します。そうでない場合は、401 Unauthorized またはその他の応答を返すことができます。
私のコメントが言うように：
REFERER はスプーフィング可能であるため、Google が確認の手段として使用する可能性は低いでしょう。このウィキペディアのエントリを参照してください。
私の推測では、Google はおそらく発信者の IP アドレスと DNS ルックアップを使用していると思われます。Web サイトがユーザーに到達するためには、DNS エントリが正しい必要があるため、DNS は実際にはスプーフィング可能ではありません。
ただし、サーバーがラウンドロビン IP アドレス DNS 設定を使用している場合、Google は DNS ルックアップを実行するときに別の IP アドレスにリダイレクトされるため、それでも問題があります。
よくある質問から
http://www.mygooglemapssite.com/のキーは、このアドレスを使用してサイトにアクセスした場合にのみ受け入れられることに注意してください。IP アドレス (例: http://10.1.2.3/ ) または DNS CNAME レコードを使用して www.mygooglemapssite.com にエイリアス化されたホスト名でサイトにアクセスする場合は、受け入れられません。
私の推測ではHost、ページをリクエストするときに送信されるヘッダーを使用している可能性があります。これは、通常、Google がその API スクリプトをページに直接含めるように要求するのと同じように機能します。次に、そのスクリプトは現在のページのヘッダーにアクセスし、それを使用して確認できます。
私の推測は、IP アドレスやエイリアスに対しては機能しないという事実で裏付けられています。つまり、DNS チェックを行っていないということです。
このメソッドは、ページにアクセスするための正しいヘッダーである必要があるため、スプーフィングできません。ただし、これは、ドメインへのエイリアスが機能しないことを意味します。
ただし、これは、このサーバー側を確認できないため、コードにアクセスするために Javascript ライブラリを提供する必要があることも意味します。
フランシ・ペノフが挙げたすべての点に同意します。他人の API キーの使用について少し詳しく説明したいと思います。に登録key1するとしexample.comます。
最初の試行 – anothersite.comhasの場合<script src="http://www.google.com/jsapi?key=key1">、Google はリファラー (言及されているハッシュ スキーム) をチェックできますが、この場合は不一致があります。リファラーはスプーフィングされる可能性があると多くの人が言及していますが、悪意のある攻撃者はこれをどのように克服するのでしょうか? これは実際にはここには当てはまりません。リクエストを作成すれば、任意のヘッダーを送信できますが、悪意のあるハッカーはどのようにしてユーザーのリファラーを偽装するのanothersite.comでしょうか? これは一般的に簡単ではありません。IE 6 には古いバージョンの flash があり、攻撃者がクロス ドメイン リクエストを行うときに任意のヘッダーを設定できましたが、一般に、これは script では機能しませんsrc。含まれているJavascriptがこれdocument.locationを防ぐために検証を行うかどうかはわかりません（おそらくそうではありません）。
2 回目の試行 – 悪意のある攻撃者が、API キーの Google Javascript をmysite.comのページ ソースからコピーし、変更した JavaScript を に埋め込みanothersite.comます。現在、Google は何もチェックできません (リモート IP はユーザーのコンピューターであり、あなたや Google ができることはあまりありません)。
そのため、何らかの理由で API キーを秘密にしておく必要がある場合 (1 つの理由として、悪意のある人物がキーをブラックリストに載せたりブロックしたりする可能性があります)、サーバー経由でクライアントおよびプロキシ リクエストにキーを埋め込まないでください (アプリケーション コードには、鍵）。
これが機能する理由は、javascript で API 呼び出しを行うことができないためです。ブラウザのセキュリティにより、javascript が発信元のドメイン以外の場所でリクエストを作成するのを防ぎます。このため、JavaScript からの API 呼び出しはすべて、API キーが保存されているサーバーを介してバウンスする必要があります (API キーは JavaScript には表示されません)。