CORS REST APIホワイトリスト

Question

REST APIを使用しています。このAPIを複数のWebアプリケーションから使用したいのですが、ホワイトリストに登録されたクライアントからのリクエストのみを許可したいのです。最初の呼び出しのポイントは、必要なヘッダーをREST API Webサーバー（許可されたドメイン）はすべて問題ありませんが、これはブラウザを使用するクライアントのみをホワイトリストに登録しますか？APIへのスクリプトによるアクセスを実際に防ぐ方法はありますか？スクリプトによるアクセスとは、PHPを意味します、Java、.NET、またはREST API URLに直接Web呼び出しを行う他のサーバー側言語。そしてもちろん、リクエストは手動で作成されるため、必要なヘッダーを追加できます（Originなど））、ドメインリクエストを偽造する可能性があります。スクリプトは必要ないと思いますが、フィドラーからの合成リクエストでも同じ結果が得られます。

（CORS構成を渡す）ブラウザーからの要求のみを許可し、他のすべてを拒否することは可能ですか？.

究極的には、REST APIは本質的に安全でないCORSを有効にします。CORSヘッダーはクライアントをホワイトリストに登録するメカニズムを提供しますが、HTTPに基づいており、手動で作成されたHTTPリクエストはこれを簡単に回避できます。

CORS設定を許可すると、不要なWebサイトへの任意の埋め込みが防止されます。

これは私のチーム内で何度か浮かび上がってきたトピックです。最近では、Web（REST）APIのような種類のアプリケーションを作成することが多くなっています。これは、新しいアプリケーションで機能を簡単に再利用できるので、セキュリティについての考えが高まっています。データ漏洩のセキュリティではなく、許可されたクライアントに基づいてAPIへのアクセスのみを許可します。

CBHacking · Accepted Answer

TLDR：いいえ、必要だと思われる場合は、おそらく何か問題が発生しています。

ブラウザーに公開されているものへの非ブラウザーアクセスを防ぐための文字通り可能な方法はありません。サーバーに関する限り、WebブラウザーはHTTP（および関連するプロトコル）トラフィックを送受信するプログラムにすぎません。それでおしまい。これは、curlを使用して行うことができます。さまざまなプログラミングフレームワークで使用できるさまざまなWebRequestオブジェクトのいずれかを使用して行うことができます。シンプルなTCPサーバーへのソケットと送信するバイトを手動で入力（nc/ncat/netcatプログラムを参照）ブラウザが通常提供する情報- Cookie、User-Agentヘッダー、ブラウザ固有のHTTPSおよびURLの癖、HTTP Authorization、TLSクライアント証明書、JavaScript解析などはすべて、他のプログラムによって偽装される可能性があります。これには、すべてのCORSヘッダーと動作が含まれます。

あなたができることは認証を要求することです。 Webサービスのコンシューマーが認証された場合、通常のWebブラウザー、目の不自由な人のためのスクリーンリーダー、モバイルアプリケーション、PHP Webサーバー、telnet Commodore 64でプログラムするか、セマフォでビットを個別に非常にすばやく取り出すか。

理論的には、クロスオリジン認証はそれほど難しくありません。 Access-Control-Allow-Credentials: true CORS応答ヘッダー（HTTP AuthorizationヘッダーとCookieを許可する）またはAccess-Control-Allow-Headers: <HEADERNAME> CORS応答ヘッダー（カスタム認証ヘッダー付き）を送信する必要があります。どちらの場合も、クライアントが有効な認証トークンを取得するための何らかの方法を提供する必要があります（これは、Webアプリ、Webサービス、またはその他の手段による可能性があります。別のCORS対応のWebサービスである可能性もあります）。。もちろん、認証サービスへのスクリプトによるアクセスを防ぐ方法はないので、資格情報を持つ誰でも/何でも有効なトークンを取得して使用できます。

ここであなたのユースケースは何ですか？スクリプト化されたアクセスをブロックしようとしているのはなぜですか？なぜこれがうまくいくと思っているのですか？つまり、Webブラウザーはスクリプトを実行できるため、JavaScriptを含むページをWebブラウザーがロードしてWebサービスにアクセスし、結果を取得して、デスクトップまたはサーバーアプリケーションに送信することを妨げるものは何もありません。

編集：

最終的には、REST CORSを本質的に安全にするAPIです

「安全」の意味を理解していないか、Webサーバーの機能を理解していません。 Webサーバーは着信HTTP要求を解析します（HTTPはテキストベースのプロトコルですが、通常TCPポート80で送信されますTCPポート443）に送信されたSSL/TLSストリーム内で、HTTP要求の内容に基づいて、HTTP応答を返します。Webサーバーは、「本質的に安全ではない」という意味で、機密情報を公開すると、ネットワークを介してそれに接続でき、適切なバイト文字列を送信できる人なら誰でもそのデータを取り戻すことができます。もちろん、世界中のあらゆるプロトコルのほぼすべてのネットワークサーバーがこのように動作します。 ..

補足として、これはCORSの問題ではありません。 CORSをまったく許可しない場合でも、想定している「攻撃者」の種類はまったく変わりません。 CORSは、ブラウザーのセキュリティモデルの重要な部分（ "same-Origin policy"と呼ばれる）に穴を開ける方法ですが、まったく関係ありません。ブラウザではないものに。

grochmal · Answer

これはCBHackingの回答とかなり似ています。 CSRFアドを追加しました。

ホワイトリストに登録されたクライアントからのリクエストのみを許可したい。

あなたがウェブ上にいるなら、あなたはすでにそこのブーツで死んでいます。クライアントをホワイトリストに登録する実際の方法は、次のものを使用することだけです。

クライアントを実行しているデバイスのOS全体（およびおそらくハードウェアも）に署名するための公開鍵暗号。
クライアントとサーバー間に安全なチャネルを確立するための公開鍵暗号化（ただし、CA証明書が上記で署名したものの一部である場合、HTTPSで十分な場合があります）。

真剣に、それをしようとしないでください、それは愚か者の用事です。

究極的には、本質的に安全でないCORSを有効にするREST APIです。

逆に。しかし、CORSはブラウザーのセキュリティについてであり、ブラウザーウィンドウの前にいるユーザーの期待についてです。つまり、REST API at http://rest.comはこれを使用します：

Access-Control-Allow-Origin: http://example.com

次に、閲覧している人example.comブラウザを使用すると、リクエストを実行できます（Origin: http://example.com）要件を満たします。

ただし、不正なWebページはブラウザから実行できません。

インターネット全体でWebページ（またはREST API））を表示したくない場合は、それを表示できるユーザーを認証する必要があります。認証を行わないユーザーには送信しないでください。正しく。

なりすましの呼び出しを防ぐには、特定のクライアントからのアクセスではなく、CSRFから防御する必要があります。 REST APIに対して認証を実行し、許可されたユーザーにのみユーザーデータを送信します。

現在、CSRFはCORSで実際にはカバーされていないため、これにはCSRF保護が必要です（OriginヘッダーはCSRF保護として使用できるため、厳密には当てはまりませんが、保護は不十分です）。 OWASPsガイドラインを使用と同期されたCSRF防止トークンを生成します。これにより、ユーザーのトラフィックを盗聴して独自のリクエストを挿入する不正スクリプトを（適切に）防止します。

CORSトークンとCSRFトークンの比較についての補足：古い（ただし実際の））SO SilverlightFoxによる回答