高木浩光＠自宅の日記

■ 「NoScript」をやめて「RequestPolicy」にした

セキュリティ屋が、Firefoxユーザに「NoScript」の使用を推奨することがしばしばあるが、私は賛同しない。

• JPCERT/CC、技術メモ「安全なWebブラウザの使い方」を公開, INTERNET Watch, 2008年11月4日 *1
• 技術メモ − 安全なWebブラウザの使い方, JPCERT/CC, 2008年11月4日

  IV. 各 Web ブラウザに共通する設定上の注意事項

  1. スクリプト等の実行を制限する

  JavaScript 等のスクリプトや（略）は（略）Ajax に代表されるインタラクティブなインターフェースが実現できるなど、高い利便性が得られます。反面、PC 上の重要なファイルを削除・変更するなど、悪意を持った処理が行われる可能性もあります。従って無制限にスクリプト等を実行できるようにしておくのはセキュリティ上好ましくありません。
 これらの機能は原則無効とした上で、信頼できる Web サイトでのみ限定的に有効とする等、一定の制限を加えた上で実行できるようにすべきです。

• 「Firefoxを使い続けるための“お勧め”設定」，NoScriptを組み込んでいないFirefoxは使用停止に, 山下眞一郎, 日経IT Pro, 2008年4月28日

これらの解説が駄目なのは、Webの仕様（本来あるべき姿）と脆弱性の存在（ある時点での現実）とを区別せずに説明しているからだ。Webの仕様では、JavaScriptは安全であり、常時オンでかまわない。そのように設計されている。危険があるとすれば、何らかに脆弱性が存在していて、修正していないときである。「何らか」とは、JavaScript自体に脆弱性が見つかる場合もあるが、Flash PlayerやAdobe Readerなどに見つかった場合もそうである。

それなのに、JPCERT/CCは、まるでJavaScriptはいつでも「ファイルを削除・変更」できるものであるかのような虚偽の解説をしている。

ある脆弱性が発見されてパッチがまだ出ていないときに、回避策としてJavaScriptのオフが紹介されることがよくあるが、それはその脆弱性についての回避策（の一つ）であって解決策ではない。そこを混同させて語るのはやめてもらいたい。

本来なされるべき（想定される読者への）解説は、まず、(1)脆弱性がないならばそのままどう使ってもよいはずであるという原理を説明した上で、(2)脆弱性が見つかることがあるのでブラウザやプラグイン更新を怠らないようにし、そうしていれば（未知の脆弱性あるいは未修正の脆弱性がない限り）何も起きないことを説明し、そこに加えて、(3)それでもなお未知・未修正の脆弱性を突いた攻撃が発生しているので、それを警戒するならばこれこれの回避策や対策があると、そのように前提を明確にしながら順序立てて説明するべきである。それができないのはプロ失格だろう。

そして、上記(3)の対策として「NoScript」などを紹介するにしても、一般のユーザたちにそれを使いこなせるのかという現実の問題がある。私も「NoScript」を使ってきたが、とても普通の人たちに使いこなせるような代物ではない。無駄に手を煩わせたあげく、本当に安全性が向上するのかさえ疑問だ。結局この手の解説をする人たちというのは、自分のやり方を他人にも押し付ける独り善がりなマニアでしかない。

思い起こせば、2001年ごろには、JavaScriptを使用しているサイトを糾弾するという、滑稽な人たちもいた*2。

• スクリプト強要する企業サイト一覧　危険なサイトに「R-MSマーク」を, ScanNetSecurity, 2001年11月12日
• 利用者を危険に陥れる「管理者ごっこ」「web 制作者ごっこ」 R-MS サイトの脅威, ScanNetSecurity, 2002年2月12日

この糾弾を掲載していたサイト自身、2004年にリニューアルした際にJavaScriptを使うようになり、自分で自分を「R-MSサイト」と認定してロゴを貼るというみっともないことになっていた。（その後もずっと貼られたままだったが、再度のリニューアルのときにロゴは外されたようだ。）

私はこういう考え方に賛同したことはない。

とはいえ、自分用には「NoScript」を使っていた。立場上、怪しげなサイトでも見に行かなければならないし、「NoScript」がどのように動作し、どのような効果をもたらすかを把握しておく必要があるからだ。

しかし、先日のNoScript作者がひき起した騒動を契機に、他に代替できるものはないかと探してみたところ、「RequestPolicy」という拡張機能を知った。これは、JavaScriptをブロックするのではなく、ドメインをまたがって参照している（same-originでない）インラインコンテンツ（Webページ中に埋め込まれた画像やフレーム、Flash、JavaScript等）をブロックするものである。1か月近くこれを試用してきて、「これでいいんじゃないか」「NoScriptじゃなくてもいいんじゃないか」と思うようになった。

正直、「NoScript」を使っていたときは、かなり多くのサイトでJavaScriptを許可する必要があって煩わしかったのだが、「RequestPolicy」ならば、そのまま動くサイトもけっこうある。JavaScriptが禁止されているわけじゃないからだ。

では、闇雲にJavaScriptオフを語っていた人達は、これに納得するだろうか。

そもそも、彼らはなぜ脆弱性回避のためにJavaScriptをオフにするのか。それは、攻撃者がJavaScriptを攻撃手段に使っているのを目にしたという安直な発想からではないのか。手段に使われているからといって、それが原因とは限らないのにだ。原因がFlashなどのプラグインの方にあるなら、JavaScriptを使わない攻撃方法もあり得るのであるし、それを別の方法で止めるなら、JavaScriptを止める必要がない。

昔は、JavaScript自体が原因の脆弱性も多く発見されていた。same-originポリシーを破ってcookieを盗めてしまう脆弱性や、ローカルファイルにアクセスできてしまう脆弱性が、Webブラウザに頻繁に発見され、長期間放置されることもあった。しかし、最近は少なくなってきているように思うし、ローカルファイルにアクセスできる脆弱性はあまり見ないようになった。今問題になっているのは、それ以外（プラグインやActiveXコントロールなど）の脆弱性が主ではないだろうか。

つい先日にも、JPCERT/CCが「JavaScript が埋め込まれる Web サイトの改ざんに関する注意喚起」などという文書を流していたが、「JavaScript が埋め込まれる」というのは事の本質ではなかろう。JavaScriptで誘導される「別のWebサイト」に根源となるものが仕掛けられているのであって、JavaScriptはそれを起動する手段にすぎない。

サイトを改竄してIFRAME等で「別のWebサイト」を埋め込むことにより、正当なサイトを訪れたブラウザに対し（プラグイン等の）脆弱性を突こうとする攻撃が流行っているわけだが、「RequestPolicy」はそのような別のWebサイトのコンテンツをブロックしてくれる。リダイレクトもブロックしてくれる。

もちろん、攻撃者がサイトを改竄する際に、攻撃用コードも同じサイトに置いて罠を仕掛けた場合には、「RequestPolicy」はそれをブロックしてくれないが、それはJavaScriptを止めただけでも同様にブロックされない。それを警戒するならば、別途、「Flashblock」などを併用するのでもよいし、無用なプラグイン（Adobe Readerや一太郎ビューア等）は止めることになるだろう。

「NoScript」はFlash等のブロック機能も備え、さらには、Webサイトのクロスサイトスクリプティング（XSS）脆弱性を突くアクセスもブロックしようと試みたり、Clickjackingの問題への対策方法を提示しようとしたり、総合セキュリティ対策ソフトの様相を呈してきていたが、私は、そういうのはそれぞれ別々の拡張機能で提供されるのがスマートだと思うし、頻繁にアップデートされて、いつどんな変更がなされるのかわからないことも不安材料になっていた。

JPCERT/CCは公式な文書で「NoScript」の使用を推奨しているわけだが、一人の個人の意思でどうとでも変わってしまうようなソフトウェアを、セキュリティの目的でJPCERT/CCが推奨するというのは、いかがなものか。

もっとも、「RequestPolicy」でもそれは同じであるし、やはり、一般の人達に推奨できるほど、簡単に使いこなせるものでもない。

ただ、ブロックされたコンテンツの認識とその解除にあたって、「NoScript」よりは「RequestPolicy」の方がわかりやすいように思った。「RequestPolicy」でブロックされるその多くは、広告やブログパーツなどで、見なくてもかまわないものであることが少なくないし、見たいものが出ないときは、ブロックされていることがよくわかる。（「NoScript」によるJavaScriptのブロックの場合は、中途半端に機能がなくなったりして、何が起きているのかよくわからないことが多い。）

YouTubeなどを埋め込んだページや、はてなブックマークの「○○ users」の画像なども、デフォルトでは全てのサイトでブロックされてしまうが、ステータスバーのメニューから「Allow requests to hatena.ne.jp」を選ぶことで、信用性の高い（はずの）サイトについて全サイトからの参照を許可してしまえば、その後はそのまま使うことができる。これを必要とするサイトは、そう多くはない。

一方、「Allow requests from example.jp」は滅多に使わない方がよい。これを許可してしまうと、そのサイトが改竄されたときに対策がパアになる。面倒でも、個別に「Allow requests from example.jp to example.com」でひとつひとつ許可して使う。そうすれば、攻撃者がexample.jpを改竄したとしても、example.comも同時に改竄しない限りこの対策はパアにならない。そうして少しずつ許可を積み重ねた設定は、図1のようになる。

図1：「RequestPolicy」の設定例

これですべてのゼロデイ攻撃が回避できるわけではないが、それは「NoScript」でも同じことだ。「NoScript」よりは、対策がパアになるような設定をしてしまうことを避けやすいのではないかと思う。「NoScript」で普段使うサイトのJavaScriptを許可に設定してしまうと、そのサイトが改竄されたときに対策がパアになる。JPCERT/CCの「技術メモ − 安全なWebブラウザの使い方」は、「NoScript」の使い方について、「実行する必要があるサイトでのみ一時的に許可することが望ましい」と説明しているが、普段訪れて使うサイトが改竄されて被害に遭うのを防止しようとしている話なのに、いったいどうしろというのか？

一般の人にまで推奨できるものではないが、それなりにWebを使いこなす人ならば、「RequestPolicy」を使ってみることで、今時のWebサイトがどんな構成になっているのか知るのにも役立つだろう。1つのドメインで完結しているサイト（デフォルト設定のまま動く）もあれば、スタイルシートを外部ドメインからロードしているためにデフォルト設定では画面が崩れてしまうサイトもあるし、やたらめったら大量の外部サイトを参照しまくってうざいサイトもあることに気付く。

セキュリティ屋は、一つ覚えのようにJavaScriptオフと唱えるのではなく、そもそも何のためにそうするのかから考えてみてはどうか。