<前の日記(2009年05月24日) 次の日記(2009年06月07日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 335   昨日: 2980

2009年05月31日

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

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

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

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

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

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

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

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

この糾弾を掲載していたサイト自身、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オフと唱えるのではなく、そもそも何のためにそうするのかから考えてみてはどうか。

*1 この記事へのはてブコメントにも書いていたように、JPCERT/CCのこの文書は他にもいろいろとおかしい。水無月ばけらのえび日記でも批判されていたが、SSL 2.0について「あらかじめ無効化しておく注意が必要」などと言っているが、べつに必要じゃない。著者は、SSL 2.0を有効にしておくことの何が問題なのか正しく理解していないだろう。

*2 「JavaScript非対応ブラウザでも正しく表示されるようにしよう」という運動は正当だが、それとは違っている。

本日のTrackBacks(全100件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20090531]

* 高木浩光@自宅の日記 - 「NoScript」をやめて「RequestPolicy」にした - http://takagi-hiromitsu.jp/diary/20090531.html#p01 &gt;&gt; 広告やブログパーツなどで、見なくてもかまわないものであることが少なくないし、見たいものが出ないときは、ブロックされている....

高木浩光@自宅の日記 - 「NoScript」をやめて「RequestPolicy」にした

「NoScript」がいいか「RequestPolicy」がいいかはともかくとして
セキュリティ屋..

検索

<前の日記(2009年05月24日) 次の日記(2009年06月07日)> 最新 編集

最近のタイトル

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|
<前の日記(2009年05月24日) 次の日記(2009年06月07日)> 最新 編集