web-dev-qa-db-ja.com

ブラウザーはなぜ同じ起源のセキュリティポリシーをiframeに適用するのですか？

今日、Chrome（V37））で簡単なテストを行いました。小さなページを作成してブラウザにロードしました：

<!DOCTYPE html>
<html>
<head>
    <title>Untitled Document</title>
</head>
<body>
    <p>Normal page</p>
    <iframe src="https://security.stackexchange.com/" />
</body>
</html>

コンソールを検査すると、次のエラーメッセージが見つかりました。

「X-Frame-Options」が「SAMEORIGIN」に設定されているため、フレームに「 https://security.stackexchange.com/ 」を表示することを拒否されました。

ブラウザーがiframesに同じオリジンポリシーを適用する必要があるのはなぜですか？

web-browsersame-origin-policy
60
sampathsris

レビュー：同一起源ポリシー

最初に、ここで観察された動作（iframeがレンダリングされない）がはるかに厳密であり、デフォルトのsame-Originポリシーよりも明確であることを明確にします。すでにご存じの場合は、下の「実際に起こっていること」までスキップしてください。

確認するために、同一オリジンポリシーはscriptsがクロスオリジンリソースのコンテンツにプログラムからアクセスできないようにします。同じ起源のポリシーがさまざまなタイプのリソースにどのように適用されるかを検討します。

  • 画像：_<img>_タグは、クロスオリジン画像をユーザーに視覚的に表示しますが、スクリプトで画像を読み取ることはできません_<canvas>_にロードされたときのコンテンツ（つまり、キャンバスにクロスオリジン画像が含まれている場合、toDataURLは失敗します）
  • Scripts：クロスオリジンスクリプトは、_<script>_要素で参照されると実行されますが、ページはrunしか実行できませんreadではなく、スクリプトの内容。
  • Iframe：画像のように、フレーム化されたクロスオリジンページのコンテンツはユーザーに視覚的に表示されますが、外側のフレーミングページのスクリプトにはアクセスできませんフレーム付きページのコンテンツ。

同じ起源のポリシーは、他のすべてのタイプのリソースに適用されるのと同じ理由でiframeに適用されます。フレーム化されるWebページ（または表示される画像、またはAjax経由でアクセスされるリソース）は、リソース自体のOriginからの資格情報を使用してフェッチされます。 （たとえば、_google.com_からリソースをフェッチするHTTPリクエストには、_google.com_に設定されたブラウザのCookieが含まれます）。リクエストを発行したページには、別のオリジンからの認証情報でフェッチされたリソースへの読み取りアクセスを付与しないでください。

実際に起こっていること：X-Frame-Options

ただし、ここに表示される動作は、同一オリジンポリシーよりも厳密です。フレーム付きページは表示されませんすべて。フレーム化された（はずの）ページをホストするクロスオリジンサーバーは、 _X-Frame-Options_応答を送信して、このブロッキング動作を要求します。 header は、ページのフレーム化を許可する方法を指定します。

  • [〜＃〜] deny [〜＃〜]ページはフレームに表示しようとするサイトに関係なく表示できません。
  • [〜＃〜] sameorigin [〜＃〜]ページは、ページ自体と同じOriginのフレームにのみ表示できます。
  • ALLOW-FROM riページは、指定されたOriginのフレームにのみ表示できます。

ここで、サイトは_X-Frame-Options: SAMEORIGIN_を送信します。これは、サイトがフレーム化されたページと同じOriginを持つページでのみフレーム化できることを意味します。

セキュリティの観点から、これは clickjacking （「UI redress」攻撃とも呼ばれます）を防ぐために行われます。クリックジャッキング攻撃では、ページは_<iframe>_内の別のサイトのクリックでアクティブ化されるコンポーネントを表示し、ユーザーをだましてクリックさせます（通常、フレーミングサイトの明らかにクリック可能な機能の上にターゲットコンポーネントを重ねることにより） ）。

簡単な例として、サイトは透明な_<iframe>_の_http://security.stackexchange.com_を配置して、フレーム化されたサイトの[ログアウト]リンクが[ここをクリックして無料お金を請求する]ボタンのすぐ上に来るようにすることができます。 。フレーミングページを表示すると、ユーザーは無料のお金を請求しようとしましたが、突然Stack Exchangeからログアウトしました。 _http://security.stackexchange.com_が_X-Frame-Options: SAMEORIGIN_ヘッダーを送信すると、悪意のあるクロスオリジンページは空の_<iframe>_のみを取得します。フレーム化されたサイトのコンテンツがレンダリングされたページに移動しなかったため、ユーザーが意図せずにログアウトリンクをクリックすることはありません。

OWASPには、詳細なページ クリックジャッキングに対する防御 があります。

42
apsillers

security.stackexchange.com の管理者は、他のサイトでフレーム化されないようにサイトを構成しています。これは通常、クリックジャッキング攻撃を防ぎ、他の人が security.stackexchange.com を広告でいっぱいのページに埋め込むのを防ぎ、トラフィックを節約するために行われます。 X-Frame-Optionsヘッダー ここ 。

この保護はデフォルトでオフになっています。

38
abacabadabacaba