APIの不正使用を回避するにはどうすればよいですか？

Question

「ウィジェット」、つまりパートナーがWebサイトに埋め込んでUIを表示し、APIを呼び出すスクリプトを設計する必要があります。

基本的に、API呼び出しで提供するいくつかのIDに基づいて、これらのサイトのデータを表示します。 避けたいのは、誰かがAPIを悪用し、それを使用してカタログ全体をこすり落とすことです。

スクリプトを埋め込む各パートナーには、APIを呼び出すときに提供する必要がある公開鍵が与えられます。スクリプトをロードするときに、このキーを追加するように依頼することもできます。例：

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

そうすることで、スクリプトのリクエストを使用してキー/ソースIPペアを登録し、キー/ IPペアが登録されたものと一致する場合に限り、後続のAPI呼び出しに応答できます（ライフタイムが制限され、1日あたりのリクエスト数に制限があります）。

難読化によるセキュリティであることは明らかなので、スクリプトがリロードされると完全にバイパスされてしまうため、これが良いアイデアかどうかはわかりません。しかし、アクセスを制限する他の方法はありません。すべてのユーザーに一意のキーを提供することはできません。パートナーにのみ提供します。すべてのコードが誰でも利用できるようになるため、私は秘密鍵システムを使用できません。基本的に、パブリックAPIへのアクセスを制限しています。つまり、その定義が矛盾しています。

このソリューションについてどう思いますか、これらの制約をどうしますか？

svidgen · Accepted Answer

いくつかのタイプの保護が必要です。

最初に、サイトBでサイトAのキーが使用されないようにする必要があります。

理論的には、キーがドメインにバインドされている場合、refererヘッダーに依存することはできませんが、クライアントがスクリプトを直接埋め込んでいるため、できますクライアント側の_document.location_に合理的に依存しています。その場所（またはその一部）をサーバーに直接送信することは信頼できません。ただし、これを使用してセッションキーを生成できます。

クライアントは、APIライブラリのリクエストに_client_key_を埋め込みます。
サーバーは、APIにアクセスできるホストを決定します（存在する場合）。
サーバーはセッションキーに「ソルト」を選択し、それをライブラリと共に（または別の事前認証交換の一部として）クライアントに送信します。
クライアントは、hash(document.location.Host + session_salt)を使用して_session_key_を計算します。
クライアントは、API呼び出しに_session_key_ + _client_key_を使用します。
サーバーは、セッションで_client_key_のホストと「ソルト」を検索し、ハッシュを計算して、提供された_client_key_と比較することにより、呼び出しを検証します。

2番目に、Hacker Hankがデバッグコンソールを開いたり、サイトAの変更されたクライアントを使用してAPIでやりたいことを実行できないようにする必要があります。

ただし、ハッカーハンクがAPIを悪用することを完全に防止することは、不可能ではないにしても非常に難しいことに注意してください。しかし、あなたはそれをより困難にすることができます。そして、私が知っているハンクを妨害する最も合理的な方法は、レート制限です。

リクエスト/秒/セッションおよびリクエスト/時間/セッションの数を制限します。（アクティビティの急上昇はおそらく妥当ですが、持続する単一のクライアントからの平均以上のトラフィックではありません。）
セッション数/ IP /時間を制限します。
リクエスト数/ IP /時間を制限します。単一のIPからの急増を許可しますが、持続的なトラフィックを許可しません。

番目に、すでに行っているように：トラフィックを暗号化します。確かに、NSAはそれを表示しますが、Hacker Hankはそうではありません。

Rob · Answer

JavaScriptファイルを保護されたリソースにして、ここで実行しているように聞こえます。そして、それを一種のトークン生成と同時にバンドルします。それは面白い。

私が一緒に働くセキュリティ担当者は、IPが偽造可能であるため、通常、手に負えないIPアドレスを無視します。しかし、SSLと組み合わせたIP制限を使用している場合は、通常はそれでうまくいきます。

しかし、IPアドレスを「ホワイトリストに登録」する必要があります。そうしないと、ハッカーが玄関に入るだけです。

私は懐疑的でしたが、実際にはあなたの計画はかなりうまく機能していると思います。 1）.jsファイルと後続のAPI呼び出しがTLS（SSLまたはhttps）で行われ、2）IPがホワイトリストに登録されている場合。次に、大胆な発言を行い、PCI（クレジットカード）のやり取りについても、セキュリティレビューに合格すると思います。

IMHO ...しかし、クレジットカード（PCI）や個人/個人情報（PII）ではなく、会社独自の情報を保護しようとしているだけなら、SSLがなくても、おそらくどれだけ良いかはあなたのカタログを公開するリスクを喜んでする。

または、次のように記述します。SSLを使用すると、専用のハッカーできませんでしたでカタログを取得できます。（SSLを破る場合を除き、Amazonも破られる可能性があります）。 SSLがなければ、専用のハッカーが通話を傍受し、IPを偽装し、カタログをプルダウンする可能性があります。ですから、それはリスクを判断するようなものです。

IPホワイトリストを省く方法を考えようとしています。これは、本格的なOAuthを使用せずに、通常は管理するのが面倒だからです;）。その上で麺を作ります。