RSS

IEBlog: Using Frames More Securely

31 5月

こんにちは。
溜めてた IEBlog 記事も 5月分はコレが最後。
(看護休暇に入っていたので、Up が遅れました。。。6/15)

さて、今回は、IE8 の新機能である Cross Domain Request (XDR)、Cross Document Messaging (XDM) に関係してくるインライン フレームにまつわる話です。
IE8 で XDR, XDM を採用した裏には、こういう経緯がある、という感じでしょうか?
書いているのは、Eric Lawrence で IE7 の時にいくつものスペックに対する質問に親身に回答をしてくれた、私の最も信頼する
PM の一人です。(HTTP デバッガーの Fiddler なんかも作ってます。ブラウザの通信状況やヘッダーなんかを確認するのに重宝しています。。。) Beta Program などの Newsgroup や Chat で彼から回答がもらえたらラッキーだと思いますよ。

6 月に入ったら、Chris Wilson が書いた Compatibility and IE8 からスタートできるようにしよう。。。

—————————————————

Friday, January 18, 2008 3:25 PM

Using Frames More Securely

HTML frames (FRAMESETs や IFRAMEs) は、ひとつの画面に複数のページからのコンテンツを表示させるための機能で、最近のほとんどのブラウザに搭載されている機能です。歴史的には、frames は本来ページの部分的な更新を実現するために使われていて、ページのナビゲーションはひとつのフレーム内にあり、ページコンテンツは他の(フレーム) に存在してました。 時が経ち、フレームの利用は、広告や mashup,  や AJAX 用途に拡張されてきました。 現在、大多数の最近の Web サイトは様々な理由でこの IFRAMEs を使っています。

セキュリティの観点から、フレームは異なるソースから提供されるコンテンツ間を隔離することによって、Web アプリケーションのセキュリティを高めることができる。例として、 Web メール アカウント (http://mail.example.com) が HTML E-メールを IFRAME (http://untrusted.example.com/getmsg?msgid=1234) 内でレンダリングすることを選択するような時、mail.example.com から提供された Web メールアプリケーションのコンテキスト内にあるHTML メールの中のどんなスクリプトも実行できません。その代わり、"untrusted.example.com" ドメインのコンテキストの中であればすべてのスクリプトは実行できます。この分離は Web メールの UI 書き換えや、ユーザー証明書やcoolies のリークや、他のメッセージの Snooping などを未然に防いでくれます。

Internet Explorer 6 やそれ以降におけるフレームのレンダリングについては、フレームのセキュリティ属性の値を "restricted" にすることで、強化することができます。 そのようにすることで Internet Explorer にフレーム コンテンツを、それらのソースを気にすることなく、制限付きサイト セキュリティ ゾーン 内でレンダリングすべきコンテンツとして扱わせることができます。 制限つきサイトゾーンで動作するフレームでは、スクリプトの実行や ActiveX コントロールの発動、他のサイトへのリダイレクトなどができなくなります。 これらのテクニックは、(上記の Web メール シナリオの場合のように) そのフレームのコンテンツが信頼できるかどうか推測できないような場合に、特に便利です。

しかしながら、HTML フレームはセキュリティにおける万能の解決策でないことを理解することが大事です。 セキュリティを保つために、他の Web サイト コンテンツを含むフレーム内の Web サイトは、他の Web サイトを悪意のないものとして一般的に信頼しなければなりません。 さもなければ、多くのセキュリティの脅威が露出することになります。

例えば、2 つの IFRAME (: 1 つは広告を表示させるために使い、もう 1 つはHTML メールを表示させる) を含む Web メールアプリケーションのことを考えてみよう。

<iframe src="http://ad.example.com/rand/1234.aspx&quot; security="restricted"></iframe>
<iframe src="http://untrusted.example.com/getmsg?msgid=1234&quot; security="restricted"></iframe>

もっとも良いケースでは、利用者に対し Web メールのページから悪意のあるサイトにナビゲートするようなスクリプト (e.g. <SCRIPT>window.location="http://evil.example.net/malice.htm"</SCRIPT&gt;) を含ませることができないように保障するために、HTML メールまたは広告に両方のフレームが SECURITY="restricted" 属性と一緒に記述されることです。

ユーザーは、メール フレームには信頼性が疑わしいコンテンツが含まれている可能性があることを認識しています。(なので) メールにフィッシング攻撃または他の悪意のあるコンテンツが含むかもしれないような場合、ユーザーは Web メールアプリケーションそのものの一部のそのようなコンテンツを見落とすようなことはありそうもありません。 対照的に、広告のケースでは、コンテンツの内容が広告であることを示している IFRAME まわりに徴候がない限り、ユーザーに安全でない行動を取らせることができました。 例えば、広告バナーは、Web メール のユーザーインタフェースにマッチさせたり、システムの供給停止を示すテキストを含めたり、ユーザーに名前とパスワードを対象のアドレスへメールするように作成することができます。 ユーザーはたぶんそのコンテンツを Web メールアプリケーションからの信頼できるメッセージとして勘違いしてしまい、安全でない操作をおこなってしまいます。

よって、Web 開発者のフレームを使う際のベストプラクティスをまとめると以下のようになります:

  • できる限り、知られていない/信頼できないサイトからのコンテンツをフレームに含ませない。
  • できる限り、IFRAME における特権的なコンテンツを排除するために、SECURITY="restricted" 属性を使う。
  • まだユーザーに対して (フレーム内のコンテンツが信頼できるかどうか?) 明らかにされていないのであれば、すべてのフレームに対して (ユーザーに) 信頼できないコンテンツを含むことを明示すべき。

Eric Lawrence
Program Manager

edit: adjusted quotes around "restricted"

広告
 
コメントする

投稿者: : 2008-05-31 投稿先 Internet Explorer

 

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

 
%d人のブロガーが「いいね」をつけました。