web-dev-qa-db-ja.com

CORS-本番環境で許可されているOriginとしてのlocalhost

プロダクションのバグをトラブルシューティングするときに、ローカルの開発環境からプロダクションRESTサーバーにアクセスできると便利な場合があります。ただし、許可されたオリジンにローカルホストを追加するとセキュリティが低下するので心配ですリスク。検索により矛盾する情報が得られました。私の懸念は有効ですか？なぜですか？

restsecurityhttpwebservercors
16
Devon Sams

あなたが持っていると思います

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://localhost

リスクは、ユーザーのマシンで実行されているサービスがサイトの Same Origin Policy を効果的にバイパスする可能性があることです。

したがって、REST URLなど

https://example.com/User/GetUserDetails

ユーザーのコンピューターで実行されている悪意のある、または侵害されたサービスは、ユーザーのブラウザーを介してその要求を行い、ユーザーの詳細を取得する可能性があります。これは、ユーザーの認証Cookieが要求と共に渡されるためです。

これで、ユーザーのコンピューターで実行されている悪意のあるサービスがブラウザーから認証Cookieを直接取得し、要求自​​体を行うことができると主張できます。ただし、サービスに独自の欠陥（XSSなど）がある場合、別のサイトがRESTサービス（evil.example.org --XSS-> localhost -CORS-> example.com/User/GetUserDetails））を介してユーザーを危険にさらす可能性があります。

ユーザーがローカルリバースプロキシを実行して何かにアクセスしている場合に危険にさらされる可能性のある別のシナリオ。これにより、標的サイトが悪意のある、または侵害された場合に、標的サイトがユーザーを侵害することが可能になります。これは、ユーザーがlocalhostのドメインでターゲットサイトにアクセスするためです。

本当にこれを行う必要がある場合は、RESTサービスにアクセスするときに、リクエストにAccess-Control-Allow-Origin: https://localhostヘッダーを追加するだけの特別な開発者アカウントを用意することをお勧めします。そうすることで、 https://localhostでのみフロントエンドサーバーを実行していることがわかっているため、他のユーザーを危険にさらしているため、開いているCORS設定によって危険にさらされることはありません。

別の方法は、フロントエンドのローカルコピーにnoonewouldusethis2859282.localhostのようなものを使用することです。次に、Access-Control-Allow-Origin: https://noonewouldusethis2859282.localhostヘッダーを安全に追加できます。他の誰もこれを使用せず、CORS攻撃から安全だからです。

16
SilverlightFox

本番環境のCORS設定にlocalhostを追加しても、セキュリティ上の問題はありません。

次のようなものを追加することにより：

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:3000

これで、ブラウザはlocalhost：3000からサービスへの呼び出しを許可され、 Same Origin Policy をバイパスします。これで、どのWeb開発者も、ローカルマシンから実行するWebページを作成して、APIを呼び出すことができます。これは、チームにとって便利です。ただし、localhostは パブリックルーティング可能なアドレス ではありません。 http：// localhost：30 へのリンクを共有することはできません。 CORSは、サイトを呼び出すWebブラウザーのセキュリティ対策にすぎません。だれでも、サーバー間呼び出し（またはスクリプト）を介してエンドポイントを呼び出すことができます。ただし、回避する必要があります：

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *

これにより、すべてのWebサイトでサイトを利用できるようになります。代わりに、Access-Control-Allow-Originを必要なサイトにロックしてください。残念ながら、Access-Control-Allow-Originは単一の値しかとらないため、ホスト要求サーバー側を処理して有効な値を返す必要があります（ 詳細 ）。

CORSエンドポイントを呼び出すときの認証

認証を必要とするCORSリクエストを行う場合は、Authorizationヘッダーを呼び出しに追加し、Cookieを渡さないようにする必要があります- fetchはデフォルトでこれを行います 。したがって、CORエンドポイントに対して行われる呼び出しは、そのセッションに対してのみ持つヘッダーにトークンを追加するJavaScriptを介して行われます。 Cookieまたはlocalstorageを介してトークンを保存する場合、そのドメインからのみアクセスできることに注意してください（ 詳細 ）。本番エンドポイントとlocalhostには、同じCookieと共有localstorageはありません。

ChromeでCORSを無効にする

最後に、Chromeを--disable-web-securityで開始することで、Chromeから任意のサイトにCORSリクエストを送信できます（ 詳細 ）。

最後に、Google Chromeは、Service Workerが安全なWebサイトおよび http：// localhost でのみ実行できるようにします。開発用にlocal.example.comを作成する場合は、SSL証明書を作成し、ローカルマシンですべての構成を行って実行する必要があります。 http：// localhost：XXXX を使用することをお勧めします。

4
Chris Lorenzo