JavaScriptのセキュリティ問題と対策

はじめに

　Web開発者としてのキャリアを積んでいくと、いずれはセキュリティ上の問題に遭遇するでしょう。JavaScriptの開発元は数多くの大きなセキュリティホールを見つけては解決してきましたし、ブラウザのベンダ各社は自らセキュリティホールを塞ぐ努力をし、ブラウザ操作のセキュリティを保証するための手段を追加してきました。JavaScriptには、それ自体にセキュリティのためのアプローチがいくつか用意されています。それぞれに長所と短所があるものの、全体として見れば、いずれもかなり成功しています。いくつかのセキュリティ機構はJavaScriptインタプリタに含まれており、またブラウザ自体に含まれているものもあります。開発を始めるときには、何らかのセキュリティ機構の実装が必ず求められます。セキュリティ上の問題点を考慮しておかないと、改竄という問題を招くことになります。これは実際に起こり得ることなので、放置してはいけません。開発時にセキュリティを軽んじると、そのWebサイト（およびそのWebサイトを公開している企業）は改竄の危険にさらされます。セキュリティホールのために危険度が高いという噂が立てば、そのWebサイトのコンテンツはユーザーに利用されなくなるでしょう。

　ブラウザはオペレーティングシステムにつながっています。つまり、ユーザーのコンピュータのファイルシステムは悪意あるユーザーのターゲットになり得るということです。JavaScriptを使ってユーザーのディレクトリリストにアクセスすることは完全に可能です。ハッカーはそのことを知っており、これを常套手段として利用しています。セキュリティはまずサーバから始まります。ユーザーはそこからコードをダウンロードし、自分のマシンで実行するからです。そのため、サーバをしっかり管理し、定期的に監視する必要があります。コードをクリーンにし、スレッドが外部アクセスにさらされないようにする必要があります。これは開発者の責任です。

　ユーザー側の責任としては、コンテンツを信頼して自分のマシンで実行するかどうかを判断することが挙げられます。コンテンツを信頼してスクリプトを実行するか実行しないかをユーザーが決められるという機能は、ブラウザに含まれる機能であり、ブラウザの環境設定やユーザー設定で指定できます。

フレームの問題

　インターネットで最初にフレームが実装されたとき、最初の重大なセキュリティホールの存在がハッキングコミュニティに知られるまでに丸2か月かかりました。フレームがどのように使われてセキュリティホールが生じたのかを理解するためには、まずフレームそのものを理解する必要があります。

　Webページでフレームが描画される手順は次のようになります。

描画するフレームについての命令を含んだページがロードされる。
フレームの描画方法を決めるアドレスと詳細（境界のプロパティやフレーム自体の配置など）がブラウザに与えられる。
フレームの内容となるドキュメントがフレームにロードされる。
ページがブラウザのウィンドウに描画（表示）される。

　この手順では、他のドメインの他のサーバからWebページをロードして実行することが可能です。あるドメインからのJavaScript変数を使って、Webページを構成する他のフレーム内で使用される他のドメインからのWebページに対する検査と修正を行うことができるのです。この問題に対処するための最初の方策は「同一生成元ポリシー（Same Origin Policy）」で、これはNetscape NavigatorとInternet ExplorerとOperaで採用されました。

同一生成元ポリシー：Internet Explorer方式のセキュリティ

　同一生成元ポリシー（Same Origin Policy）では、あるサーバから送られたJavaScriptコードが、別のサーバ、別のポート、または別のプロトコルから送られたドキュメントのプロパティにアクセスして元のサーバに情報を返すことは禁止されます。同一生成元ポリシーはHTMLドキュメント内の機能スクリプトの実行に不可欠なJavaScript要素に作用するものであり、HTMLドキュメントのすべての要素に作用するわけではありません。同一生成元ポリシーの対象となる（生成元検査をパスしなければならない）要素は次のものです。

document ― anchors、applets、cookies、domains、elements、embeds、forms、lastModified、length、referrer、title、URLの各メソッドおよびプロパティの読み書き。form要素の各インスタンスと、LiveConnectを通じてJavaScript関数で使用できるすべてのJava CLASSも検証されます。
image ― lowsrcプロパティとsrcプロパティ。
layer ― srcプロパティ。
location ― locationで使用できるすべてのプロパティ（ただしlocation.xとlocation.yは除く）。
window ― findプロパティ。

　一般的なJavaScriptスクリプトのほとんどの機能は、この生成元検査の対象になるプロパティやメソッドを少なくとも1つは使用しなければなりません。そのため、フレーム化されたウィンドウのスクリプトに悪意を持って変更またはアクセスすることはほとんど不可能になります。

　ときには、Webアプリケーションの目的を実現するために、あえて同一生成元ポリシーを犯さなければならないこともあります。この可能性に対応するために例外が設けられています。ページフレームの中に作成および表示されるページ内の情報にアクセスできるようにするには、document.domainステートメントを使って、そのWebアプリケーションが（ひいてはブラウザが）信頼できるドメインを指定します。例えば、「http://developer.walkthegeek.com」を生成元とするページから、「http://www.walkthegeek.com」を生成元とするページ内の変数とスクリプトエンティティにアクセスできるようにするには、関数内で次のステートメントを使用します。

document.domain = "walkthegeek.com";

　このようにしてdocument.domainプロパティを設定すると、ドメインwww.walkthegeek.comとwalkthegeek.comのすべてのサブドメイン（上記のdeveloper.walkthegeek.comなど）からのコンテンツをすべて信頼するようにブラウザに指示することになります。

データ汚染ポリシー：Netscape方式のセキュリティ

　Netscapeは、インターネットユーザーを保護するにはセキュリティを強化する必要があると判断し、既存のどんなセキュリティよりも強力な新しいタイプのセキュリティを導入しました。それが「データ汚染ポリシー（Data Tainting Policy）」です。データ汚染ポリシーは同一生成元ポリシーとクライアント（ユーザー）のコンピュータの設定を組み合わせたもので、その働きは同一生成元ポリシーとほぼ同じです。データ汚染ポリシーでは、他のドメインを信頼する権限と、別のサーバから提供されたページ内のJavaScriptの変数とオブジェクトにアクセスする権限を制御します。この機能は随意にオン／オフできます。基本的にデータ汚染ポリシーがオフなら、メッセージウィンドウがポップアップして、別のドメインから提供されたページ内のJavaScriptエンティティにはアクセスできない旨が通知されます。

　データ汚染ポリシーはオペレーティングシステムの一部なので、ブラウザからオン／オフすることはできません。各種オペレーティングシステムでデータ汚染ポリシーを有効にする方法は次のとおりです。

Windowsの場合：NS_ENABLE_TAINT=1 ― Windows 3.1X、95、98、NTについてはautoexec.batファイルにこのステートメントを挿入します。Windows NTの場合、Data Taintingをユーザー環境変数として設定することもできます。
UNIXの場合：NS_ENABLE_TAINT=1 ― 使用するUNIXシェルによって違ってきます。基本的にはset envまたはenvコマンドを使って環境変数を設定します。
Macintoshの場合 ― Navigatorアプリケーション自体のタイプenviおよび128のリソースを編集して、NS_ENABLE_TAINTステートメントの前の2つのスラッシュを削除します。NS_ENABLE_TAINTステートメントはドキュメントの終わり近くにあるはずです。
OS/2の場合：NS_ENABLE_TAINT=1 ― 起動ドライブのルートにあるconfig.sysファイル内にこのステートメントを設定します。

　データ汚染ポリシーが作用するのはNetscape Navigatorのみです。データ汚染ポリシーは同一生成元ポリシーとほぼ同様の働きをします。つまり、すべてのページ要素の生成元がテストされるわけではなく、次のようなJavaScriptスクリプトに必須の部分だけがテストされます。

document ― cookie、domain、lastModified、links、referrer、title、URLの各プロパティ
form ― form要素のすべてのインスタンス
history ― current、next、previous、toStringの各メソッドおよびプロパティ
link ― hash、host、hostname、href、pathname、port、protocol、search、toStringの各メソッドおよびプロパティ
location ― hash、host、hostname、href、pathname、port、protocol、search、toStringの各メソッドおよびプロパティ
option ― defaultSelected、selected、text、valueの各メソッドおよびプロパティ
plugin ― nameプロパティ
window ― defaultStatus、name、statusの各メソッドおよびプロパティ

　上記のすべてについて生成元がテストされます。taintEnabled()メソッドを使用すると、データ汚染ポリシーが有効になっているかどうかをテストすることができます。このメソッドは、データ汚染ポリシーが有効ならばtrueを返し、有効でなければfalseを返します。テスト対象にするスクリプト要素を指定することもできます。なお、データ汚染ポリシーはバージョン1.1以前のJavaScriptでしか使用できないことに注意してください。バージョン1.2以降のJavaScriptでは、データ汚染ポリシーとは違うタイプのセキュリティが使われています。それが次に説明する「署名付きスクリプト」です。

署名付きスクリプト

　署名付きスクリプト（Signed Scripts）は、クライアント（ユーザー）のコンピュータに関する、ある特定の重要情報にアクセスするために使用されます。署名付きスクリプトはLiveConnectとJava Capabilities APIを使って、この重要情報にアクセスします。このモデルでは、外部JavaScriptファイルにセキュリティ証明書で「署名」することができます。セキュリティ証明書は指紋に似ており、開発者や開発者の組織に固有のものです。セキュリティ証明書はNetscapeのPage Signerツールを使って作成できます。このツールはhttp://developer.netscape.com から無料で入手できます（編集部注：2009/02/26時点でリンク切れになっています）。Site MapでToolsを選択してください。

　NetscapeのPage Signerツールを使用すると、独自のオンラインセキュリティIDを作成できます。このツールはセキュリティ証明書とコードの両方が含まれたJAR（Java Archive）ファイルを作成します。ドキュメント内にARCHIVE属性が設定されたHTML SCRIPTタグがあると、ブラウザはコードを実行する前に検証を行います。アラートボックスがポップアップするので、ユーザーはスクリプトの実行を許可するか拒否するかを選択できます。スクリプトが外部.jsファイル内ではなくドキュメント内に含まれている場合、JARファイルにはセキュリティIDだけが含まれますが、やはりARCHIVE属性を使ってアクセスされます。

　ユーザーがスクリプトの実行を許可または拒否できるようにしたことで、Netscapeはユーザー判断によるセキュリティという新たなセキュリティレベルを実現しました。これは頻度が高すぎるとユーザー側の負担になるという意見もあります。つまり、どの領域のスクリプトを実行してよいかとブラウザがたびたび質問してくるので、ユーザーにとって煩わしく感じられるということです。どの領域のスクリプトに対して許可／拒否のアラートボックスを出すかは、netscape.security.PrivilegeManager.enablePrivilege()というJavaメソッドを使って設定します。開発者がユーザーに確認を求めるために使用できるオプションは次のとおりです。

UniversalBrowserAccess ― ブラウザでの特権データの読み取りと書き込みを許可します。
UniversalBrowserRead ― ブラウザでの特権データの読み取りのみを許可します。ブラウザ内でDragDropの値を取得したり、historyオブジェクトを使用したりするときに必要です。
UniversalBrowserWrite ― ブラウザでの特権データの書き込みのみを許可します。eventオブジェクトのいずれかのプロパティを使用したり、ブラウザのコンテンツバー（ステータスバーやメニューバーなど）のいずれかを追加または削除したり、スクリプト内でwindowオブジェクトの値を設定したりするときに必要です。
UniversalFileRead ― ユーザーのコンピュータのファイルシステムの読み取りを許可します。fileUpload()メソッドを使用するときに必要です。
UniversalPreferencesRead ― スクリプトによるブラウザの環境設定の読み取りと報告を許可します。
UniversalPreferencesWrite ― スクリプトによるブラウザの環境設定の変更を許可します。
UniversalSendMail ― スクリプトによるユーザーの名前を使った電子メールの送信を許可します。スクリプト内でnews:またはmailto:属性を使用するときに必要です。

　それぞれの方式の長所と短所についてはお分かりいただけたかと思います。Microsoft Internet ExplorerとNetscape Navigatorという2つの主要なブラウザはそれぞれ異なるセキュリティ基準を備えています。Internet Explorerでは同一生成元ポリシーを使用しており、Netscapeでは署名付きスクリプトを使用しています。どちらにも、それなりの良さがあります。セキュリティを実施しようとすると分かりますが、苛立たしいのは両者が非常に異なっていることです。それぞれでまったく異なるディレクトリパスが必要になることもあり、ブラウザごとに違った作業を強いられるので、セキュリティ作業が実質的に2倍になります。

まとめ

　本稿によって、ユーザーが遭遇する可能性のあるセキュリティ上の問題への理解と、JavaScriptコーディングに関する問題の回避方法への理解が進むことを願っています。コーディングを行う際には、本稿で取り上げた潜在的なセキュリティ上の問題に注意を払ってください。同一生成元ポリシー、データ汚染ポリシー、および署名付きスクリプトは、そうしたセキュリティギャップを埋めるのに役立ちます。

著者紹介

Thomas Valentine（Thomas Valentine）