概要この記事には主に 3 つのキーワードが含まれています。
同一生成元ポリシー (SOP)相同まず、同じオリジンが何を意味するのかを説明します。プロトコル、ドメイン名、ポートがすべて同じであり、それが同じオリジンです。
制限クロスドメインの問題が発生する理由は、SOP のさまざまな制限によるものです。しかし、具体的に何が制限されているのでしょうか? SOP が「非同一オリジンのリソースの取得を制限する」という意味だと言うなら、それは間違いです。最も単純な例は、画像、CSS、JS ファイルなどのリソースを参照するときにクロスドメインが許可されることです。 SOP が「クロスドメイン リクエストを禁止する」という意味だと言う場合、これも間違いです。本質的に、SOP はクロスドメイン リクエストを禁止するのではなく、リクエスト後のリクエストの応答を傍受します。これにより、後述するCSRFが発生します。 実際、SOP は単一の定義ではなく、状況に応じて異なる解釈が行われます。
実際のアプリケーションで遭遇する可能性のある 3 つの例を以下に示します。
SOPがない場合:
クロスドメインをバイパスSOP はセキュリティをもたらしますが、ドメイン間の要求がある場合があるため、ある程度のトラブルも生じます。スペースの制限とインターネット上に関連記事が多数あるため、ここではクロスドメインの問題の解決策について詳しく説明せず、いくつかのキーワードのみを示します。 アヤックスの場合
iframeの場合
クロスサイトリクエストフォージェリ (CSRF)簡単な説明CSRF(クロスサイトリクエストフォージェリ)は一般的な攻撃方法です。これは、A ウェブサイトが正常にログインした後、Cookie が正常に保存されることを意味します。他のウェブサイト B は、何らかの方法で A ウェブサイトのインターフェイスを呼び出して操作し、A インターフェイスは要求時に自動的に Cookie を取得します。 前述のように、SOP は htmltag を通じてリソースをロードすることができ、また、SOP はインターフェース要求をブロックせず、要求結果を傍受します。CSRF はこれら 2 つを利用します。 したがって、SOP は CSRF を防止する方法として使用することはできません。 GET リクエストの場合、<img> 内に直接配置して、誰にも気付かれずにクロスドメイン インターフェイスをリクエストできます。 POST リクエストの場合、多くの例ではフォーム送信が使用されます。 <form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST"> <input type="hidden" name="acct" value="マリア" /> <input type="hidden" name="金額" value="100000" /> <input type="submit" value="私の写真を見る" /> </フォーム> 最終的に、これらの 2 つの方法では、リクエストが HTML によって制御され、JS を使用して結果を直接操作できないため、クロスドメインが報告されません。 SOP と ajaxajax リクエストの場合、データを取得した後、必要に応じて js 操作を実行できます。この時点では、同一生成元ポリシーにより応答は阻止されますが、リクエストは引き続き行われます。応答のインターセプションを実行するのはバックエンド プログラムではなくブラウザだからです。実際、リクエストはサーバーに送信され、結果が返されていますが、セキュリティ ポリシーにより、ブラウザーは js 操作の続行を許可しないため、「CORS ポリシーによってブロックされました: 要求されたリソースに 'Access-Control-Allow-Origin' ヘッダーが存在しません」というよく知られたメッセージが報告されます。 したがって、同一オリジンポリシーは CSRF を防止する方法として使用することはできないことを再度強調しておきます。 ただし、CSRF を防止できる例外があります。ブラウザはすべてのリクエストが正常に送信されることを許可しません。上記の状況は単純なリクエストに限定されます。関連する知識については、以下の CORS セクションで詳しく説明します。 CSRF対策SOP は CSRF によって悪用されるので、本当に役に立たないのでしょうか? いいえ! SOP が Cookie の名前の範囲を制限していることを覚えていますか? リクエストによって Cookie が自動的に取得されますが、攻撃者は Cookie の内容自体を取得することはできません。 したがって、CSRF に対処するための考え方は、トークンを Cookie に書き込み、リクエストを行うときにそのトークンをクエリ、本文、またはヘッダーに含めることです。リクエストがサーバーに到着し、トークンをチェックします。トークンが正しければ、そのリクエストは Cookie を表示できるドメインから送信されたものであるはずです。CSRF はこれを実行できません。 (この方法はフロントエンドとバックエンドを分離するために使用され、バックエンドのレンダリングはDOMに直接書き込むことができます) サンプルコードは次のとおりです。 var csrftoken = Cookies.get('csrfToken') 関数csrfSafeMethod(メソッド) { // これらの HTTP メソッドは CSRF 保護を必要としません /^(GET|HEAD|OPTIONS|TRACE)$/.test(メソッド) を返します } $.ajaxSetup({ 送信前: 関数(xhr, 設定) { if (!csrfSafeMethod(settings.type) && !this.crossDomain) { xhr.setRequestHeader('x-csrf-token', csrftoken) } }, }) クロスオリジンリソース共有 (CORS)クロスドメインはブラウザの制限ですが、サーバーが CORS 関連の構成を設定すると、サーバーに返される情報ヘッダーに Access-Control-Allow-Origin が追加されます。ブラウザは、このフィールドの値が現在のオリジンと一致することを確認すると、クロスドメイン制限を解除します。
CORS には 2 種類のリクエストがあります。 簡単なリクエスト
上記の 2 つの条件を満たすすべてのリクエストは CORS シンプル リクエストです。単純なリクエストはサーバーに直接送信されるため、CSRF が発生する可能性があります。 事前飛行リクエスト単純なリクエストの要件を満たさないリクエストでは、まずプリフライト リクエストを送信する必要があります。ブラウザは、実際のリクエストを行う前に、現在のソースが CORS ターゲットを満たしているかどうかをサーバーに問い合わせる OPTION メソッドを使用してリクエストを送信します。正式なリクエストは、検証に合格した後にのみ送信されます。 たとえば、application/json を使用してパラメータを渡す POST リクエストは単純ではないリクエストであり、事前チェック中にインターセプトされます。 たとえば、PUT メソッド リクエストが使用される場合、事前チェック リクエストも送信されます。 CSRF を防ぐことができる上記の例外は、事前チェック リクエストを指します。クロスドメイン リクエストの事前チェックが成功した場合でも、実際のリクエストは送信できないため、CSRF が成功しないことが保証されます。 CORS と Cookie同じドメインとは異なり、クロスドメイン CORS リクエストは、デフォルトでは Cookie と HTTP 認証情報を送信しません。フロントエンドとバックエンドの両方で、構成に Cookie を含めるようにリクエストを設定する必要があります。 このため、axios では CORS リクエストを行うときに withCredentials: true を設定する必要があります。 以下は、node.js バックエンド koa フレームワークの CORS 設定です。 /** * CORSミドルウェア * * @param {Object} [オプション] * - {String|Function(ctx)} origin `Access-Control-Allow-Origin`、デフォルトはリクエスト Origin ヘッダー * - {文字列|配列} allowMethods `Access-Control-Allow-Methods`、デフォルトは 'GET、HEAD、PUT、POST、DELETE、PATCH' * - {文字列|配列} exposeHeaders `Access-Control-Expose-Headers` * - {文字列|配列} allowHeaders `アクセス制御許可ヘッダー` * - {文字列|数値} maxAge `Access-Control-Max-Age`(秒単位) * - {ブール値} 資格情報 `Access-Control-Allow-Credentials` * - {Boolean} keepHeadersOnError エラーが発生した場合に `err.header` に設定されたヘッダーを追加します * @return {Function} corsミドルウェア * @api パブリック */ 以上がJS Same-Origin PolicyとCSRFの詳しい説明です。JS Same-Origin PolicyとCSRFの詳細については、123WORDPRESS.COMの他の関連記事もご覧ください。 以下もご興味があるかもしれません:
|
>>: MySQL5.7.17 winx64 インストール バージョン構成方法 Windows Server 2008 R2 でのグラフィック チュートリアル
序文最近、プロジェクトを構築しているときに、リクエストのカプセル化について考え、どのようにカプセル化...
一般的に、データ テーブル内の列を ID 列として設定すると、ID 列の表示値を手動で ID 列に挿...
この記事では、ネストされたタブ機能を実装するためのjQueryの具体的なコードを参考までに紹介します...
ブラウザウィンドウの中央に要素を配置する方法まず、コード ブロックを示します。すでにコードを理解して...
最近、関連テーブル内のすべてのフィールドをクエリし、それらを 1 つのフィールドに再グループ化する必...
この記事の例では、参考のために画像をサーバーにアップロードするためのjsの具体的なコードを共有してい...
目次インストールパッケージのダウンロードインストール環境変数の設定インストールが成功したか確認する記...
前提条件: データベースを復元するために必要な .frm ファイルと .ibd ファイルを保存します...
設置環境WIN10 VMware Workstation Pro 15.0.0 ビルド 101344...
今日のキャンパス採用筆記試験では、固定された最初の行と最初の列を実装し、幅をウィンドウの変更に適応さ...
背景:サイトはフロントエンドとバックエンドから分離されています: vue+springbootフロン...
以前にインストールしたmariadbを削除する1. rpm -qa | grep mariadb を...
nginx が proxy_pass を設定する場合、末尾に "/" がある U...
成果を達成する html <div class="コンテナ"> &l...
前提条件: ヘッダー情報操作をサポートするには、ngx_http_headers_module モジ...