Mozilla Flux

Mozilla関係の情報に特化したブログです。

トップ > Firefox > Firefoxが提供する安全なブラウジング

Firefoxが提供する安全なブラウジング

Firefox セキュリティ

フィッシング詐欺対策とマルウェア対策

Firefoxは、Googleが提供するSafe Browsing APIを利用して、ユーザーがフィッシング詐欺にあったり、マルウェア(悪意のあるソフトウェア) に汚染されたりすることを防いでいる。Firefox 3の時点でこのメカニズムは確立されており、Firefox 3.0.5ではAPIのバージョンをv2.1からv2.2に引き上げたが、その差はわずかだ。そして、Firefox 3.5は一連のメカニズムをそのまま引き継ぐ。

Firefoxのユーザーが偽装サイト*1（フィッシング詐欺サイト）として報告されているWebページにアクセスすると、警告画面が表示される。そこでは具体的な被害の例が示され、引き返すことを強く推奨される。マルウェアを配布する攻撃サイト*2でも同様だが、偽装サイトと違い、ページを読み込んでから警告画面を出しても、既にマルウェアのインストールが始まっていて手遅れという可能性があるため、読み込み自体をブロックする仕組みになっている。

セーフブラウジングの仕組み

Firefoxが特定のWebサイトを偽装サイトや攻撃サイト（以下「危険サイト」と総称）であると識別するためには、照合用のデータベースが必要だ。大元となるデータベースを構築して、危険サイトのデータをクライアントに送っているのはGoogleである。Firefoxは定められた通信手順（プロトコル）によってデータを取得し、照合に用いる。ユーザーが手元に保持するデータベースは、urlclassifier3.sqliteという名のSQLite形式のファイルである。

『Developer's Guide - Google Safe Browsing API』によれば、最初のアップデートはFirefoxの起動から5分以内に実施される。次のアップデートは15〜30分後に行われ、それ以降のアップデートは25〜30分おきとなる。*3このような形で危険サイトのブラックリストができあがる。

これをレギュラー・モードと呼ぶが、Firefox 2では、エンハンスト・モード（Enhanced Mode）を利用することもできた。安全なサイトのリスト（ホワイトリスト）をクライアント側に保存しておき、このリストに該当しないページについては、URLをすべてGoogleのサーバー側データベースに送ってチェックさせるモードである。前記のとおり、Firefoxは短い間隔で定期的にデータを受け取っているものの、サーバー側のデータベースとは一定のタイムラグが生じる。エンハンスト・モードは、URLを送ることでプライバシーを犠牲にしつつ、サーバー側の最新データを利用することで安全性を高めるものといえよう。*4しかし、このモードは、利用頻度などが考慮されてFirefox 3において削除された。

Firefox 3では唯一のモードとなったレギュラー・モードについて、もう少し詳しく見てみよう。『Client specification for the Google Safe Browsing v2.2 protocol』によれば、Googleのサーバーは、最初の接続時に最も価値のあるデータ（たとえば直近のデータ）をクライアントに送り、以後差分を送信し続ける。その際、危険サイトのURLはハッシュ値と呼ばれる暗号化されたデータに変換されているのだが、いったんSHA-256というアルゴリズムで256ビットのハッシュ値を生成*5した後、その先頭または最後尾の32ビットだけをクライアントに送る仕様となっている。なぜこのような手間をかけるのかといえば、ユーザー側データベースのサイズと通信負担を最小限に抑えるためである。

Firefoxは、urlclassifier3.sqliteの中に、この32ビットの暗号データを大量に保管しているわけだ。Webページなどにアクセスするたびに、FirefoxはそのURLを同じSHA-256アルゴリズムで暗号化し、先頭の32ビットを取り出して、蓄積されたデータと照合する。

もちろん、ハッシュ値の一部を切り取って用いているので、データと一致したとしても本当に危険サイトの場合もあれば、偶然という場合もありうる。そこで、最初の照合で陽性反応が出たときは、FirefoxはGoogleのサーバーに要求して、本来のハッシュ値（256ビット）を取得し、256ビットのデータ同士で再度照合を行う。このハッシュ値はURLに固有のデータなので、二度目の照合でも一致したときは、ユーザーがアクセスしたサイトは危険サイトと判定される。その後は前述したメカニズムが作動することになる。

詳細はコードの中に

これ以上の詳細を知りたい方は、"Bug 402611 - deal with changes to the safebrowsing v2 protocol"でパッチのコードを調べていただきたい。一例を挙げると、次のような記述が見つかるだろう。

/**
 * Clients updating the url-classifier database have the option of sending
 * partial (32-bit) hashes of URL fragments to be blacklisted.  If the
 * url-classifier encounters one of these truncated hashes, it will ask
 * an nsIUrlClassifierCompleter instance to asynchronously provide the
 * complete hash, along with some associated metadata.
 */
     malwareWarden.registerBlackTable("goog-malware-shavar");
     phishWarden.registerBlackTable("goog-phish-shavar");

うち、"goog-malware-shavar"と"goog-phish-shavar"については、前記Client specificationにおいて、次のように説明されている。

The contents of each chunk depends on the list type that the chunk belongs to. Currently, the possible lists are:

  • goog-phish-shavar: a list of hashed suffix/prefix expressions representing sites that should be blocked because they are hosting phishing pages.
  • goog-malware-shavar: a list of suffix/prefix regular expressions representing sites that should be blocked because they are hosting malware pages.

加えて、Bug 402611のコメント欄には「We can store either a partial hash (32 bits) or a complete hash (256 bits) for a given fragment.」との記述も見られる。このように、FirefoxがまずGoogleから送られてきた32ビットのデータを利用し、必要なときだけ256ビットのフルデータを利用する仕組みになっていることが、コードからも確認できる。

なお、"Bug 461891 - switch to using v2.2 safebrowsing servers"のコメントによれば、v2.1プロトコルとv2.2の違いは、リストの隙間を埋めるため空のチャンク（データ塊）をサーバーが送信できるようになったことだけだという。*6

Google ChromeやSafariとも共通

Firefox 3以降の危険サイト対策は、他のWebブラウザと同じなのか、違うのか。たとえば、Google Chrome（以下Chrome）については、Chromium Blogの『Understanding Phishing and Malware Protection in Google Chrome』でメカニズムが解説されている。その内容を読むと、Firefoxと同じ仕組みであることがわかる。

Chromeは、起動から5分以内にGoogleのサーバーにアクセスして危険サイトのリストを取得し、以後半時間ごとにリストを更新する。このリストはユーザーのコンピューターに保存され、Webブラウジング中は常に照合が行われる。SHA-256を用いて256ビットのハッシュ値を生成するが、最初の32ビットだけをユーザーの手元にダウンロードすることで、データベースのサイズと通信コストを節約している。

照合の際は、アクセスしたWebページやリソース（JavaScriptやFlashムービー）のURLも同様にハッシュ値を算出し、リストと比較。32ビットについて一致したときは、Googleのサーバーにそのハッシュ値を送信して、256ビットのフルハッシュ値を取得する。このように、送信されるのは基本的に32ビットのハッシュ値だけなので、ユーザーのプライバシーが守られるとGoogleは説明している。

ただ、Google Chrome Helpの『General Privacy : Safe Browsing』では、通常のログ情報（IPアドレスや場合によってはクッキー）を受け取ることもあるとしているが、これはサーバーとやりとりを行う以上やむを得ないだろう。なお、この32ビットのハッシュ値に該当するURLは上で述べたように複数あるため、ユーザーがアクセスしたWebページが特定されることはない。*7

Chromium Blogでは明言されていないものの、ChromeがSafe Browsing APIを使用しているのは明らかだ。常識的に考えても、かなりのコストをかけて開発・維持しているシステムを使わない理由がない。プロトコルのバージョンも最新のv2.2であると判断して間違いないだろう。

このSafe Browsing APIを利用するもう一つのWebブラウザが、意外にもSafariである。MacJournals.comは、Safari 3.2がSafe Browsing v2.1プロトコルを利用して危険サイトの判定を行っていると報じている（『Inside Safari 3.2’s anti-phishing features』*8）。Appleが詳細を明らかにしていないため、MacJournalsの独自分析に基づいてはいるものの、記述を読むかぎり信用してよさそうだ。ちなみに、記事は昨年11月時点のものであり、現在ではv2.2プロトコルにアップデートされていることだろう。

Operaでは

Operaは独自の危険サイト対策機能を実装している。これに関しては、id:saiton氏のブログ「A blog? with Σαιτω」に解説がある。

『Anti-Phishing エンジン』によれば、Opera 9.5以降は、フィッシング防止機能について、PhishTankとNetcraftのデータを利用している。また、『Opera Press Release』によれば、Opera 9.5はHaute Secureと提携してマルウェア対策を行うようになった。

具体的な手順は、Opera Softwareが出している『Fraud Protection』を見ると分かる。

Opera Fraud Protectionがプライバシーに与える影響は、次のように要約されます。

  1. デフォルトで、Opera Fraud Protectionは有効になっています。
  2. Opera Fraud Protectionを有効にしている場合、訪れたWebサイトのドメイン名はOperaの詐欺防止サーバーに、ドメイン名のハッシュ値とともに送信されます。HTTPSサイトは暗号化されたチャンネルを通じてチェックされる一方、ローカルなイントラネットのIPアドレスがチェックされることはありません。
  3. Operaの詐欺防止サーバーは、IPアドレスその他個人の識別にかかわる情報を保存しません。クッキーや他のセッション情報も存在せず、サーバーはログを取りません。
  4. Opera Fraud Protectionはいつでも設定から無効にできます。Tools > Preferences > Advanced > Securityを選んで、「Fraud Protectionを有効にする」のマークをチェックボックスから外してください。Opera Fraud Protectionが無効のとき、ブラウザは詐欺防止サーバーと一切やりとりしません。

以上はフィッシング詐欺対策とマルウェア対策で共通だ。ドメイン名はサーバーに送信されるものの、情報を保存しないポリシーを明確にすることで、ユーザーのプライバシーを保護している。

IE8のSmartScreenフィルター

Internet Explorer 8（IE8）は、SmartScreenという危険サイト対策機能を新しく搭載した。解説は既にあちこちでされているが、『Windows Internet Explorer 8 Privacy Statement』の記述は公式のものなので、最も信頼できる部類に入るだろう。

それによれば、SmartScreenフィルターは次のように動作する。ユーザーがIE8でWebサイトを訪れると、IE8はまずユーザーのコンピューターに保管されたリストと照合を行う。このリストは、トラフィックの多いWebサイトの中からMicrosoftが信頼できると認めたものから構成されている。つまりホワイトリストだ。ホワイトリストにないアドレスとユーザーがダウンロードするファイルのアドレス*9は、Microsoftに送信され、サーバー側のリストと照合が行われる。こちらのリストは、Microsoftが危険または疑わしいと判断したWebサイトやダウンロードURLから構成され、頻繁に更新されているものだ。ユーザーは、SmartScreenを自動的に機能させることもできるし、手動で個別にWebサイトのチェックを行うこともできる。

Microsoftに送信される情報は暗号化されたものだが、アドレスには検索語などのユーザーが入力した情報も含まれることがあるという。たとえば、「http://search.microsoft.com」で"Seattle"という単語を検索した場合、「http://search.microsoft.com/results.aspx?q=Seattle&qsc0=0&FORM=QBMH1&mkt=en-US」というフルアドレスが送信されることになる。Microsoftの説明では、こうした情報は個人情報を除去するようフィルタリングされるし、残ったものも個人の特定、連絡、あるいはターゲット広告には使用しないとのことである。

ただ、SmartScreenフィルターの利用状況、つまりWebサイトの訪問時間や訪問総数が、ときどき分析のためMicrosoftに送信される。また、ダウンロードされたファイルの名前やファイルパスが送信されることがある。さらに、Webサイトのアドレスが送信される際、ブラウザやOSのバージョン、SmartScreenフィルターのバージョン、ブラウザの言語、そのサイトで互換性ビューが有効かといった情報が付属することもある。加えて、IE8がランダムに生成したユニーク識別子も送信される。これらの情報は、パフォーマンスを分析し、製品とサービスの品質を改善するためにのみ利用されるという。

気になるのは、IE7のころと少し手順が変わっている点だ。IE7のPrivacy Statementを見ると、フルアドレスを送信することはないとしている。たとえば、上の例で言えば、「?q=Seattle&qsc0=0&FORM=QBMH1&mkt=en-US」の部分をあらかじめカットし、「http://search.microsoft.com/results.aspx」だけがサーバーに送られていた。IE8で仕様を変更した理由は明らかではない。いい方に解釈すれば、危険なページかどうかを正確に判断するためにそうした情報が必要だからということになるだろう。他方で、悪く取れば、MicrosoftはWebサイトのアクセス情報を把握できるとの見方もできる。ホワイトリストに含まれないサイトに限定されるが、どこにどの程度人気が集まっているかといったことを調査できる。理屈の上では、その分析結果を自社の検索サービスに反映させてもPrivacy Statementに反したことにはならない。なお、上の付属情報は、IE7の時代からMicrosoftに送信されていたようだ。

IE8のSmartScreenは、かつてFirefoxが実装していたエンハンスト・モードと基本的な仕組みは同じといえよう。サーバーに照合する頻度が高いぶん、安全性は保たれるが、プライバシーは犠牲になる。Microsoftは、「情報の保護と管理をきちんとやっていると考えている」そうだが、他のブラウザと比較すると、プライバシー保護の面では見劣りすると評価せざるを得ない。

とくに、フルアドレスが送信されるのは、企業ユーザーにとって不安の種だ。いくら暗号化されているとはいえ、イントラネットのローカルアドレスをMicrosoftのサーバーに保存されたくはないだろう。『SmartScreen フィルター : よく寄せられる質問』には、Webサイトを自分の信頼済みサイトの一覧に追加することで、部分的にSmartScreenフィルターをオフにできると書かれており、Microsoftがこうした懸念に対処する手段を用意していることが分かる。ただ、逆にいうと調べて設定を変える必要があるわけで、Firefoxなどと比べると格段に手間がかかることは事実だ。そして、IE8の設定について知らない多くのユーザーは、Microsoftを信頼するしかない。

どの程度安全なのか

主要なWebブラウザの危険サイト対策機能を概観してきたが、実際の効果のほども気になるところだ。しかし、この点に関する研究は少なく、現時点で判断を下すのは難しい。

たとえば、米NSS Labsが2009年3月12日付けで主要なブラウザのマルウェア対策機能に関するレポートを出している*10。その『Web Browser Security - Socially Engineered Malware』によると、調査は12日以上（2月26日〜3月10日）に渡って実施され、延べ282時間に及ぶもので、6万のURLをふるいにかけて得られた492のマルウェアサイトを対象とした。誤差のマージンは3.76％。結果は、次のとおりである。

有効性（Effectiveness）
Microsoft IE8 (RC1) 69％
Mozilla Firefox v3.07 30％
Apple Safari v3 24％
Google Chrome v1.0.154 16%
Opera v9.64 5%
Microsoft IE7 4%

有効性の欄は、マルウェアを検出して警告を発した率を示している。IE8の検出率が圧倒的で、二位のFirefox 3.0.7とは倍以上の大差だ。また、いわゆるモダンブラウザの中で、Opera 9.64のスコアだけが非常に悪い。

当然のことながら問題は、この結果の信用性である。IE8の数字があまりにも良すぎるため、かえって疑わしい。The Tech Heraldが『Can you trust the NSS Labs report touting the benefits of IE8?』という記事を出すのも無理はない。NSS Labsが対象としたマルウェアサイトのURLがレポートに含まれておらず、IE8に有利なアドレスを選んでいても確かめようがないため、鵜呑みにするのは危険である。

同じAPIを利用しているはずのFirefoxとChromeでスコアに顕著な差が付くのも非常に不自然だ。実装がおかしければ別だが、Chrome開発陣の腕前が他に比べて劣るとは到底思えない。しかも、Googleが開発したAPIなのだ。Chromeが隠し機能を利用していて成績がいいというならまだ話はわかるが、まったく逆なのである。テストの方法が不適当だったのではないか。

結果が信用できないとなると、Operaは最大の犠牲者といえる。Safe Browsing APIは利用していないので、Firefoxなどと結果が違うこと自体は不自然ではないものの、さすがにマルウェアの検出力がFirefoxの6分の1ということはないはずだ。ちなみに、フィッシングサイトの検出に関してではあるが、「セキュリティホール memo」の簡単な調査では優れた結果を出している。提携先は正しく選ばれているのであり、マルウェアの検出率だけ極端に落ちるとは考えにくい。

このように、一つの研究だけから危険サイト対策機能の効果を判断することはできない。同種の研究がさまざまな機関から発表されるようになれば、各ブラウザの真の実力も見えてくるだろう。一日も早くそのような状況になってほしいものだ。

結論

危険サイト対策として、Firefoxのようなブラックリスト方式をとるか、IE8のようなホワイトリスト方式をとるかは、安全性とプライバシーのバランスに対するスタンスの違いによる。ブラックリスト方式でも、リストが短時間のうちに逐次更新されれば安全性は保たれるし、ホワイトリスト方式でもサーバーが取得したデータを適切に管理するならばプライバシーは守られる。

Firefoxは初期設定のままでユーザーのプライバシーを強く保護しつつ、危険サイトもきっちりブロックする。なにしろ、IE8の安全性を強調したNSS Labsのレポートでさえ、Firefoxが次点につけているくらいだ。トップクラスのセキュリティ保護を提供していることは確かである。Firefoxは従来からセキュリティの高さをアピールしてきたが、その看板に偽りはない。

*1:偽装サイトのテストページ

*2:攻撃サイトのテストページ

*3:厳密にはエラーやタイムアウトの場合があるので、実際の仕様はより複雑である。

*4:ホワイトリストを保存するだけなので、データベースが小さくて済むというメリットもある。

*5:v1プロトコルの時代はMD5というアルゴリズムで128ビットのハッシュ値を生成していた。

*6:要求サイズを小さくしておける効果があるそうだ。

*7:この点はFirefoxも同じ。

*8:Macworldが転載したもの

*9:SNSサイトやファイル共有サイトのように、一般的には安全なサイトでも、危険なダウンロードアドレスが混じっていることがありうる。

*10:Firefox Hacks翻訳日記の『IE8 は進歩を証明したのか？』経由