Hebikuzure's Tech Memo

2009年8月1日

宣言型セキュリティー

Filed under: Internet Explorer — hebikuzure @ 8:32 AM

Declaring Security
http://blogs.msdn.com/ie/archive/2009/06/25/declaring-security.aspx


月遅れになってしまいましたが、まだまだ続けています。もう少しピッチを上げたいのですが….。

以下の文章は IE Blog の 6/25 の記事 Declaring Security を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


宣言型セキュリティー

最近、多くの人から Mozilla の Content Security Policy ドラフト仕様についてどう思うか訊ねられますが、既に 1 月の時点で私は CPS が良いアイデアだと考えている事を公言しています

CPS は宣言型セキュリティーのメカニズムで、これによりサイトは自らの意図を伝えてユーザー エージェントにそれをどのように実現するかの決定を委ねます。

宣言型のセキュリティー メカニズムには多くの利点があります:

  1. 互換性リスクの軽減。サイトはオプトインを必要とした上で、必要な制限であればどのような物でも、互換性の副作用の少ない新しいセキュリティー機能をユーザー エージェントに対して宣言できるからです。
  2. 明確な意図。どのような制限が望まれるのか明確に宣言する事により、ブラウザーはサイトの意図を “当て推量” する必要がなくなります。例えばフレーム ブレイク JavaScript はクリックジャッキングを防ぐためには信頼が置けない事について説明する場合、Kymberlee が示しているように:

    セキュリティー脆弱性を防ぐための設計を行わないのであれば、偶然にうまく機能するという見込みは持てません。

    宣言型セキュリティーの機能はそれ自身セキュリティー上の脅威を軽減するようデザインされていますから、ブラウザーは必要であればどのような制限も実装できますし、無関係の機能を意図せず損なうことなしに制限の抜け穴を修正できるでしょう。

  3. ユーザビリティー。サイトに自身のセキュリティー ポリシーを宣言させる事により、ブラウザーはユーザーに代わっていろいろなセキュリティー上の判断を行う事ができます。
  4. 監査能力。ポリシーのためにコンテンツをスキャンし、発行組織の期待に合致しているか判断するようなツールを作成するのは難しくありません。

Internet Explorer はこの領域で華々しい歴史を有しています: HTTPOnlySECURITY=RESTRICTED フレーム、X-Content-Type-OptionsX-Frame-Options などはすべて IE で最初に実装された宣言型のセキュリティー メカニズムで、現在他のブラウザーでもさまざまな程度でサポートされています。

CPS の背景としているアイデアは新しい物ではありませんし、BEEP から HTML5 サンドボックス に至る、宣言型セキュリティーの数多くの提案の一つに過ぎません。

宣言型セキュリティーのメカニズムは意義深い物ですが、同時に課題も抱えています:

  1. プラグイン。明確に無効にされていない限りでは、プラグインはセキュリティー ポリシーを留意し執行するでしょう。プラグインは数多くの異なるベンダーから提供されるので、この要件は現実的な展開では難しいと考えられます。
  2. 不適切な構成。CPS の有効性は開発者や管理者が構成したポリシーと同じだけしかなく、多くの主要なサイトには不適切な構成による欠陥が存在しています。Ira Winkler は、政府の研究によるとコンピューターへの侵入の 70% は構成の問題の結果であると主張 [p143] しています。
  3. 新規の攻撃対象領域。CPS を実装するのに使用されるメカニズム自体がハッカーにより徹底的に調査されるでしょうから、攻撃対象領域が追加されるのを防ぐには包括的なファジー テストとペネトレーション テストが必要となるでしょう。その上、攻撃者が所与の user-agent で所与のポリシーを回避できるような抜け穴が見つかれば、– 他のuser-agent がそのポリシーをサポートしようとしていなくとも — その user-agent の評価は損害を受けるでしょう。
  4. デバッグの容易さ。Web 開発者は既に Web ページの開発で相当な量の課題に直面しており、新しいセキュリティー ポリシーを導入すると、どのような場合にセキュリティー ポリシーによってコンテンツがブロックされるのかを明確に示せるようツールを更新する必要があるでしょう。サイトに誤って過剰な制限のポリシーを設定してしまうかもしれず、包括的なテストでミスを発見できなければ、ユーザー エクスペリエンスは混乱するでしょう。
  5. 動的なコンテンツ。実行可能なポリシーを (例えば電子メールの作成やブログの編集などのような) 動的コンテンツのシナリオに対して作成する事は、ユーザーが最初に表示された元のページにどのようなコンテンツを追加するか Web 開発者にはわからないので、困難である事が明確になるでしょう。
  6. 採用。CPS やその競合する提案の最大の課題は、これらが “既定では無効” のセキュリティー機能を提案している事実に関連しています。これは互換性にとって素晴らしい事ですが、サイトやユーザーを保護するという点ではそれほど素晴らしくはありません。なぜならこの機能の恩恵は、Web 開発者がサイトをアップデートした後にのみ受けられるからです。CPS が成功するには、簡単さ/分かりやすさに対する効力/柔軟性のバランスを取る必要があります。

包括的な防御のための万能のセキュリティー技術は存在しないので、ブラウザーは次の両方を提供すべきだと思います:

  1. サイトが XSS 攻撃を防ぐことのできるリッチなセキュリティー API。
  2. ただちに、あるいは永遠にコードを更新する事ができない、あるいは更新したくないサイトを保護する自動的な防御。

XSS 攻撃と戦うため、IE8 では多くの攻撃対象領域の削減を行い、いくつかの 新しい API や前述の宣言型セキュリティー メカニズム (X-* ヘッダー) を導入しています。しかしながら、私たちは Web サイトがただちにこれらの API や宣言型セキュリティー機能を採用する訳ではない事を理解しており、そのため既定で有効で、やーザーに確認なしの、コード変更を必要としないメカニズムである XSS フィルターを作成しました。これは現行の多くの一般的な XSS 攻撃の軽減に有効です。

私は CPS が発展する事を切望しており、この技術は増大しつつある数多くのネット上の脅威に対して Web サイト自身がセキュアになるのに役立つ、有望なアプローチであると確信しています。CSP ドラフト仕様へのフィードバックは、Mozilla の Talk page を使って行えます。

-Eric Lawrence

広告

コメントする »

まだコメントはありません。

RSS feed for comments on this post. TrackBack URI

コメントを残す

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

WordPress.com ロゴ

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

Twitter 画像

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

Facebook の写真

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

Google+ フォト

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

%s と連携中

WordPress.com Blog.

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