高木浩光＠自宅の日記

■ Bluetoothの異常な大量検出、シャープ製に原因

間があいてしまったが、3月9日の日記の件について、その後わかったことを書いておく。

シャープ社製ソフトバンクモバイル端末のデフォルト設定

3月9日の日記で、「デフォルト設定で有効かつ検出可能としている」と書いたが、それは誤りだった。自分が持っているシャープ製のソフトバンクモバイル端末「816SH」で、設定の初期化（出荷時設定へのリセット）をしてみたところ、デフォルトで検出可能設定（「デバイスの公開」がオン）であるが、Bluetooth機能全体はデフォルトではオフになっていた。

それなのになぜ、Bluetoothをオンにしている人がソフトバンクのシャープ端末だけで多いのかについて、はてなブックマークコメントで「ちかチャットとか対戦ボンバーマンを起動すると青歯Onにされる」という指摘があった。

自分の816SHで確かめてみたところ、たしかにその通りだった。以下にそれを確かめた様子を示す。

816SHでは「神経衰弱DX 体験版」というアプリが入っていたので、これを選択して開いたところ、図1のように「Bluetoothを起動しますか？ はい/いいえ」という選択肢が現れた。ここで「はい」を選択すると、Bluetoothがオンになり、画面の上部に青いBluetoothのアイコンが現れる。

図1: 付属のBluetooth対戦ゲームを起動した様子
（3枚目写真の画面の上部に青いマークが現れている）

続いて「Bluetooth接続しますか？ Yes/No」という選択肢も現れるが、その時点で既にBlueooth自体はオンになっており（図1の3つ目の写真のように、青いアイコンが出ている）、ここで「No」を選んでも、Bluetoothオンの状態は続く。（この選択肢は、Bluetooth経由の対戦機能を使うかどうかを尋ねているだけのようだ。）

そして、このアプリを終了させると、図2のようになる。終了させてもBluetoothはオンのままとなるわけだ。これは「ちかチャット」を起動した場合も同様である。*1

図2: 付属のBluetooth対戦ゲームを終了させた様子
（青いマークは消えていない）

なるほど、これが原因なのだろう。携帯電話を購入したらまずなんとなくゲームを起動してみるという人は多いだろう。そのとき、いきなり「Bluetoothを起動しますか」と尋ねられても何のことやらわからないまま、とりあえず「はい」を押してゲームを試してみるということも、ごく普通にあるだろう。そして、終了させた後、青いアイコンが出ていても、それが何を意味するかもわからないし、最初からそういうものだと思ってしまう人も少なくないだろう。

これが原因だとなると、これほどまでに多くの端末が検出可能となっているのは、日本だけの異常な事態と言えるかもしれない。

検出されるBluetooth端末の名前を集計

3月9日の日記に書いていたとおり、以前の私の実験では、デバイス探査の後の名前問い合わせ処理をしていないなかった*2のだが、実際の機種名を調べるため、私もそれをやってみた。その結果を以下に示す。

名前問い合わせの応答が得られた535個のデバイス*3について、多かった名前順に集計したのが次のリストである。

 60 812SH
 37 913SH
 32 816SH
 29 911SH
 22 705SH
 21 910SH
 18 920SH
 17 810SH
 14 821SH
 14 810P
 13 811SH
 11 923SH
 11 912SH
 11 822P
 10 931SH
 10 921SH
  9 922SH
  9 820P
  8 823SH
  8 820SH
  7 815SH
  6 W64SH
  6 824SH
  6 705P
  5 au Sportio
  5 W54T
  5 932SH
  5 930SH
  5 706P
  4 W63SA
  4 W63CA
  4 W61T
  4 Vodafone 905SH
  4 NM705i
  4 930SC
  4 821P
  3 Vodafone 904SH
  3 905SH
  3 821SC
  3 814SH
  2 W62SH
  2 W61SA
  2 W54S
  2 Vodafone 705SH
  2 NM706i
  2 920SC
  2 904SH
  2 813SH
  2 805SC
  2 709SC
  2 707SC2
  2 707SC

やはり、シャープ製ソフトバンクモバイル端末が圧倒的に多い。キャリアとメーカー別に集計すると、次の表の通りとなる。（「不明・その他」は、人の名前などに変更されていて機種が不明であるものや、カーナビ等である。）

auは、合わせて28個（5%）であり、NTTドコモは、Nokiaのドコモ対応（iモード対応）端末だけが検出された。

ソフトバンクモバイル以外/シャープ以外の端末の挙動

携帯電話販売店で実機を触らせてもらって、各社端末のBluetooth機能の挙動を調べてみたところ、概ね次のことが言えるようだった。

auの端末は、シャープ製ソフトバンクモバイル端末と同様の設定方式（検出可能設定「探索受付」のオン/オフと、Blutoothオン/オフ設定から構成）で、デフォルト設定も同様に、検出可能はオン、Bluetoothはオフのようだった。

NTTドコモの端末は、私が見た機種ではどれでも、検出可能にする設定が見当たらなかった。代わりに「ダイヤルアップ登録待受」という機能があり、これを使ったときだけ一時的に検出可能になる様子だった。NTTドコモはこの問題に初めから配慮しているということだろうか。

ソフトバンクモバイルの端末は、各社で仕様がバラバラの様子だった。日本の携帯電話はキャリアによって仕様が定められ、統一された仕様となっているという印象があったが、ソフトバンクモバイルはそうでもないようだった。

ソフトバンクのパナソニック製端末は、発売時期によって設定方式が異なるようだった。現在販売中の機種では、NTTドコモの端末に似た設定方式になっていたが、知人が持っている2007年春モデルでは、シャープ製に近い設定方式で、少し違うだけだった。上の検出された名前リストに、パナソニック製の2008年夏以降発売のモデルが現れていないことから、2008年夏モデルから、パナソニックは設定方式を変更したのではないだろうか。パナソニックもこの問題を認識して、対策を施したということなのではないか。

au端末は、設定方式がシャープ製ソフトバンク端末と同じであるにもかかわらず、検出される数が 5% と少ない。au端末では、おそらく、Bluetoothを意識的に使っている人だけが検出されているのだろう。

やはり、シャープ製（と他社製の一部も？）のソフトバンクモバイル端末が異常なのであって、付属のゲームや「ちかチャット」を起動しただけでBluetoothがオンになってしまう仕組みが、この事態を招いているのだろう。Bluetoothを使う人の割合が auでもソフトバンクでも同じで、両社のBluetooth対応端末のシェアも同じと仮定すると、全体の8割ほどがそれが原因ということになる。

それさえなければ、検出される端末の数は、現状の2割（5分の1）程度に少なくできていたはずではないだろうか。

パソコン等との比較

Bluetoothの設定方式は、大別して次の2つに分けられると言える。ここでは仮に「パソコン型」と「ドコモ型」とする。

Type-A （パソコン型）

特徴： Bluetooth電源のオン/オフ設定と、デバイス公開のオン/オフ設定という、2つの設定項目から構成。

該当機器

• Windows XP/Vista
• Mac OS X
• ソフトバンクのシャープ製端末の全て（おそらく）
• ソフトバンクのパナソニック製およびサムスン電子製 2008年春以前発売機種（おそらく）
• auのBluetooth対応全機種（おそらく）

Type-B （ドコモ型）

特徴： 基本的に「デバイス公開」状態にならない設計。Bluetoothの電源を入れることさえ誤ってすることがないよう外部機器の接続設定を終えてからでないとBluetoothオンにできないようになっている。

該当機器

• NTTドコモのBluetooth対応全機種（おそらく）
• ソフトバンクの2008年夏以降発売機種（シャープを除く）
• ソフトバンクのシャープ、パナソニック、サムスン電子以外の全機種（NEC、東芝、カシオ等。おそらく）

そして、Type-A はさらに以下のように2つに分けられる。

Type-A1（初期設定でデバイス公開オン）

特徴： デバイス公開設定が、デフォルトでオンのもの。

該当機器

• Windows XP
• Mac OS X
• ソフトバンクモバイルの Type-A 該当機種の全部（おそらく）
• auの Type-A 該当機種の全部（おそらく）

Type-A2（初期設定でデバイス公開オフ）

特徴： デバイス公開設定が、デフォルトではオフのもの。

該当機器

• Windows Vista

Type-A を採用するメーカーからすれば、「パソコンだって Type-A じゃないか」という釈明があるかもしれないが、パソコンを使う人と携帯電話を使う人とでは、リテラシに大幅な違いがあるわけで、パソコンを電源を入れたまま持ち歩く人というのは自己責任と言えるが、携帯電話の利用者もそう切って捨てていいのか。

パソコンの場合ですら、Microsoft社は、これをプライバシーの問題として捉えていて、Windows Vistaからは、Type-A2（デフォルトでデバイス公開はオフ）にして、設定画面で「プライバシー保護のため、Bluetoothデバイスによるこのコンピュータの検出時のみ、このチェックボックスをオンにしてください。」との注意書きをしている（図3）。

図3: Windows VisitaにおけるBluetoothの設定
（「プライバシー保護のため……」という注意書きがある）

（19日追記）しかも、他から接続して機器登録をするためにこの設定を「検出を許可する」に変更した場合でも、接続して機器登録が完了した時点で、図4の画面が現れて、設定を元に戻すよう促されるようになっている（デフォルトで戻す）。

図4: Windows Visitaで機器登録が完了したときの画面

関連ページ

• [010887]［ちかチャット］Bluetooth機器検索を止めることはできますか？, よくあるご質問, ソフトバンクモバイル
• 携帯の画面の上のほうにblueｔｏｏｔｈのマークが表示されたままなんです。 ソフト..., Yahoo!知恵袋, 2008年12月

■ Bluetoothフィッシングに注意 特にシャープ製ソフトバンクモバイル端末

シャープ製ソフトバンクモバイル端末でテスト

携帯電話で図1の画面が現れたとき、どうするだろうか？




図1: 「無料ゲーム パスキーは5555」

「無料ゲーム パスキーは5555」と出ている。

これは、他の機器からBluetoothでこの携帯電話に接続しようと試みたときの画面なのだが、接続元のデバイス名（コンピュータ名）を「無料ゲーム パスキーは5555」と設定しているため、このように表示されている。

ここでわけもわからず「はい」を押した場合にどうなるか。図2の画面が現れる。




図2: 「同じ数字（パスキー）を入力してください」の画面

「接続先」と書かれているが何のことかわからないまま、「パスキー？」「5555とか言ってたな」などと、思わず「5555」と入力してボタンを押してしまうと、次のようになる。




図3: 登録が完了して「はい」を押した場合の画面

この時点で*1、接続元の機器（ここではMacintosh）の画面は図4のようになっており、携帯電話内のファイルを自由に閲覧したりコピーできる状態になっている。




図4: 接続元の「Bluetoothファイル交換」ソフト

ここでたとえば「Pictures」のフォルダを開くと、下の図のようになり、携帯電話に保存されている写真を一覧したりコピーできてしまう。




図5: 携帯電話内の写真フォルダを閲覧している様子

さすがに、この画面で何かおかしいと気付いて、「キャンセル」ボタンを押して止めることになるだろうとは思うが、このような危険性が存在しているので、注意が必要だ。

このような画面が出たら「いいえ」「キャンセル」を押すこと。また、そもそもこのような接続をされないためにも、Bluetoothの「デバイスの公開」をオフに設定したほうがよい（3月1日の日記参照）。

以上は、シャープ社製ソフトバンクモバイル携帯電話の「816SH」での場合である。

では、同様のことを、コンピュータに対して（ここではMac OS X 10.5の場合）試みた場合にはどうなるだろうか。接続が試みられた時点で図6の画面が現れる。




図6: Mac OS Xに対してWindows Vistaから接続しようとした様子
（Windows Vista側でコンピュータ名を「パスキー：88793」とした場合）

これに騙されて引っかかる人はいるだろうか。「登録要求元」という太字の部分で違和感を感じることができれば、「拒否」を選ぶだろう。

仮にこれにひっかかってペアリングしてしまったとしても、普通は、ファイルを閲覧されてしまうことはない。なぜなら、Mac OS X 10.5では、「Bluetooth共有」機能がデフォルトではオフになっているからだ。

しかも、環境設定の「共有」で「Bluetooth共有」をオンに設定したとしても、図7のように、デフォルト設定では、閲覧されるのは「パブリック」フォルダだけとなっている。




図7: Mac OS Xの「Bluetooth共有」設定

Windows Vistaでも同様に注意深く設計されており、デフォルト設定でファイルを閲覧されることはないようだ。

これらに比べると「816SH」の設計はあまりにも不用心だ。初期設定のまま、ただBluetoothをオンにしただけで、この危険にさらされる。

図1や図2の画面をよくみると、「Bluetooth」「ペアリング」というタイトルが出ているので、「そこで気付け」という言い分があるかもしれない。たしかに、一度でもBluetoothで機器登録設定をやったことのある人なら、これらが何を意味するのか察知できるかもしれない。

だがどうだろう？ 昨日の日記に書いたように、シャープ製他のソフトバンクモバイル端末を使っている人の多くが、Bluetoothを使っていないのに、Bluetoothが何かさえわからないまま、Bluetoothをオンにしてしまっている。ペアリングの経験もない人々だろう。そういう人々にこれを察知せよというのはあまりに酷ではないか。

コンピュータの画面に比べて携帯電話の画面は狭いので、詳しく説明を表示することができず、図1や図2のような説明不足な画面にならざるを得ないというのは理解できるが、それならば、何らかの工夫でこういう危険をなくす設計をするべきだろう。

実地検証

実際にこれによる被害が出るものなのかを確かめるために、このような接続（接続元のコンピュータ名を「無料ゲーム パスキーは5555」とした）を、山手線列車内で何度か試してみた。

試すにあたっては、こちら側にパスキー入力画面が出た時点で中止する（こちら側でパスキー入力はしない）ものとし、ペアリング成功までは試さないようにした（重要）。

何日かにわたって、いくつもの相手に対し、何度か接続を試みたが、こちら側にパスキー入力画面が出るところまで至ったケースは、一度もなかった。

その原因として次のことが考えられる。(1)先方がその携帯電話で何らの操作をしているとき（メールを読み書きしているときや、Webを閲覧しているとき）には、先方に図1の画面が出ず、こちら側はエラーとなる。(2)先方が携帯電話を操作してないときは、この画面が出ても気付かず、時間切れで中止となる。

つまり、たまたま、待ち受け画面をぼんやりと見ていたときに図1の画面が出たときだけ、危険が生ずる。そう簡単には被害が出そうにないことを確認した。

しかし、この危険性の存在は知っておくべきであるし、端末の開発者らは、このような危険が生じないように工夫するべきであるので、ここに書いておく。

違法性に関する検討

ところで、このような罠のペアリングによって他人の携帯電話のファイルを閲覧する行為は、日本の法律で処罰の対象とすることはできるのだろうか。

この行為に関係し得るのは、不正アクセス禁止法しかない。疑問を挟む余地は以下の点にある。

1. Bluetooth端末同士で直接通信して接続しようとする行為が、はたして「電気通信回線を通じて行うもの」と言えるか。
2. Bluetoothのペアリングのために入力したパスキーが、はたして2条2項の「識別符号」に該当すると言えるか。
3. この手法による接続が、3条2項2号の「利用の制限を免れることができる情報又は指令を入力して当該特定電子計算機を作動させ」たに該当するか。

不正アクセス禁止法はどんな場合にも適用されるわけではない。まず、電気通信回線を通じて行うものに限られている。電気通信回線とは、解説書*2によると、「物理的な電気通信回線設備（送信の場所と受信の場所との間を接続する伝送路設備及びこれを一体として設置される交換設備並びにこれらの付属設備をいう。電気通信事業法第六条第二項参照）の存在を前提に、論理的に設けられているものである。有線、無線を問わない。電気通信事業法第六条第四項、第二一条第三項等にも用例があるが、これらと同一の概念である。」（p.28）とある。また、「ネットワークがインターネットに接続しているなどオープンなものであるか閉じたLANやWANを形成しているなどクローズドなものであるかを問わない。」（p.74）とある。LANでも該当し、無線でも該当するというのだが、一対一の直接の無線通信が「ネットワーク」なのか？「回線」なのか？という疑問はある。これが該当するなら、アナログのトランシーバーでのやりとりでも該当しそうだが、そういう法律なのだろうか？ よくわからない。

次に、攻撃者側で決めたパスキーを被害者側に入力させたときに、そのパスキーが「識別符号」なのかという点。「識別符号」とは、「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないものとされている符号」と定義されている（2条2項1号）。この場合、被害者側の本人がアクセス管理者である（携帯電話の通信キャリアは無関係）として、表示された通りの番号「5555」をその場で設定したものが、「みだりに第三者に知らせてはならないものとされている符号」と言えるのだろうか？ よくわからない。また、解説書には、「留守番電話に記録されたメッセージを暗号番号を入力して自宅外からこれを聞くような場合の留守番電話」等について、「他人の利用を予定しておらず、そのために利用権者等の識別のための識別符号を付与することもしていないから」という理由で、「アクセス制御機能を有していることにはならない」との記述がある*3。Bluetoothの利用制限も自分での利用しか予定していないもので、ユーザIDによる識別は存在しない（また、解説書p.41冒頭の例にも該当しない*4）のであるから、その例と同様に、この法の対象外であるようにも思える。が、よくわからない。

いずれにせよ、他人の携帯電話の中身を無断で覗き見ることは、少なくとも不適切な行為であるから、してはいけない。

■ Bluetooth探査、定点観測の場合

駅のホーム

3月の日記に掲載した図のように、電車内でBluetooth機器を観測すると、駅に出入りするごとに、ホームにいる人の携帯電話がたくさんすれ違い様に検出されるパターンが見られた。

図1: 平日朝における山手線の乗降パターン（再掲、class 2*1）

では、それとは逆に、駅のホームの側から出入りする電車の方を観測するとどうなるだろうか。図2は、山手線の新大久保駅*2のホーム（中央あたり）で観測した場合のデータである。なお、このときは、class 1のBluetoothアダプタを外付けして使用した*3。電車が出入りするごとに数十個の機器が検出されている。点線で繋がれているのは、どこかで用を済ませて戻ってきた人のものと思われる。

図2: 駅で定点観測した場合（新大久保駅、土曜夜、class 1）

図2では、土曜の夜だったため運転間隔がやや長い。本場の山手線はこんなものじゃないぞということで、平日の朝にも観測してみたところ、図3のようになった。

図3: 駅で定点観測した場合（新大久保駅、平日朝、class 1）

1時間38分の間に2597個の機器が検出された。このケースでは、ちょうと1時間数分後に再び現れた機器が1つあった（8時2分20秒から始まっている点線は9時5分0秒につながっている）。乗務員の携帯電話なのだろうか、それとも一周以上廻った乗客がいたのだろうか。

踏切の脇

図2で、ときどき見られる数個から10個ほどの小さな山は、隣の山手貨物線を通過する埼京線や湘南新宿ラインなどの列車のものだった。では、駅に停車する山手線電車ではなく、通過する山手線電車を観測するとどうなるだろうか。そこで、線路脇で試すべく、第二中里踏切に行って観測してみたところ、図4のようになった。観測は外回り線側で行い、この場所では山手貨物線は陰になっており、検出されていない。

図4: 通過列車を線路脇で観測した場合（第二中里踏切、土曜夕方、class 1）

停車する列車の場合よりかなり少ないが、それでもこれだけの数が検出された。1時間の間に230個が検出された。どこかで用を済ませて戻ってきた人も1つ検出されている。2つ以上のスロットにまたがる実線は付近の道路の通行人のものと思われる。

このとき、線路に接近しても、離れても、検出される数に大きな違いはないようだった。線路脇の道路の反対側でも十分検出できた。ということは、もし鉄道沿線の家に住んでいれば、継続して24時間、毎日観測することもできてしまいそうだ。

スクランブル交差点

次に、鉄道以外に人の多く集まる場所だとどうなるだろうか。図5は、渋谷ハチ公前スクランブル交差点正面のStarbucks店内の窓際の席で観測したときのデータである（外付けclass 1を使用、最初の20分間のデータ）。

図5: スクランブル交差点近くでの定点観測
（渋谷ハチ公前スクランブル交差点正面のStarbucks店内の窓際の席、日曜夜、class 1）

店の中からでも外の人たちを検知できている。長い実線は店内の客や後ろ側のTSUTAYAの客なのかもしれないが、数分の長さのものは交差点で信号待ちしている人たちであろう。2分間隔でブロックがあるように見えるが、これは信号の周期に対応しているだろうか。

同じデータを1時間後まで表示させると、図6のようになる。点線が多いのは、どこかに行って戻ってくる人の多い場所だからであろう。1時間の間に822個が検出された。

図6: 図5の1時間後までのデータ

既知との遭遇

第二中里踏切で検出した機器が、新大久保駅でも検出されていたかを調べてみたところ、2つあった。

000E7BXXXXXX 2009-05-22.09:01:25  0:00 | 217  新大久保駅、平日朝
000E7BXXXXXX 2009-05-23.17:41:15  0:00 | 138  第二中里踏切、土曜夕方

001CEEXXXXXX 2009-05-22.08:02:03 62:33 | 50,226  新大久保駅、平日朝
001CEEXXXXXX 2009-05-23.17:09:26  0:00 | 48      第二中里踏切、土曜夕方

このうち1つ（後者）は、図3で一周して現れたものだ。やはり乗務員なのか、あるいは乗務員室に備え付けの携帯電話か何かだろうか。「001CEE」のベンダー名は「SHARP Corporation」である。

次に、渋谷のスクランブル交差点で検出された機器が、新大久保駅でも検出されていたかを調べてみたところ、6つ見つかった。

001987XXXXXX 2009-04-04.19:35:19  0:21 | 41,42  新大久保駅、土曜夜
001987XXXXXX 2009-04-05.21:12:57  0:21 | 65,66  渋谷スクランブル交差点

0022F3XXXXXX 2009-04-04.19:57:10  0:00 | 103  新大久保駅、土曜夜
0022F3XXXXXX 2009-04-05.21:38:16  0:00 | 137  渋谷スクランブル交差点

001262XXXXXX 2009-04-05.21:04:33  0:00 | 41   渋谷スクランブル交差点
001262XXXXXX 2009-05-22.08:47:48  0:00 | 179  新大久保駅、平日朝

00175CXXXXXX 2009-04-05.21:07:18  1:25 | 49,52,53  渋谷スクランブル交差点
00175CXXXXXX 2009-05-22.07:52:11  0:00 | 22        新大久保駅、平日朝

00175CXXXXXX 2009-04-05.21:15:23  0:42 | 72,73,74  渋谷スクランブル交差点
00175CXXXXXX 2009-05-22.08:44:13  0:00 | 169       新大久保駅、平日朝

001CEEXXXXXX 2009-04-05.21:38:16  3:31 | 137,140,142,143,146,147  渋谷スクランブル交差点
001CEEXXXXXX 2009-05-22.07:47:15  0:00 | 8                        新大久保駅、平日朝

なお、土曜夜の新大久保駅と平日朝の新大久保駅の両方で検出されたものを調べたところ、45個もあった。

まとめ

3月にこの件を書いてからずいぶん経ったが、Bluetoothを検出可能にしたままの人の多さは減る様子がない。私がここに書いたところで、読む人はごく僅か。肝心な人たちには伝わらない。

先日の日記にも書いたように、ここまで多いのは、シャープ社製ソフトバンクモバイル端末の設計が悪いからなのだから、やはり、シャープなり、ソフトバンクモバイルから注意喚起のお知らせを公式に出してもらえないものだろうか。

• Bluetoothで山手線の乗降パターンを追跡してみた, 2009年3月1日の日記
• ユビキタス社会の歩き方(6) Bluetoothの「デバイスの公開」「検出可能にする」はオフに, 2009年3月1日の日記
• 首都高速都心環状線でBluetooth追跡できるか + 続・山手線, 2009年3月7日の日記
• 検出可能Bluetooth端末の3/4がシャープ社製か, 2009年3月9日の日記
• 東京地下鉄でBluetooth探査, 2009年3月15日の日記
• Bluetoothの異常な大量検出、シャープ製に原因, 2009年5月18日の日記
• Bluetoothフィッシングに注意 特にシャープ製ソフトバンクモバイル端末, 2009年5月19日の日記

■ 「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オフと唱えるのではなく、そもそも何のためにそうするのかから考えてみてはどうか。