高木浩光＠自宅の日記

■ セキュリティ商社の餌食になる思考停止事業者を自衛のため見分けよ

INTERNET Watchの4日の記事によると、UFJカードがフィッシング詐欺対策ツール を導入したという。

• UFJカード、フィッシング詐欺を防ぐ個人情報保護ツールを導入, INTERNET Watch, 2005年4月4日

  同ツールを起動することにより、利用者がアクセスしようとしているサイトが正規のUFJカードのサイトであるか判別できる。UFJカードを装ったメールに記載されたURLを開くと、正規のページではない場合には「UFJカードとは関連のないホームページにアクセスしました。」というメッセージダイアログが表示される。

そんなことができるのか？ と、にわかには信じがたい。UFJカードのプレスリ リースを確認してみると、次のように書かれていた。

本ソフトはフィッシング詐欺＊1対策機能等を持っており、お客様はUFJカードホームページ画面の起動ボタンをワンクリックするだけで、安全な環境で各種サービスをご利用いただけます。

（略）ＵＦＪカードのホームページにアクセスしている間、「nProtect Netizen」を起動することで、お客様のお使いのパソコンと情報を ガードします。また、昨今、問題となっているフィッシング詐欺に対しての有 効な対策機能である「フィッシングブロック」機能も備えております。フィッ シング対策機能がついた製品は他社にもありますが、それらは警告を促すだけ にとどまり、最終的にはお客様の意思決定に委ねられているため、抜本的な問 題解決には至っておりませんでした。しかし、「nProtect Netizen」の「フィッ シングブロック」機能は、お客様がアクセスしようとしているサイトが、正規 のＵＦＪカードのサイトであるかどうかを自動的に検知し、簡単に判別する画 期的なツールです。

UFJカード、ホームページのセキュリティを強化〜フィッシング詐欺対策機能ツール導入〜, 株式会社UFJカード, 2005年4月4日

ブックマークなどから本物のUFJカードのサイトを訪れて、そこに設置されている「nProtect:Netizen」を 起動することで、UFJカードのサイトに滞在している間、つまり、少なくとも一つのウィンドウがUFJカードのサイトを開いている間、ウイルス検出や、パーソナルファイアウォールや、キーロガー対策などができるというわけだ。消費者は無料で使用でき、料金はサイト側が負担するというコスト負担モデルになっており、サイト側にとっては、「お客様のためのセキュリティ対策をしている」というポーズをアピールできる点に価値があることになる。そのため、消費者がUFJカードのサイトを去ると数秒以内に 「nProtect:Netizen」は終了する仕組みになっている。他のサイトでも有効で あるためには、他のサイトも金を払って導入しないといけない。

キーロガー対策ができるといった機能はまあ評価できるだろう。銀行のような重要なサイトで無料でキーロガー対策ができるというわけだ。だが、フィッシング詐欺対策になるというのは納得しがたい。

そこで、UFJカードに電話して尋ねてみた。担当の方にいろいろ質問したり意 見を述べたところ、この製品の採用を決めた担当者が異動してしまっていて詳 しいことがわからないから、後日折り返し電話するとのことだった。

すると翌日、「nProtectサポートセンター」から電話がかかってきた。サポー トセンターと話す気などなかったのだが、かかってきたものはしかたがないの でお相手した。やりとりはおおむねこんな感じになった。

サポートセンター: 昨日UFJカード様へお問い合わせ頂いた件、nProtectサポー トセンターからお答えさせていただきます。

私: はぁ、そうですか。

サ: UFJカードのサイトでnProtectを起動した後、メールのリンクから別サイ トへジャンプすると、nProtectが終了してしまうとのことでしたが、

私: はい。

サ: ではまずお客様のパソコンの環境を教え……

私: 環境は関係ないですよ。だって、UFJカードのサイトに居るときだけ動作 するのがnProtectの仕様なんですから、そうなるのが当然ではないですか？

サ: UFJカードのサイトを開いて、nProtectを起動して、メールのリンクをク リックすると、ジャンプ先がUFJカードのサイトでないときには、「はい」か 「いいえ」を尋ねるダイアログが現れます。

私: 「はい」「いいえ」などというボタンは出ませんが。

サ: 出ます。

私: 「有効のまま閉じる」と「無効にして閉じる」ではありませんか？ まずそちらでやってみてはどうでしょうか。

サ: こちらで確認しますので、少々お待ちください。

...

サ: 「有効のまま閉じる」または「無効にして閉じる」のダイアログが出ました。

私: その後どうなりましたか？

サ: nProtectは動き続けています。

私: それは、別のウィンドウが開いたのではありませんか？

サ: 別のウィンドウが開いています。

私: IEの設定がデフォルトと違うのではありませんか？ 「インターネットオ プション」の「詳細設定」の「ショートカットを起動するためにウィンドウを 再使用する」の設定は、チェックになっていますか？

サ: チェックされています。

私: メールソフトは何を使いましたか？

サ: Outlook Expressです。

私: 他のメールソフトではどうなりますか。

サ: では、Becky!で確かめてみます。しばらくお待ちください。

...

サ: おっしゃるとおり、Becky!からリンク先にジャンプすると、既に開いているIEのウィンドウがジャンプ先に切り替わり、nProtectが終了しました。

私: そうでしょう？ で、どうなんですか？

サ: UFJカード様から伺っていましたお客様のご質問は、メールからリンク 先にジャンプするとnProtectが終了してしまうというものでした。たしかに そうなります。

私: これがフィッシング詐欺対策になるんですか？ ということをUFJカードに 尋ねたのですが。

サ: この現象について上に報告させていただきます。

私: むしろ、UFJカードに伝えたほうがよいのではないですか？

サ: 伝えます。

ちなみに、UFJカードより先に、東京スター銀行が同じものをフィッシング詐欺対策と称して導入していたが、こちらのプレスリリース（の2ページ目）には嘘偽りないことが書かれている。

■使用方法

例: 東京スター銀行のお客様のもとに、東京スター銀行を装ったフィッシング詐欺のメールが届いたとします。メールに書かれているURLがフィッシングサイトかどうかを判断したい場合、以下のようにします。

1. 東京スター銀行のホームページ（http://www.tokyostarbank.co.jp/）にアクセスし、「nProtect Netizen」を起動します。（メールに書かれているURLを直接クリッ クしないでください。）

2. 別のブラウザウィンドウを立ち上げ、メールに記載されているURLをクリックしてそのサイトを開きます。もしこのときに、『東京スター銀行とは関係のないホームページにアクセスしました。』というメッセージダイアログが表示されたら、そのサイトはフィッシングサイトである可能性があります。

日本企業初!! フィッシング詐欺対策機能を持ったツールを導入 〜自社ホームページの個人情報保護を強化し、お客様に安全と安心を提供〜, 株式会社東京スター銀行, 2005年3月23日, p.2

この説明は正しい*1。この通りに使うことを消費者が理解していないと、フィッシング詐 欺対策にはならない。このように使い方をきっちり説明しなければ、虚になる。

ちなみに、この東京スター銀行の（正確な）プレスリリースを受けて、マスゴミがいい加減な報道をして、人々に誤まった理解を広げていた。

• 東京スター銀行、Web サイトにフィッシング詐欺対策機能を導入, japan.internet.com編集部, 2005年3月24日

  このフィッシングブロック機能は、ツールを起動するだけで、ユーザーがアクセスしようとしているサイトが正規の東京スター銀行のサイトかどうか、判別することができる。同ツールが起動している間、これを起動させた Web サイトとは関係のない URL を開こうとすると、注意を促すメッセージダイアログが表示される。

他方、INTERNET Watchは正確な報道をしていた。

• 東京スター銀行、フィッシング詐欺メール対策ツールを導入, INTERNET Watch, 2005年3月23日

  たとえば、利用者のもとに東京スター銀行を装った疑いのあるメールが届いた場合、東京スター銀行のサイトにアクセスしてからnProtect Netizenを起動する。その後、 別のブラウザを立ち上げてメールに記載されているURLを開 くと、正規のページでない場合には「東京スター銀行とは関連のないホームペー ジにアクセスしました。」というメッセージダイアログが表示される。

同じソフトなのに、東京スター銀行についての報道では正しいことが書かれて おり、UFJカードについての報道では誤ったことが書かれているのはどうした ことか。同じ記者による記事なのにだ。どうやら、プレスリリースを右から左 へと流しているだけらしい。いまどき、文章の要約なんぞ機械でもできるわけ で、プレスリリースを垂れ流すだけならそんな報道はいらない。そんなのは近 い将来 Googleが機械的にやってのける仕事になるだろう。マスゴミに人間は 不要なのだ。

さて、東京スター銀行にとって、この「nProtect:Netizen」のフィッシング対 策機能は欠かせない重要な役割を担っている。

なぜなら、東京スター銀行のログインの画面は（いまどきめずらしく）アドレス バーもないし、ステータスバーもないし（図1）、右クリックも禁止されてい るので、ログイン画面が本物かどうか消費者が自力で確認する手段がないのだ。 だからこそ、「nProtect:Netizen」を使うことによって、消費者が画面が本物 かどうか確認できるというわけだ。

図1: 東京スター銀行のログイン画面（Windows XP SP1で表示した様子）

今まさにこの種の対策ソフトを導入して成果をあげたいと考えている事業者の 担当者がいたら、その前にまず、自社の正規のログイン画面からアドレスバー を隠し、ステータスバーも隠し、右クリックも禁止するとよいだろう。

そして消費者は、「セキュリティ対策をしました」と発表するサービス事業者 の真価を見極める眼を持たなければならない。マスゴミは本当のことを絶対に 教えてはくれない。

■ PKIよくある勘違い(9)「『詳細設定』ボタンで証明書の使用目的を制限できる」

LGPKI Application CAルート証明書の配布は各自治体ごとに行われているが、 たとえば東京都の配布サイトでは、「安全な通信を行うための証明書 使用許諾」に同意しないとダ ウンロードできないように説明されている。ここには「禁止事項」が規定され ているのだが、認証局の公開鍵証明書をどう使おうがそんなのは利用者の勝手 だろう*1。 コースターとして使おうがちり紙として使おうが自由だ。 ましてや、「証明書」という性質のデータに著作権などあるはずもないわけで、 そもそも「使用許諾」などと称すものをここで掲げること自体、大きな勘違い に基づいているように思えてならない。

さて、東京都が規定している「禁止事項」の文は次のようになっている。

1.禁止事項

安全な通信を行うための証明書の入手と設定に当たっては、次に掲げる行為を 禁止します。

(1) 本証明書を、証明書ポリシー（CP：Certificate Policy）に定められてい る目的以外に使用すること。

安全な通信を行うための証明書 使用許諾, 東京都総務局IT推進室

CPに定められている目的以外に使用しない……というが、CPが定める目的とい うのは認証局側が守るべき事項なんじゃないか？

CPとは、認証局がその証明書をどのような目的にしか使用しない、つまり、ど んな証明書しか発行しないということを、消費者に対して約束する（その認証 局証明書を信頼済みルート認証局として登録する利用者に対して保証事項を約 束する）文書である。なのに、CPに定められている目的以外に使うなと我々に 対して要求しているのである。

そもそもそれ以前に、この文書は他人に何かを禁止する性質の文書としての体 をなしていない。なぜなら、「証明書ポリシー（CP：Certificate Policy） に定められている目的」という文が何を指すのかが不明だからだ。

この点について、2月だったかに東京都に電話して尋ねたことがある。「禁止 事項にある『CPに定められている』とは、CPのどの条項のことを指すのですか？」 という趣旨の質問をしたところ、即答できず、折り返し電話ということになっ た。折り返しの電話で得られた回答によると、この「目的」とは以下の部分の ことを指すそうだ。

1.3.2 適用性・適用環境など

アプリケーション証明書は、以下の用途及びアプリケーションでの使用を前提とする。

・Web サーバ証明書

地方公共団体で運営されるWeb サーバ等の各種サーバに適用し、住民・企業等に 対するホームページによる広報及び申請業務等や地方公共団体内の業務システム 等で使用する。また、地方公共団体組織認証基盤として運用される各種サーバに適 用する。Web サーバ証明書の有効期間は、証明書を有効とする日から起算して3 年とする。

・メール用証明書

地方公共団体の広報担当者による住民・企業等向けメールマガジンの発信等に使用 する。メール用証明書の有効期間は、証明書を有効とする日から起算して3 年とす る。

地方公共団体組織認証基盤 アプリケーション証明書 証明書ポリシー（ＣＰ）, p. 8

つまり、ルート証明書の「使用許諾」では、サーバ証明書とS/MIME証明書以外 の目的に使うなと規定していることになるわけだが、使うなと言われても、 それは一般の利用者にとって何を意味するのだろうか。

さてここからが本題であるが、じつは、これは具体的に何を指しているのかと いうと、東京都の「安全な通信を行うための証明書の組み込み方」のページに 書かれている、「4.証明書の設定」のことを指すのだ。要点は図1の部分にある。

図1: 東京都が指示している「証明書の設定」

このように、Windowsの証明書ストアでは、証明書の「プロパティの編集」 機能で、その証明書の利用の範囲を限定する設定が可能になっている。 東京都は、「サーバ認証」と「電子メールの保護」だけを有効にせよと指示し ている。「使用許諾」で「禁止事項」とされてい たのは、この通りの以外の設定をする行為が禁止されていたのである。（電話 で問い合わせた際、そのような趣旨の説明を受けた。）

この「証明書の目的」の限定は重要だ。もし「すべてを有効にする」を選択し ていると、下のチェックボックスのリストに挙げられているあらゆる目的で使 われることを許してしまう。

つまり、もし認証局が悪意を持って、もしくはミスによって目的外の証明書を 発行してしまった場合や、あるいは、認証局のミスで秘密鍵が悪意ある者の手 に流出した場合、それによる攻撃がもたらすなりすまし被害は、ここに挙げら れたあらゆる目的の認証パス検証において生じてしまうわけだが、ここをきち んと設定して、「次の目的だけを有効にする」とし、ルート認証局の証明書発 行ポリシーに定められた目的だけに限定させておけば、万が一の被害を最小限 に抑えることができるわけだ。

実際、図2のように、Windowsのルート証明書ストアに最初から登録されている 各ルート認証局の証明書は、すべてきちんとこの目的の設定がなされている。

図2: ルート認証局の「証明書の目的」が最初から設定されている様子

ところが、後からユーザが手作業でルート証明書を登録した場合には、「この 証明書の目的をすべて有効にする」がデフォルト設定となっているのだ（図3）。

図3: 後からユーザがインポートしたルート証明書の「目的」のデフォルト設定

これは、「すべて有効にする」がデフォルトという Windowsの設計が悪い*2 のだが、それを言っていても始まらないわけで、東京都はユーザに対し、この 設定を怠ることを禁止しているわけである。

じつは、同様の設定を指示している自治体は他にもある。たとえば以下だ。

• 三重県: 証明書の設定
• 広島県: 「安全な通信を行うための証明書」の入手と組込み手順
• 鳥取県: LGPKIアプリケーションCA自己署名証明書の組み込み方法

「信頼されたルート証明機関」から「Application CA」を選んで「表示」 ボタンを押し（図4）、現れた証明書プロパティのウィンドウで「詳 細設定」タブを選んで「プロパティの編集」ボタンを押せと指示されている。

図4: 正しい指示（三重県の例）

と・こ・ろ・が、だ。

以下の自治体の場合を見てみよう。

• 岩手県: 電子入札, 4.ブラウザの設定
• 福島県: 電子申請の準備, ブラウザへの設定
• 茨城県: 電子入札案内, 安全な通信を行うための証明書の設定
• 栃木県: 「安全な通信を行うための証明書」のインストール
• 静岡県: 地方公共団体組織認証基盤(LGPKI), 安全な通信を行うための証明書の入手と設定
• 岐阜県: 安全な通信を行うための証明書 入手と設定方法2（ブラウザの設定）
• 滋賀県: 安全な通信を行うための設定
• 京都府: 自己署名証明書の組み込み手順
• 兵庫県: 安全な通信を行うための証明書の組み込み方法について
• 岡山県: 自己署名証明書の入手と組み込み
• 山口県: 安全な通信を行うための仕組み, 証明書のインストール１
• 沖縄県: 安全な通信を行うために

これらの自治体はいずれも、図5のように、「詳細設定」ボタンを押せと言っ ている。（「表示」ボタンではなく。）

図5: 誤った指示（栃木県の例）

すると、図6の指示にあるウィンドウが現れるので、ここの「証明書の目的」 欄の「サーバー認証」と「電子メールの保護」だけチェック状態にせよという。

図6: 誤った指示（栃木県の例）

この設定画面は何だろうか？ 図1のものとは異なる。

じつはこれ、証明書の使用目的を限定する設定ではないのである。

画面のタイトルにあるように、これは「詳細オプション」であり、「[高度な 目的]の一覧に追加する目的を1つ以上選択してください」という項目の他に、 「エクスポート形式」という項目も並んでいる。これは、ひとつひとつの証明 書に対する設定ではなく、証明書ストア操作画面での操作の好みを設定する （カスタマイズする）ところなのだ。

もっと具体的に言うと、「[高度な目的]の一覧」とは何なのか？ だ。その答 えの鍵は、図7の矢印部分のメニューにある。

図7: 表示する証明書を目的で絞るためのメニュー

この「目的(N):」というメニューを開いてみると、図8のようにメニュー項目 が現れる。ここに「<高度な目的>」という項目がある。そして、このメニュー は最初の状態では「<すべて>」が選択されている。

図8: メニューを開いた様子

このメニューがどういう機能のものかというと、下にある証明書一覧リストに 表示させる証明書を、その目的設定に従って絞るというものだ。

つまり、このメニューで「<すべて>」が選択されているときは全部の証明書が 表示され、メニューで「サーバー認証」を選択したときは、図1の設定で「サー バー認証」がチェックされている証明書についてだけこの一覧に表示されると いうものだ。

ユーザの立場から言えば、ユーザが「S/MIME署名の検証用に使っているルート 認証局を調べたい」と思ったら、このメニューから「電子メールの保護」を選 べば、それに該当する認証局だけがリストアップされる。そういう仕組みだ。

そして、証明書の目的の種類には数多くのものがあるわけだが、デフォルト設 定では、このメニューには少しだけの項目しかない。たとえば「コード署名」 の項目がメニューにない。というのは、デフォルト設定では「コード署名」は 「<高度な目的>」グループに分類されているからだ。つまり、「高度な目的」 グループに分類されていないものがメニューに単独で現れているのである。

というわけで、図9の設定画面が何なのかというと、これは、このメニューで 「高度な目的」グループに分類するのをどれにするかを選ぶところなのだ。 もし、「コード署名」をメニュー項目として出したいならば、図9の画面で 「コード署名」のチェックを外せばよい。「<高度な目的>」グループから外さ れるからだ。

図9: メニューの分類方法を設定するオプション設定

というわけで、岩手県、福島県、茨城県、栃木県、静岡県、岐阜県、滋賀県、 京都府、兵庫県、岡山県、山口県、沖縄県などが言っていることは、滅茶苦茶 に頓珍漢なのである。これはメニューのカスタマイズをさせているだけなのだ。

岡山県の例

沖縄県の例

京都府の例

兵庫県の例

静岡県の例

山口県の例

滋賀県の例

岐阜県の例

岩手県の例

栃木県の例

図10: 頓珍漢な説明

どうしてこんな愚かなことになってしまっているのだろうか。 何か抜本的な対策が欠けているはずである。

■ メールアドレス変更

転居に伴い、ケーブルテレビの accsnetを解約することにしたため、これまでのメールアドレス「takagi@mail1.accsnet.ne.jp」は廃止することにした。あと2週間ほどで届かなくなる。

この日記の新しい連絡先メールアドレスは、blog@takagi-hiromitsu.jp だ。

■ 他社製品は「欠陥」と報道、自社のことは「不具合」とぼかす朝日新聞社

14日の朝日新聞朝刊に「ウィンドウズ、欠陥８件公表　ウイルス侵入の危険」という見出しの記事が出ていた。ネット版では「ＯＳなどに欠陥　ＭＳが修正版ダウンロード呼びかけ」という見出しになっている。こうし た記事が一般紙に出るようになったことは、今ではもう珍しくない。

ところが、22日、朝日新聞社からの告知として次の見出しの発表がなされた。

• 文字拡大・音声ツール「WebUD（ウェブ・ユーディー）」の不具合に関するお知らせ, 朝日新聞社, 2005年4月22日

  「WebUD」において、画面を開いた際にブラウザ上で自動実行される部品に不具合があることが明らかになりました。

  「WebUD」の利用者を狙った悪意あるサイトにアクセスした場合、悪意あるプログラムを実行される恐れがあります。これにより、利用者のPC内のファイルが読み取られたり、書き換えられる可能性があります。

なぜ欠陥ではなく、脆弱性でもなく、不具合なのか。

これはJVN#A7DA6818 の件のようだ。私はこの件の発見者（届出者）ではないので、どのような 脆弱性なのか詳細は知らないが、製造者である富士通の発表文の「対応方法」 には、ActiveXコントロールを削除するようにと指示されていることから、 おそらく、インターネットゾーンで呼び出されると危険な機能を持つActiveX コントロールであるにもかかわらず、「スクリプトを実行しても安全」とマー クして出荷していたということではなかろうか*1。

朝日新聞社の告知によれば、「悪意あるプログラムを実行される」とあり、 「ファイルを書き換えられる」ともあるので、任意コードの実行が可能となっ ていた可能性*2がある。であれ ば、それによってもたらされる脅威は、ウイルスやスパイウェアの埋め込みな どが挙げられるべきところだ。

Windowsの脆弱性を伝える記事にあった表現

最も重大な「緊急」と位置づけており、（略）

今回見つかった欠陥を放置した場合、コンピューターウイルスが入り込みやす くなったり、ハッカーからパソコン内部の画像ファイルを消される攻撃を受け たりする恐れがあるという。

ＯＳなどに欠陥　ＭＳが修正版ダウンロード呼びかけ, 朝日新聞, 2005年4月13日

は、そのまま「文字拡大・音声ツール」にも当てはまる表現だろう。たとえば、 今回の件を新聞記事風に次のように書くことができる。

朝日新聞社は２２日、同社のウェブサイト「asahi.com」で配布していたパソ コン用ソフト「WebUD（ウェブ・ユーディー）」に欠陥が見つかったと公表し た。最も重大な「緊急」と位置づけており、同社のホームページを通じて、 組み込んだソフトと部品を削除するよう、また「信頼された発行元」から 「FUJITSU LIMITED」を削除するよう呼びかけている。

今回見つかった欠陥を放置した場合、コンピューターウイルスが入り込みやす くなったり、ハッカーからパソコン内部のファイルを書き換えられる攻撃を受 けたりする恐れがあるという。

にもかかわらず、Microsoftの件は「欠陥」で、自分のところの告知は 「不具合」なのか。

「不具合」という表現の選択にはどのような意図が込められているだろうか。たとえば、14日に発表されたJVN#9ADCBB12のケースを見てみる。ここには、

この問題は、KDDI 株式会社の端末について報告されました。製品開発者の判断により脆弱性ではないとされていますが、対策情報が公開されています。JVN では製品開発者との調整の上、ユーザへの周知を目的として、この問題を掲載しています。

JVN#9ADCBB12: 携帯電話端末における特定 QR コードを使用したサイト接続時の問題

と書かれている。こちらの発見者（届出者）は私なので問題点の詳細を知って いる。詳細については BUGTRAQ-JPで以下のように公表した。

• au携帯電話のバーコードリーダでジャンプ先URLが偽装される

この事象の場合、これを「脆弱性ではない」と言い、「不具合である」と言う、 その気持ちは察することができる。auの発表文では次のように説明されている。

〈事象〉
読込んだバーコードによっては、カーソルのあたっている次の行のURLにジャンプする事があります。
※尚、auホームページで公開しておりますau仕様に基づいて作成された バーコードでは本事象は発生しません。

バーコード (2次元コード) リーダーご利用にあたっての注意点, auからのお知らせ, 2005年4月14日

つまり、「au仕様に基づかないコードを読み取ると、ジャンプ先が1行ずれた ものになってしまうことがある」という説明のしかたになっている。たしかに このように表現されると、「不具合」という言葉でも似合うように感じられる*3。 「ときどき1行ずれちゃうんです」というわけだ。

たしかに、偶発的に一行ずれるようなバグであれば、それは「不具合」と呼ば れても違和感を感じない。しかし、JVN#9ADCBB12の 事象は偶発的に発生するというよりも、ほとんどの場合、攻撃者が意図して作 成したデータによって起こされるであろうし、それは 100パーセントの再現性 をもって起こされるものだ。そして、攻撃者のその意図は、ユーザのセキュリ ティを損ねるものである。

一般的な不具合ないし欠陥と、脆弱性とをなぜ区別して表現するべきかという と、ユーザがそれを修正するパッチを適用する必要があることについて、もし くは、回避策をとる必要があることについて、その必要性を正しく認識できる ようにするためだ。

偶発的に稀に起きる事象とか、特定の機能が正常に動かないといった不具合で あれば、パッチを適用しないで済ますということもあり得るが、外部からの意 図的な攻撃によって生ずる事象であれば、攻撃する者がいないうちは何も起き ないが、ひとたび攻撃が始まると確実に被害に遭うといったことになるため、 早めにパッチを適用しないといけない。もしくは、回避策があるなら問題点を 理解して避けるように行動しないといけない。そういう性質の問題点なのかど うかがすぐに見分けられるよう、脆弱性という言葉が使われるべきである。 「vulnerability」（脆弱性）は「攻撃誘発性」とも訳される。

auのバーコードリーダーBREWアプリの件では、それを「欠陥」とまで呼ぶのは 相応しくないように思う。なぜなら、このBREWアプリは、「MEBKM:」形式のデー タを読み取ると、タイトル行とジャンプ先URL行の両方をリンクにするわけだ が、これは仕様だったのだと思われる。タイトルにURLが書けることも仕様だ と見るのが自然だ。

HTMLメールでも、ハイパーリンクの表示文字列にURLを書く（リンク先とは別 の）ことができるが、たとえそれがフィッシング詐欺に悪用されまくっていて も、それは仕様だ。そういった仕様のままで受け入れられているのは、PCの Webブラウザでは、ジャンプした後でアドレスバーを見て現在地を確認するこ とができるし、本来それをするべきということになっているからだ。auのバー コードリーダの挙動も、HTMLメールのハイパーリンクと違いない。だが、携帯 電話のWebブラウザにはアドレスバーがないため、PCとは状況が異なってくる。 リンクの表示文字列に任意の文字列を指定できるHTMLのようなことは、できな いようにしておくべきなのだ。

つまり、auの件は、欠陥ではなく仕様通りの挙動なのだが、その仕様がフィッ シング詐欺という攻撃を誘発しかねないという点で、改善した方がよいと人々 のコンセンサスが得られそうな話だったからこそ、auは修正をしたわけである。 そうしたセキュリティ上の理由で改善した方がよいものを、「脆弱性」と呼ぶ。

マイクロソフト社が、脆弱性のことを欠陥と呼ばないで欲しいというようなこ とを主張しているのを、いろいろなところで耳にした。たしかに、auのバーコー ドリーダの事例に見られるように、すべての脆弱性が欠陥と呼べるものという わけではないのだから、一律に「脆弱性」を「欠陥」に置き換えて呼ぶのはよ ろしくないかもしれない。

ベンダーの立場として「欠陥」と呼んで欲しくないとする理由として、製造者 の中では「欠陥」=「瑕疵」を意味するということがどうもあるらしい。 「瑕疵」とは広辞苑によれば「〔法〕行為・物・権利などに本来あるべき要件 や性質が欠けていること」とある。マイクロソフトが「欠陥」という言葉を避 けるわりに、「脆弱性」という言葉は積極的に使っているのは、「脆弱性」と いう言葉に、瑕疵といった意味を持たせていないためであろう。

つまり、「脆弱性」とは、必ずしも製造者の瑕疵によるものだとは認めないが、 お客様のセキュリティのために改善した方がよいと判断したので、修正パッチ を提供してさしあげますよ、という性質のものではないだろうか。責任を認め ずにバンバン修正パッチをリリースできるので、「脆弱性」とはまことに便利 な言葉である。

にもかかわらず、auがバーコードリーダの件を「脆弱性ではない」としたとい うのは、まことに不可解である。「仕様通りの挙動だが、セキュリティ上よく ない仕様だったので、改善することにした」という意味で「脆弱性」と言えば よいはずだ。修正版を出すにあたって、脆弱性と認めたくないがために、修正 理由を「1行ずれることがある」という事象として捉えざるをえず、そうする とそれは仕様通りに動作しないという意味となり、「不具合」ということになっ てしまう。

私の理解では、「脆弱性」を出してしまうことより「不具合」を出すことの方 がみっともないことだと感じる。バーコードリーダの挙動は仕様通りだったの だから、不具合なんかじゃない*4。

「脆弱性ではないからパッチを出さない」とか、「脆弱性ではないから発表し ない」というのならわかるが、auは、修正版も出したし、きちんとした告知も しているのだから、「脆弱性ではない」と拘ることの auにとってのメリット がわからない。それほどまでに「脆弱性」という言葉に悪いイメージを抱いて いるということなのだろうか。

脆弱性には深刻なものから軽微なものまであることをまず理解するべきだろう。 「ユーザは脆弱性と耳にしただけで恐れおののいてしまうのではないか」と心 配なのなら、脆弱性の深刻度について記述して発表すればよかろう。

話を戻すと、マイクロソフトは「欠陥」報道に不満があるようだが、少なくと も深刻度が最高レベルのものについては「欠陥」と呼んで差し支えないはずだ。 「欠陥」とは一般的な言葉であり、必ずしも法的な「瑕疵」を意味するわけで はない。

このように言葉を整理してみても、Windowsの脆弱性のときは「欠陥」と報道 している朝日新聞社が、自社の件では「不具合」と表現するのは正当性を欠く と言える。脆弱性の深刻度が最高レベルのものだからだ。深刻度を見出しに含 めずに「脆弱性」と表現するのならそれはそれでよいが、そうともしないで、 欠陥という言葉を避けるのには正当な理由が見当たらない。

もっとも、この「不具合」という表現は、製品開発者である富士通の発表文が そうなっていたため、そのまま写しただけなのだろう。

富士通は、http://software.fujitsu.com/jp/security/というセキュリティ脆弱性情報専門のページを設けており、 これまで、他社製品であろうが自社製品であろうが「脆弱性」と表現してきて いる。 たとえば以下の見出しのページがある。（「Interstage」は富士通の製品。）

• Interstageアプリケーションサーバのシングル・サインオン機能における脆弱性について

ここは富士通のセキュリティ専門部隊が書いているところなので、当然の表現だ。

ところがどういうわけか、「WebUD」についてだけは「不具合」と称している。 それはプロフェッショナルとしてどうなのか？ 「[緊急]」とマークまでして いるのに、あくまでも不具合なのか。

4月22日 [緊急]
「ウェブ・アクセシビリティ支援ツール「WebUD」の不具合への対応について」が公開されました。

大元の発表文は、富士通の「コンサルティング事業本部」というところが出し ているらしい。コンサルティング事業というのが何のコンサルか知らないが、 セキュリティのコンサルをする資格がないことだけはわかる。

そこが「不具合」という言葉を使えと指示したのだろうか？ そんな指示に従っ て適切なアドバイスをしないセキュリティ部隊なんてのも信用に値しない。

■ 音声読み上げブラウザにおけるphishing詐欺対策は？

何度も書いてきたとおり、フィッシング詐欺対策の要は、アドレスバーのURL を確認することであり、錠前アイコンを確認することであり、SSLの証明書異 常を示す警告が出たら「いいえ」を押すことだ。

では、WebUDのような音声読み上げブラウザにおいて、視覚障害者の使用を想 定した場合にはどうだろうか。

WebUDをざっと使ってみたところ、アドレスバーを読み上げる機能はないよう だ。全部のURLを読む必要はなくドメイン名だけでもよいので、読み上げる機 能があるべきではなかろうか。

そうした機能がないと、音声だけを頼りに使っているユーザは、自分が今どこ を見ているかについて、ページコンテンツに書かれている文章だけを頼りに信 じてしまうことになる。これは危ないのではないか。

錠前アイコンを音声で確認する機能も欲しいところだ。

というか、それ以前に、WebUDには錠前アイコン表示機能（視覚的な）からして存在しないのだが……。 IPAに脆弱性として届出ようかとも考えたが、脆弱性ではないと言われそうな ので、ここに書いてしまおう。

■ 自動アップデートは電子署名検証が必須なのだが……

トレンドマイクロ社の「ウイルスバスター」で、問題のある更新データを配布 してしまったために、大規模な障害が発生した。

• メディア・ＪＲなどＬＡＮ障害、ウイルス対策で不具合, セキュリティホールmemoによるまとめ

奇しくも、前日に「『重要インフラでは自然災害や人為的ミスによるIT障害への対応も』――情報セキュリティ基本問題委員会が第2次提言を公表」という話題が出ていたところだった。

重要インフラのセキュリティとか、サイバーテロとか以前から言われつつも、 具体的にどういう事態だろうか？ という疑問はあったと思われるが、 こういうところ（ウイルスバスターのようなもの）がけっこうアキレス腱になっ ているのだということが明るみになった。

今でこそ Windows Updateは全自動になっているが、4年前ごろは手動だった。 そのころから「もう自動で更新しちゃえばいいじゃないか」という声はあがっ ていたが、Microsoftはそれに慎重だったように記憶している。なにしろ、 万が一誤ったデータを配布してしまったら、それがもたらす損害は莫大となる。

また、全自動更新が当たり前になってしまうと、事実上、インターネットにつ ながったWindowsコンピュータは、Microsoft社の思い通りにどうとでも操るこ とができてしまうことになり、安全保障上の問題があるとする声もあった。

そしてその後どうなったかと振り返ってみれば、最初のうちは更新があるかど うかの自動チェックから始まって、ダウンロードまでの自動化、インストール までの自動化と、徐々に全自動化が進められてきた。Microsoft自身、アップ デートのシステム的な確かさを確認しつつ進めてきたのだろうし、ユーザ達も、 どうやら大丈夫らしいということで、自動更新を徐々に受け入れてきた。安全 保障上の懸念についても、Microsoftの積極的なアピールで、それなりに信頼 が得られるようになってきたのだろうと思われる。

ところが、これに伴って、他のソフトウェアベンダー達のあいだにも、同様の 自動更新機能を自社のソフトウェアに組み込むところが増えてきた。データの 更新だけならよいが、プログラム自身も自動更新するものが増えてきている。 たとえば国内のマイナーなソフトウェアでも、自動更新機能が最初から有効に なっているものもある。

はたして、そうしたベンダーは、安全保障上の懸念がないほどに信頼できる会 社なのだろうか？ ソフトウェアを販売する段階では不正のないものを配給し ておき、普及したところで突如、悪意あるコードを配信するといった、狂った 行為が行われないとは限らない。

また、万が一、第三者の侵入などによって、悪意あるプログラムが自動更新サー バに不正にアップロードされてしまうと、大変なことが起きることになる。そ ういうことが絶対に起きないだけの十分な対策を、そうしたマイナーな会社た ちは、はたして実施しているのだろうか。

偽のアップデートコードが混入することを避けるには、コードに電子署名すれ ばよい。Windows Updateでは登場した当初から署名検証が行われていたと記憶 している。

SymantecのNorton Antivirusでは、古くから搭載されている「LiveUpdate」機 能において、バージョン1.6から、配布物に電子署名を付けて検証するように なった。1.4のバージョンにはそうした検証機能がないため、危険だという指 摘が、2001年10月にBUGTRAQに投稿されたことがあった。 指摘は、サーバに不正なコードがアップロードされる懸念だけでなく、クライ アントに近いところへの DNS spoofing攻撃によって、容易に偽コードにすり かえられてしまう危険性について述べている*1。

• Symantec LiveUpdate attacks, BUGTRAQ, 2001年10月5日
• シマンテックのツールにセキュリティーホール , セキュリティホールmemo, 2001年10月12日

このころようやく、自動アップデートには電子署名の検証が必須だとするコン センサスが業界で確立したように記憶している。

Apple Computerが MacOS Xに「SoftwareUpdate」機能を導入し、自動化を図ろ うとしたときも、同様の指摘を受けて、後に配布物に電子署名するようになっ たという経緯がある。

• AppleCare Document: 75304: This document contains the Security Update 7-12-2002, セキュリティホールmemo, 2002年7月15日

たしかに、署名なしでネット配布されているインストーラは沢山あるし、署名 されていても誰も検証せずに実行してしまっているという話がある。署名のな いプログラムのダウンロード実行を、セキュリティポリシーで禁止している組 織がどれだけあるだろうか。

だが、いつ誰がどこからダウンロードするかわからない実行形式ファイルを偽 にすりかえるのと違って、自動アップデートされるコードを偽に差し替える攻 撃は、攻撃の動機も強くなるうえ、もたらされる被害も甚大となる。なので、 少なくとも自動アップデートについては、配布するコードに電子署名しておく のが当然……というコンセンサスが確立しているのだろう。

というわけで、自動アップデート機能を提供していながら、配布コードに電子 署名をしていないというのは、それは脆弱性であると言ってよいかもしれない。

しかし、IPAにそれを届け出たとき、はたして脆弱性と認められるかどうかは、 かなり不確かだ。

少なくともウイルス対策ソフトはおそらく全部が、署名検証に対応しているは ずだろう。私は現在 Norton以外を使える状態にないので、今のところ確かめ ていないが、もし、署名検証をしていないものがあるとしたら、今回のような 大規模な障害が、外部から故意に引き起こされる可能性もある。そうなったら それはまさに「サイバーテロ」である。

■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法

「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。

クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。

前提

ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。

ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追跡（セッション管理）を行っているはずであり、それをcookieの値を頼りに 行っている場合、そのcookieの値は第三者には予測不能な値が選ばれているは ずである。（でなければ、セッションハイジャックされたり、なりすましログ インされてしまうのだから、CSRF以前の重大な欠陥があることになる。）

最も自然な方式では、ログインごとに発行するランダムな受付番号、つまり 「セッションID」を1個（ないし https:// 専用を含む2個）用いて、どのユー ザからのアクセスなのかを検索して特定する――(A)。この値を十数桁以上の 乱数とすることで、偶然に的中する確率を何億分の1までに小さくしている。

あまり適切ではないが何らかの都合でセッションIDを使わずに、cookieにユー ザIDを入れる方式となっている場合もあるが、それだけでは予測不能とはなら ないので、そうした場合はそのユーザのパスワードのハッシュ値などもcookie に格納して、ページ毎に両方を確認することによって、なりすましされないセッ ション追跡を実現することになる――(B)。この場合の予測不能性は、パスワー ドが予測不能なはずであることに立脚している。

CSRFを防ぐ必要があるのは、Webアプリケーションに対して何らかの恒久的な データ変更を発生させるアクセスとなるページ（登録情報変更、設定変更、退 会処理、注文実行、取り消しなど）である。たとえば、情報を表示するだけの ページには対策が不要、もしくは重要性が低い（後述の「2ページ目」など）。 ショッピングカートへの商品追加などのように、一時的な状態変更を加えるだ けのページに対するCSRF対策の重要性は低めとなる*1。

たとえば住所変更の機能を想定すると、1ページ目で現在の登録情報が入力欄 に埋め込まれて表示され、その入力欄の必要な部分を書き換えてボタンを押す と 2ページ目で確認画面となり、「変更」ボタンを押すと変更が処理されて 3 ページ目が表示されるという構成が多い。ここで、3ページ目に直接外部から ジャンプさせられると、住所を勝手に変更されてしまうことが起きる。

簡潔な対策方法

Webアプリケーションに対してデータ変更を処理させるページ（前述の「3ペー ジ目」）の前のページ（前述の「2ページ目」）に以下のHTML要素を含ませる。

 <input type="hidden" name="sessionid" value="セッション追跡用cookieの値"> 

そして、「3ページ目」で、そこに送信されてくるこの値が、cookieのその値 と一致しているかを調べて、一致しているときだけ処理を実行する。

「セッション追跡用cookieの値」には、前述の(A)方式ならばセッションIDの 値、(B)方式ならばユーザIDとパスワード（のハッシュ値など）の両方を格納 し、「3ページ目」でそれぞれの一致を確かめる。

第三者サイトから「3ページ目」へのハイパーリンク（JavaScriptによる自動 POSTを含む）が作られても、一致させる値を予測することは不能であるはずな ので、CSRF攻撃は成功しない。

制限事項

一致するかを確認するのは「3ページ目」だけでよいのか。そのままでは、 「2ページ目」へのハイパーリンクを作ることはできてしまう。しかしその場 合、被害者は「2ページ目」が現れたところで自発的に「3ページ目」へ進む ボタンを押さない限り被害に遭わない（XSS脆弱性など他の脆弱性がなければ）。

そこでボタンを押してしまいやすいかどうかは、「2ページ目」の画面内容に 依存する。たとえば、「本当に実行しますか？」以外に何も書かれていない 「2ページ目」である場合には、ボタンを押してしまうかもしれないので、 さらに前のページから同様の対策が必要となる。もっとも、ボタンを押すと何 が起きるのかを適切に説明しておくことは、もとより要求されるところである。

不適切な解説の例

• GETを使わずPOSTを使え。*2
• 実行の前に確認画面を挟め。*3
• Referer:は偽装できるので対策にならない。*4
• ワンタイムトークンを使わなくてはならない。*5
• ログインなしのWebアプリケーションに対するCSRF攻撃（掲示板荒らし） を防止するには、セッションIDやワンタイムトークンを使えばよい。*6
• 実行画面（「3ページ目」）に必要な情報を引数（hiddenを含む）に持た せず、「2ページ目」までにそれら必要な情報はセッション変数（Webアプリケー ション側で、セッションIDに結び付けて記憶している情報）に格納しておき、 「3ページ目」の処理ではそれを利用すればよい。*7

BASIC認証の場合

（続く）