CORSとSOP
3387 ワード
reactとnode.jsでToyプロジェクトをするときにcorsホットスポットが出てきたので、この機会に曖昧な概念を再整理し、位置づけを開きました.
SOPとは、同じソース原則を指し、1つのページから別のソースにリソースを要求することはできません.
ここで言う同じ出所です.両URLのプロトコル ポート(EN-US)(指定されている場合) ホスト(EN-US)は、同じソースとみなされるには、すべて同じでなければなりません. 同じソースの原則を守らないと、どのような安全問題が発生しますか?
ユーザーが銀行のWebサイトにログインしたと仮定した場合、セッションは保留中であると仮定します.当時、電子メールや何らかの理由でハッカーのページに偶然アクセスした場合、サーバに銀行口座情報を直接要求することができます.登録してあるから!
したがって、サーバ側は、このリソースを要求する場所が信頼できるかどうかを決定する必要があり、ブラウザ側もSOPポリシーを使用してこれを阻止します.
しかし,従来と異なり,ウェブページが複雑になるにつれて,異なるソースの他の場所に要求することが多くなり,解決する必要がある.
そこでSOPを解決する方法で,Formラベルとスクリプトタグの間接的な方法で他の人に要求した.
同時にjavascriptにもネットワークに関するメソッドが追加され,サーバ側で確認することで同じソースを解決するという原則がCORSである.
CORSリクエストには、セキュリティリクエストやその他の不安全リクエストがあります.
セキュリティ要求は次のとおりです.セキュリティ方法–GETまたはPOST、HEAD要求 .セキュリティヘッダ(セキュリティヘッダ)-次のリストに属するヘッダ
Accept
Accept-Language
Content-Language
値はアプリケーション/x-www-form-urlcodedまたはmultipart/form-data、text/plainのcontent-type です.
それ以外に、私たちはこれが安全ではない要求だと思っています.2つの要求の違いは:
上記のフォーム/スクリプトタグは、要求を作成できないPUT、DELETE、PATCHなどのメソッドを示します.安全でない要求に対しては、「preflight」という名前のサーバに事前要求を送信し、この要求が有効であることを確認します.
サーバはまず、「原点」ヘッダーの値をチェックします.「原点」が許可されている場合、「アクセス-制御-すべての-Origin」ヘッダーに許可されたOrigin情報または「*」が含まれて応答します.
許可されていないoriginの場合、JavaScriptを使用して結果値にアクセスし、corsエラーをコンソールに配置できます.
安全でないリクエストの場合、ブラウザはこのリクエストを送信する前にpreflightリクエストを送信します.preflightリクエストはOPTIONメソッドでリクエストを送信し、次の2つのタイトルと空白の内容でリクエストを送信します.アクセス-制御-要求-メソッドヘッダ-セキュリティでない要求のためのメソッド情報が含まれます. アクセス-制御-要求-Headersヘッダ-セキュリティでない要求で使用されるヘッダのリストが含まれます.各見出しはカンマで区切られます. 許可されたリクエストの場合、サーバは次の内容を含むタイトルと空の本文の応答を送信します.アクセス制御すべてのOrigin–*または要求を発行するOrigin(https://javascript.infoなど) アクセス-制御-すべてのメソッド-許可されたメソッド情報を含む. アクセス-コントロール-すべてのHeaders–許可されたタイトルリストが含まれます. アクセス-制御-MAx-Agene–パフォーマンスを確認するためにキャッシュされる秒数を指定します.これらのスーパータスク情報をキャッシュすることで、ブラウザはpreflightリクエストを一定期間スキップし、安全でないリクエストを送信することができます.
デフォルトでは、CORSリクエストはCookieまたはHTTP認証などの認証情報を同時に送信しません.資格証明書を持つリクエストは、サーバにアクセス権の高いリクエストを任意に送信できるため、より高いセキュリティポリシーが必要です.
したがって、corsは、このリクエストに認証に関連するデータが含まれていることを示す認証情報を提供する必要があります.「include」オプション.
その後、サーバが認証情報を含む要求を受け入れることに同意した場合、サーバは応答にAccess-Clontrol-Allow-OriginヘッダとAccess-Clontrol-Allow-Coriginヘッダ:trueヘッダを追加します.
証明書付きリクエストを送信する場合、*アクセスコントロールAllow-Originに書き込めません.上記の例に示すように、Access Control Allow-Originでは正しいバイナリ情報のみを指定する必要があります.
これは、サーバがどのoriginリクエストに関する情報を信頼できるためです.
SOP
SOPとは、同じソース原則を指し、1つのページから別のソースにリソースを要求することはできません.
ここで言う同じ出所です.
ユーザーが銀行のWebサイトにログインしたと仮定した場合、セッションは保留中であると仮定します.当時、電子メールや何らかの理由でハッカーのページに偶然アクセスした場合、サーバに銀行口座情報を直接要求することができます.登録してあるから!
したがって、サーバ側は、このリソースを要求する場所が信頼できるかどうかを決定する必要があり、ブラウザ側もSOPポリシーを使用してこれを阻止します.
しかし,従来と異なり,ウェブページが複雑になるにつれて,異なるソースの他の場所に要求することが多くなり,解決する必要がある.
そこでSOPを解決する方法で,Formラベルとスクリプトタグの間接的な方法で他の人に要求した.
同時にjavascriptにもネットワークに関するメソッドが追加され,サーバ側で確認することで同じソースを解決するという原則がCORSである.
CORS
CORSリクエストには、セキュリティリクエストやその他の不安全リクエストがあります.
セキュリティ要求は次のとおりです.
Accept
Accept-Language
Content-Language
値はアプリケーション/x-www-form-urlcodedまたはmultipart/form-data、text/plainのcontent-type
それ以外に、私たちはこれが安全ではない要求だと思っています.2つの要求の違いは:
上記のフォーム/スクリプトタグは、要求を作成できないPUT、DELETE、PATCHなどのメソッドを示します.安全でない要求に対しては、「preflight」という名前のサーバに事前要求を送信し、この要求が有効であることを確認します.
セキュリティ要求
GET /request
Host: anywhere.com
Origin: https://javascript.info
...
上記の要求を出すと、サーバはまず、「原点」ヘッダーの値をチェックします.「原点」が許可されている場合、「アクセス-制御-すべての-Origin」ヘッダーに許可されたOrigin情報または「*」が含まれて応答します.
許可されていないoriginの場合、JavaScriptを使用して結果値にアクセスし、corsエラーをコンソールに配置できます.
安全でない要求
安全でないリクエストの場合、ブラウザはこのリクエストを送信する前にpreflightリクエストを送信します.preflightリクエストはOPTIONメソッドでリクエストを送信し、次の2つのタイトルと空白の内容でリクエストを送信します.
資格
デフォルトでは、CORSリクエストはCookieまたはHTTP認証などの認証情報を同時に送信しません.資格証明書を持つリクエストは、サーバにアクセス権の高いリクエストを任意に送信できるため、より高いセキュリティポリシーが必要です.
したがって、corsは、このリクエストに認証に関連するデータが含まれていることを示す認証情報を提供する必要があります.「include」オプション.
その後、サーバが認証情報を含む要求を受け入れることに同意した場合、サーバは応答にAccess-Clontrol-Allow-OriginヘッダとAccess-Clontrol-Allow-Coriginヘッダ:trueヘッダを追加します.
200 OK
Access-Control-Allow-Origin: https://javascript.info
Access-Control-Allow-Credentials: true
重要だ!証明書付きリクエストを送信する場合、*アクセスコントロールAllow-Originに書き込めません.上記の例に示すように、Access Control Allow-Originでは正しいバイナリ情報のみを指定する必要があります.
これは、サーバがどのoriginリクエストに関する情報を信頼できるためです.
Reference
この問題について(CORSとSOP), 我々は、より多くの情報をここで見つけました https://velog.io/@seeker1207/CORS와-SOPテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol