IE8 セキュリティー パート VII: クリックジャッキングを防ぐ 更新日: 2009 年 1 月 27 日 翻訳元: IE8 Security Part VII: ClickJacking Defenses (英語) 本記事は、Internet Explorer 開発チーム ブログ (英語) の翻訳記事です。本記事に含まれる情報は、Internet Explorer 開発チームブログ (英語) が作成された時点の内容であり、製品の仕様や動作内容を保証するものではありません。本記事に含まれる情報の利用については、使用条件をご参照ください。また、本記事掲載時点で、Internet Explorer 開発チームブログ (英語) の内容が変更されている場合があります。最新情報については、Internet Explorer 開発チームブログ (英語) をご参照ください。 Internet Explorer 8 について計画していたとき、セキュリティー チームは現実に行われている一般的な攻撃と、攻撃者が次にどこに注意を向けるのかを示す傾向について分析しました。IE8 の開発過程を通じて、新しい種類の脅威の先を行くために、セキュリティー研究のコミュニティーと緊密に協力してきました。最も巧妙かつ興味深い Web アプリケーションの脆弱性の一つは、セキュリティー研究者の Jeremiah Grossman 氏が Web 脆弱性の "眠れる巨人 (英語)" と呼んだクロス サイト リクエスト フォージェリィ (英語)(RSRF) です。Jeremiah 氏が示したように、一般的な解決方法が存在しないため CSRF 攻撃を防ぐのは困難です。ブラウザーのセキュリティー モデルの構造的な基盤は、複数の Web サイトが同時に相互作用する事を許可し、無関係な Web サイト間をシームレスに移動できるよう設計されています。しかしこれらはまさに CSRF 攻撃が利用しようとする能力そのものです。個人的な情報やその他の価値の高い情報の保存場所が、エンド ユーザーの PC から人気のある Web アプリケーションに変化するにつれて、CRSF への誘導 (英語) やその他の Web アプリケーションの脆弱性への誘導は増大の一途をたどるでしょう。 Internet Explorer 8 を設計する際には、CSRF 攻撃に対するブラウザーの攻撃対象領域を増大させないよう細心の注意を払いました。一例として、IE8 の新しい XdomainRequest オブジェクト (英語) はサーバーの明示的な許可の下でクロス ドメインの通信を許可しますが、新しいタイプの CSRF が可能とならないようにする特定の制限を含んでいます。エンド ユーザーは利用していない時は機密性のある情報を取り扱う Web サイトからログオフする事や、独立した InPrivate ブラウズのセッションを使う事で CSRF 攻撃の脅威を軽減できます。(InPrivate のセッションの Cookie 保存領域は空の状態から開始されるので、保存済みの Cookie が CSRF 攻撃で再利用される事がありません) とはいえ究極的には、Web アプリケーションは CSRF 脆弱性を防止するよう構築されるべきです。最善に設計された Web アプリケーションでは、被害者のユーザーが意図的に送信したのではない不正なリクエストを識別できるチャレンジ トークン (英語) やそれに類似した手法を使い、自身を保護しています。残念ながら、チャレンジ トークンやそれに類似した手法は脆弱性に陥りやすいのです。第一の脆弱性はクロス サイト スクリプティング (英語)(XSS) です。トークンで保護された Web アプリケーションにクロス サイト スクリプティングの脆弱性があると、セキュリティー トークンが盗まれ CSRF 攻撃が可能になります。幸いな事に Internet Explorer 8 には XSS フィルター やその他の機能 (英語) があり、CSRF を防ぐためのチャレンジ トークンの奪取に使われるであろう XSS 攻撃の防止に役立ちます。 昨秋、研究者である Robert Hansen 氏と Jeremiah Grossman 氏はクリックジャッキング (英語) として知られる、CSRFを可能にする第二の要素について公開しました。クリックジャッキングとは、ユーザーがそれと気づかずあいまいにされたか隠されたウェブ要素をクリックするように騙すのに使用される複数のテクニック (英語) を包含する用語で、一般に意図しない売買取引を生じさせます。効果的なクリックジャッキング攻撃は、ユーザーに取引の確認を求めて CSRF を防ごうとする仕組みを回避します。例えば、Cookie を認証に使い、ワン クリック購入ができる単純な Web ショップ (英語) について考えてみましょう。 悪意のあるサイト (英語) を Web 上のどこかに作成し、正当なショップから標的となるページを IFRAME によって引き出します。そしてフレーム内の重要な要素を紛らわしいテキストやイメージで覆い隠します。 ユーザーが騙されてしまい、Web ショップのページとは知らずにクリックするかもしれません。この時ユーザーがショップにログインした状態であった場合、意図しない注文が発生します。 明らかにこれは非常に単純なクリックジャッキング攻撃ですが、より洗練された種類の攻撃も存在しています。 クリックジャッキングに対してはさまざまな緩和策 (英語) が提唱されていますが、いずれの緩和策にも互換性やユーザー エクスペリエンスへの影響、既存の標準への大きな変更の必要性など、トレードオフとなる条件が付いています。現時点で、最も単純で最も広く利用されているクリックジャッキングを打ち破るためのメカニズムはフレーム バスティングと呼ばれるもので、攻撃されやすいページがフレーム内で表示されないようにする単純な動作をします。残念ながら典型的なフレームバスティング (英語) のメカニズムはスクリプトに依存しおり、その結果さまざまな方法で回避されてしまいます。 12 月初旬に他のブラウザー ベンダーへ開示したように、Internet Explorer 8 リリース候補版には攻撃されやすいページをフレーム内に表示させないよう宣言する事で Web アプリケーションがクリックジャッキングの危険性を軽減できる、新しいオプトイン のメカニズムを導入しました。 Web 開発者はページがフレーム内に表示されないよう制限するために、X-FRAME-OPTIONS という名前の HTTP 応答ヘッダーを HTML ページと共に送信できます。X-FRAME-OPTIONS の値に DENY トークンが含まれていると、そのページがフレームの中に含まれている場合に IE8 はページの表示を行いません。値に SAMEORIGIN トークンが含まれていると、X-FRAME-OPTIONS ヘッダーを含むページのオリジン サーバーとフレームのトップ レベルのコンテキストのオリジン サーバーが異なる場合に限り IE はページの表示を行いません。たとえば、http://shop.example.com/confirm.asp が DENY 指示子を含んでいると、親フレームの場所がどこであろうとそのページはサブフレームには表示されません。それとは対照的に、X-FRAME-OPTIONS ヘッダーに SAMEORIGIN トークンが含まれているページは、正しく http://shop.example.com をオリジン サーバーとするページのフレーム内に表示できます。 X-FRAME-OPTIONS のポリシーにより表示がブロックされた場合、制限の説明とフレームを新しいウィンドウで開くためのリンクが表示されたローカルのエラー ページが現れます。サブフレームではなく新しいウィンドウで表示されれば、コンテンツはクリックジャッキングの影響を受けません。 機微情報を扱うアンチ CSRF のページを保護するためにX-FRAME-OPTIONS 指示子を使う事で、Web 開発者は IE 8 のユーザーへの web アプリケーションを通じた攻撃をただちに軽減する事ができます。クリックジャッキングの脅威に対する互換性が高く展開しやすい軽減策として、X-FRAME-OPTIONS 指示子が他のブラウザーにも実装される事を期待しています。長期的に見ればセキュリティー研究者や Web 標準化組織は、ブラウザーで実装される Web アプリケーションのセキュリティー ポリシーの設計についての進化を続けると予想しています。彼らとともに、将来のクリックジャッキングへの防御を、将来のバージョンのブラウザーのより大きなセキュリティー ポリシー機能の文脈の中に形作る作業に携われる事を期待しています。 ありがとうございました。 Eric Lawrence プログラム マネージャー

 

ページのトップへ