Silverlight 5のセキュリティ

作者 Jonathan Allen , 翻訳者 徳武 聡 投稿日 2012年1月9日

セクション

デベロップメント

トピック

Silverlight ,

.NET ,

RIA ,

プログラミング ,

セキュリティ

共有 |

原文(投稿日：2012/01/04)へのリンク

Silverlightの役割はあまり理解されてこなかった。当初はFlashと競合するものだと思われていたが、今ではFlash自体がHTML5に置き換えられつつある。また、クロスプラットフォームのアプケーションの実行環境だと見なされていたが、AppleのiOSに関するポリシーのおかげで見込みがなくなった。現在、Silverlightは驚くべきことに企業内のビジネスアプリケーションのようなWPFが使われそうな領域で盛んに使われている。Silverlight 5のセキュリティモデルのアップグレードもこのような使われ方を考慮している。

Silverlight 2は事実上の最初のバージョンと見なされていたが、開発者が従来のスタイルのアプリケーションを配布する方法を要求し始めるまでは普及しなかった。“out-of-browser”またはOOBと呼ばれるこの機能はSilverlight 3で初めて実現した。しかし、この機能がリリースされる以前から、COMへアクセスできるようにしてほしいという要望が現れていた。しかし、周知の通り、セキュリティを考慮すればブラウザ内でCOMにアクセスするのはとても危険だ。結局、Microsoftはこの要望を聞き入れ、Silverlight 4ではOOBアプリケーションの場合だけ、COMへアクセスできるようにした。

一度COMを使えるようになると、Silverlightの開発者はさらにOSの深い部分へアクセスできるよう求めた。そして、ブラウザ内で動作するアプリケーションの場合もCOMへアクセスできるようにしてほしいという要望も現れた。Silverlight 5にはp/invokeがあり、完全に信頼されたアプリケーションをブラウザ内で実行できる。このようなSilverlightを企業アプリケーションの技術だと言っても見当違いではないだろう。大胆な意見だと思うかもしれないが、下記のSilverlight Security Overviewの文章を読めばわかる。

ブラウザ内の信頼されたアプリケーションはブラウザ外の信頼されたアプリケーションと同様にファイルシステムへのアクセスやCOMの呼び出しのような特権を持ちます。ブラウザ内で信頼されたアプリケーションを実行する場合、そのアプリケーションは信頼された発行元リストの中にあるキーで署名されている必要があり、企業環境のグループポリシーに従わなければなりません。ユーザ自ら許可を設定することはできません。

“信頼された発行元”になるのは単にコード署名証明書を購入するだけでは済まない。証明書をリストに追加するためには手動でインポートして、マイクロソフト管理コンソールのスナップインを使って証明書をインストールする必要がある。このコンソールにはショートカットがない。コマンドラインから起動しなければならない。

また、Silverlight 4のアプリケーションは管理者権限のアクセスは制限されていたが、Silverlight 5ではこの制限も撤廃されている。

Silverlight 5は管理者特権を排除しません。Silverlight 4の場合アプリケーションが管理者権限で実行されたら、Silverlightは制限された第2のプロセスを起動して元のプロセスを終わらせることで管理者特権を排除します。この制限された許可はWindows Vistaなどのユーザアカウント制御(UAC)に似ています。Silverlight 5ではこの仕組みを除外して普通のOSのルールに従います。アプリケーションが管理者権限で起動されたら管理者特権を持つアプリケーションとして実行し、管理者権限で起動されなかったら管理者特権のないアプリケーションとして実行します。

コード署名

インターネットでSilverlightアプリケーションを配布している場合、信頼されたアプリケーションに関する設定を無視できるが、それでもセキュリティ上考慮しなければならない点は多い。MicrosoftはSilverlightアプリケーションはすべて署名することを第一に推奨している。“認証機関(CA)が発行した署名を使えない場合は、最低でもアプリケーションに自己署名をしてアプリケーション更新時の中間者攻撃に備えましょう。”

リホスティング

Silverlightの主要なリスク要因のひとつがリホスティングだ。攻撃者は“フィッシング”サイトを作ってあなたが作ったSilverlightアプリケーションをホストする。そして、その偽サイト来るサービス呼び出しからユーザ名やパスワードを盗んでしまう。

この攻撃を受けるリスクを減らす方法のひとつはアプリケーションがどのページで起動されたのかをチェックすることだ。そのアプリケーションが正しいドメインから来たのでないのなら、アプリケーションを起動しない方がいいだろう。

クロスサイトスクリプティングとページ/アプリ信頼

デフォルトではSilverlightはクロスサイトスクリプティングに対して脆弱性はない。しかし、XamlReader.LoadやAssemblyPart.Loadを呼び出すクスリプト実行可能な関数がある場合には脆弱性が生まれてしまう。ScriptableMemberAttributeを使ってタグ付けされている関数はすべてJavaScriptから呼び出せるので、脆弱性の観点から慎重にレビューした方がいい。

また、ページ上のJavaScriptを実行するSilverlightアプリケーションから脆弱性が生まれる可能性もある。この場合は<object>タグのEnableHtmlAccessプロパティを可能な限りfalseにすることである程度防げる(ページとアプリケーションが違うドメインの場合はデフォルトでfalseになっている)。

直接のサービス呼び出し

アプリケーションが使うサービスへの攻撃は見落とされやすい。WCFには正しいアプリケーションからのウェブサービス呼び出しかどうかを判断するための信頼できる方法がない。したがって、すべてのサービス呼び出しが潜在的に悪意があるものだと仮定してクライアント側と同じバリデーションをサーバ側でも実装する必要がある。