[Browser] CORS

Web脆弱性攻撃

ブラウザが脅かされています.脅威の根本的な原因の一つは、ブラウザがJavaScriptを駆動することです.ブラウザでjavascriptを使用できるため、次のリスク要因があります.

AJAXでAPI

を呼び出す

動的DOM制御

ブラウザにおいて認証情報

を格納検索する.
ウェブサイトの脆弱性を利用した代表的な攻撃はXSSとCSRFである.

XSS

XSS(Cross-Site Scripting、サイト間スクリプト)は、攻撃者がウェブサイトに悪意のあるスクリプトを追加する方法です.攻撃が成功すると、このWebサービスユーザの動作により、XSSコードを含むスクリプトがWebサーバに転送され、ユーザシステム上で実行される.悪意のあるスクリプトは、ユーザーのブラウザ内で適切な検証なしに実行されるため、ユーザーのCookieやセッションタグなどの機密情報を盗んだり、悪意のあるサイトに移動したりする可能性があります.XSSはクライアントがサーバを信頼することによって生じる.

CSRF

クロスサイトリクエスト転送(CSRF)は、ユーザが自分の意思に応じて特定のサイトに攻撃者の意図を要求する行為(修正、削除、登録、送金など)である.ユーザが認証情報として攻撃者が作成したネットワークやXSS攻撃によって改ざんされたウェブサイトへのリンクに接続すると、攻撃者は認証情報をブロックしてサーバに要求を送信する.攻撃対象となるサイトでは,偽造された攻撃命令は信頼できるユーザからの要求であると考えられ,攻撃にさらされる.CSRFは、サーバがクライアントを信頼することによって生成される.

CORS

ソース(Origin)は、ドメイン(ホスト)、プロトコル、ポートの3つの側面で決定され、1台のサーバを表す概念です.セキュリティ上の理由から、ブラウザは同じソースポリシーに従います.同じソース・ポリシーは、あるソースからロードされたスクリプトがソースのリソースにのみアクセスできることを制限するセキュリティです.ブラウザは基本的にスクリプトのCross-origin(クロスソース)HTTPリクエストを制限しています.
しかしながら、フロントエンドサーバ(React等)の出現により、フロントエンドサーバはUIを受信し、受信したスクリプトから他のWebサーバにAPI要求を発行する.
クロスソースリソース共有は、同じソースポリシーを回避し、ブラウザのWebサイトのユーザーを保護するポリシーです.追加のHTTPヘッダを使用すると、あるソースで実行されるWebアプリケーションは、別のソースのリソースにアクセスし、インタラクションすることを許可されます.このプロセスでは、ブラウザはJavaScriptとリソースが存在するサーバの間で仲裁者として機能します.

COSのクロスソースを要求

クロスソースリクエストは、セキュリティリクエストと非セキュリティリクエストに大きく分けられます.

セキュリティ要求

単純なリクエスト
単純な要求は安全な要求であり、安全な方法とヘッダーのみを使用する交差ソース要求であり、以下のすべての条件を満たす.単純なリクエストはプリフライトリクエストを送信しません.

安全方法
- GET
- HEAD
- POST

セキュリティヘッダ
- Accept
- Accept-Language
- Content-Language
- Content-Type

application/x-www-form-urlencoded

multipart/form-data

text/plain

単純リクエストヘッダ
-Origin:要求のソース
単純応答ヘッダ
-Access-Control-Allow-Origin:許可されたソース
クロスソース要求が送信されると、ブラウザは常に要求にソースを含むヘッダーOriginを追加する.サーバはソースを確認し、応答にAccess-Control-Allow-Originヘッダを追加します.ブラウザは、Access-Control-Allow-Origin応答ヘッダに送信要求のソースがあるかどうかを確認し、ある場合は応答が成功し、JavaScriptから応答にアクセスできます.サーバのセキュリティを保護するために、JavaScriptはソースが許可されていることしか知らず、他のソースからのリクエストもサーバが許可されているかどうか分かりません.
応答ヘッダに要求を送信するソースがない場合、エラーが発生し、要求されたリソースを受信できません.エラーが発生しても、JavaScriptはエラーの詳細にアクセスできません.

安全でない要求

プリフェッチ要求
要求にサーバに副作用をもたらす可能性のある不安全な方法が含まれている場合、CORSはブラウザにpreflight(preflight、プリ転送)要求を転送してサーバサポートを要求する方法を要求し、サーバが許可されていない場合、実際の要求を送信する.これは、サーバが実際のリクエストが安全かどうかを事前に理解できる手段です.
preflightリクエストはOPTIONSメソッドを使用し、他にも2つのヘッダがあります.
- Origin-Access-Control-Request-Method:不安全な要求のための方法
-Access-Control-Request-Headers:不安全要求用ヘッダー
サーバは、プリホップ応答で200個のステータスコードと3個のヘッダを再送信する.
-Access-Control-Allow-Origin:許可されたソース
-Access-Control-Allow-Methods:許可された方法
-Access-Control-Allow-Headers:許可されたヘッダー
-Access-Control-Max-Age:ライセンスキャッシュ時間(秒)
サーバがリクエストを許可すると、ブラウザはpreflightリクエストの応答と比較し、実際のリクエストを送信します.その後は単純なリクエストと同じ手順で行います.

認証情報を含むリクエスト
JavaScriptにクロスソース要求を送信すると、CookieやHTTP認証などの認証情報はデフォルトで同時に送信されません.ユーザーの同意がないため、機密情報にアクセスすることもできます.
クロスソース要求fetchメソッドの場合、認証情報を含めるには、credentials: "include"オプションを明確に追加します.

fetch(uri, {
  credentials: "include"
});

サーバがリクエストを受け入れることに同意すると、uriに対応するクッキーがリクエストに同時に送信され、応答にAccess-Control-Allow-Origin: uriヘッダとAccess-Control-Allow-Credentials: trueヘッダが追加されます.