2006年02月05日
■ 適切な脆弱性修正告知の習慣はなんとか広まらないものか
2日の日記の件について、伊藤直也さんからトラックバックを頂いた。話は2つに分ける必要がある。1つ目は、一般にソフトウェア開発者・配布者が、配布しているソフトウェアに脆弱性が見つかって修正版をリリースしたときに、ユーザに伝えるべきことは何か、また、どのような方法で伝えるべきかという話。2つ目は、JVN側の改善の余地の話。
1つ目の話
はてなは以前から、Webアプリに脆弱性の指摘があって修正した場合、それを「はてな○○日記」で事実関係を公表してきた*1。これは、他のWebサイトの大半がそうした公表をしていない*2のと比べて、先進的な対応であると言える。
しかし、今回のはてなツールバーの脆弱性は、Webアプリの脆弱性ではなく、「ソフトウェア製品の脆弱性」である*3。一般に、Webサイトの脆弱性は、修正した時点でその危険性は解消するという性質があるのに対し、ソフトウェア製品の脆弱性は、ユーザが修正版に置き換えるまでその危険性は解消されないのであるから、Webアプリの場合と違って、ソフトウェア製品の脆弱性を修正したときこそユーザへの周知徹底が必要である。
このことは、「ソフトウエア等脆弱性関連情報取扱基準」に定められているからということ以前に、ソフトウェア開発コミュニティの間で、この数年間、当然になすべきこととしてようやく定着しつつあるところであろう。たとえば、Mozillaプロジェクトでは、「Mozilla 製品における既知の脆弱性」というページで、セキュリティ脆弱性の修正を含むリリースが出るたびに、その修正内容を専用のページで公表しているし、Microsoft社は、90年代から「MS99-0XX」といった番号を付けた脆弱性情報を公表してきている。
ところが残念ながら、現在でも大手以外のソフトウェアベンダーのいくつかは、そうした告知を適切に行っていない。典型的なパターンは、セキュリティアップデート（脆弱性の修正を含むリリース）を通常の機能追加アップデートと区別せずに発表するもので、修正の事実が書かれている場合でも、リリースノートの更新履歴のようなところにチラっと書かれているだけというものがある。これは、小規模なオープンソースコミュニティやシェアウェアなどにも見られる悪習である。
開発者の立場からすれば、「リリースノートは全部読んでくれるはずだ」という思いがあるのかもしれないが、ユーザの立場からすれば、毎回細かな修正内容を把握しておきたいなどと思う人は稀であろう。普通の人にとって必要とされる情報は、「今、私はこれをインストールする必要があるのか？」であろう。
脆弱性の修正を含むリリースのときだけ通常と別の方法でユーザに知らせない限り、脆弱性の解消は進まないだろう。脆弱性情報専用のページを設けるか、せめて、リリースノートでそれがセキュリティアップデートであることを強調するべきであろう。
IPAの脆弱性届出窓口がなかったころは、直接ベンダーに脆弱性情報を通知していたが、ベンダーが適切な告知なく修正版をリリースした場合、発見者としては、「ユーザ達にアップデートの必要性を知らせなくては」という思いに駆られ、ベンダーが公表しなかった情報を公表することになる。「ベンダーとしては隠しておきたい情報なのかもしれない」と思うと、その行動は慎重なものとならざるを得ない。発見者が公表することには一定のリスクがあるのだから、表沙汰にならなかった事例もあるだろう。
こうした緊張を回避するために脆弱性届出制度は有効だと私は期待した。2003年1月のIPAのイベントでの基調講演で、ベンダーの公表方法についてのガイドラインのようなものが必要だということを訴えた。
ベンダーへの報告や公表には標準のようなものは存在せず、発見者が独自に行うしかない。報告されたベンダー側の対応方法も決まってはいない。権威付けのされたガイドラインがあれば、報告者もベンダーもそれに従って行動できる、ということで、こちらもガイドラインが必要だろう、とする。
【レポート】ソフト/Webの脆弱性対策のため、何が必要なのか, MYCOM PCWEB, 2003年1月24日
それから半年後、IPAに「情報システム等の脆弱性情報の取扱いに関する研究会」が設置され、私もメンバーとなり、いくつか意見を提供して、現在の届出制度が翌年の7月から開始されることとなった。しかし、ベンダーの公表方法についてのガイドラインは整備されなかった。
制度の運用が始まって、どんな公表が行われるだろうかと見ていたところ、やはり不適切な公表がしばしば出てきた。たとえば次などがそれにあたる。
- JVN#8F8B1C85: サイボウズ Office におけるブラウザスクリプト実行の脆弱性
この事例では、ベンダーからの提供情報は、「よくある質問と答え」へのリンクだった。脆弱性の内容については詳細に書かれていて良いが、どういう人がこのページを見に来るのか？ 質問のタイトルは、
「クロスサイトスクリプティング脆弱性」の影響を受けることはありますか？
になっているが、脆弱性の存在を知らない人へ告知が必要だというのに、知らない人がこの質問を捜しに来るわけがない。 - JVN#B4BE09A4: Shuriken Pro3 のS/MIME機能で署名検証時に証明書の真正性が確認されない
この事例では、一昨年12月21日の日記に書いていたように、影響を受けるバージョン番号と、修正版のバージョン番号が明記されないまま発表されていた。ユーザの立場からすれば、「自分は今パッチをあてないといけないのか？」ということが関心事なのであり、その判断のためにバージョン番号の確認が必要となるのに、どうしてその情報を発表することの必要性に気付かないのだろうか？
- JVN#42435855: FreeStyleWiki におけるコマンドインジェクションの脆弱性
この事例では、ベンダーの公表情報が通常のリリースノートの中に書かれており、通常の機能改善項目と一緒に書かれている。「脆弱性に対しての修正を含んでいます」という記述はあるものの、冒頭ではなく末尾に書かれている。
こうした告知方法には改善の余地があることは、ユーザの立場で考えてみることで自ずと気付くはずだと思えるのだが、なかなかこういう「輩」は後を絶たない。
そしてはてなツールバーの事例である。JVNが発表されるより前の1月27日付で、はてなツールバーホームページの「更新履歴」が改定されていた。
2006/1/27・・・v1.5.5
- URLがhttpsの場合、含むアンテナ、言及日記のために、はてなにURLを自動送信しないようにしました
- ヘルプページURLを変更しました
そして、同じ日の「はてなダイアリー日記」に「はてなツールバー、Hatenabarアップデート」が書かれていた。内容は更新履歴と同一である*4。はてなダイアリー日記は、普段からいろいろなことがたくさん書かれているところだが、ここをずっと読んでいないといけないのだろうか。
以上は、JVNや脆弱性届出以前の話として、私の個人的考えだ。「JVN のシステムの話」によると、
そういう状況で通常業務と平行しながら
というが、「はてなツールバー」の配布（とそれに付随する責任）は通常業務外だというのだろうか。
2つ目の話
「脆弱性情報の取扱いに関する研究会」では、私も勤務先の業務として参加し、ベンダーの告知方法に関するガイドラインが必要だということを、何度か意見として述べてきた。制度の運用が始まった後にも主張したが、どういうわけかあまり重要な課題として受け止められていないようだ。（業務に関する話なのでここにはあまり書かない。）
どんな情報を公表しなくてはならないかについて、ベンダーに強制することはできないだろう。ベンダーによっては、どんな種類の脆弱性かの公表を避ける*5ところもあるかもしれないが、それは自由であろう。だが、脆弱性情報を適切に告知してないベンダーが、本当に明確な意思によって、脆弱性情報の公表を避けているとは限らないと思われる。つまり、単に不慣れであるために、何をどのように公表したらよいかに思いが至らないというケースも少なくないのではないか。
そうした事例を救うために、告知方法の見本のようなものを出すことが効果的であるはずだ。ベンダーの自由を尊重しつつ、消費者が脆弱性情報を正確に知る機会を確保するという、バランスのとれた施策であると思う。
製品の脆弱性はJPCERT/CCがベンダーとやりとりすることになっているが、具体的にどんなやりとりがなされるのかは、「脆弱性情報コーディネーション概要」に掲載されている「JPCERT/CC 脆弱性関連情報取り扱いガイドライン」で窺い知ることができる。これには次の記述がある。
規約への合意と規約の遵守
JPCERT/CCの脆弱性情報ハンドリングの枠組みにご協力頂ける場合、JPCERT/CCが用意する「JPCERTコーディネーションセンター製品開発者リスト登録規約」に合意して頂く必要があります。製品開発者の皆様には、本枠組みへのご参加と共に、上記規約を遵守して頂きますようお願いします。
公表日一致の原則
（略）
４．調整：公表日時の決定
■脆弱性情報の一般公表日の設定に際して
冒頭の「覚えて頂きたい事項」にて記述した通り、脆弱性情報には一般公表日が設定されます。製品開発者の方は、対策情報なども含む脆弱性関連情報の公表に関して、一般公表日を遵守してください。
4-1. JPCERT/CC における公表日時の決定
脆弱性情報の一般公表日時は、製品開発者とJPCERT/CCが協議の上決定します。（略）
JPCERT/CCでは、一般公表日の決定の際には、JPCERT/CCが脆弱性関連情報の取り扱いを開始した日時から起算して45日後を目安とします。ただし、公表日時の決定の際には以下の点も考慮します。
（略）
6-1. 製品開発者における公表情報の作成
製品開発者の方は、脆弱性情報に関して公表可能な情報がある場合には、一般公表日までに、公表情報の作成もお願いします。内容は、以下の項目が含まれることを推奨します。参考にしてください。
- 脆弱性に該当する製品名およびバージョン
- 脆弱性の概要
- 脆弱性への対応状況 (注:詳細は6-2に記述)
- ワークアラウンドやパッチなどの対策方法
- 関連情報へのリンク
- 当該脆弱性情報に関する連絡先 （略）
どんな情報を公表するのが推奨されるかは、上のように一応書かれてはいる。だが、これではわからないベンダーも少なくないのではないか。なぜその情報の公表が求められるのか理由を示しつつ、具体的なお手本例を示すなどしないと、慣れていない人にはパッと見でわからないのだろうと思う。
そして、2日の日記で駄目だと書いた、消費者側に見えるJVNの「製品開発者からの提供情報」の部分が、ベンダー側にどのように説明されているかは、この文書の 6-2.節から窺い知ることができる。
6-2. JPCERT/CCへの対応状況の連絡
製品開発者の方は、自社の対応状況についてJPCERT/CCに連絡してください。その際には以下の項目を含めてください。JPCERT/CCではこれらの情報を元に、一般公表情報を作成します。
- JPCERT/CCが発行した識別番号
- 製品開発者名称(会社名)
- 製品の該当状況(以下1-4より選択)
1) 該当製品あり
2) 該当製品あり：調査中
3) 該当製品なし
4) 該当製品なし：調査中- 公表情報に記載するフリーフォーマットの文章 (URLや説明文など※注：6-3を参照のこと)
6-3. JPCERT/CCにおける公表情報の作成と公表
JPCERT/CCは、事前に設定された一般公表日時に、JVNを通じて脆弱性情報を一般に公表します。この際に公表されるのは以下の情報が含まれます
1)脆弱性情報の概要
2)脆弱性情報の影響範囲
3)脆弱性情報に対する製品開発者の対応状況
4)各製品開発者固有の情報（略）
また、上記4)の製品開発者固有の情報においては、6-2-4. においてJPCERT/CCに通知された情報を記載します。これらの情報の公表内容は、次ページのようなイメージになります。
（略）
図2：図1において、株式会社○○をクリックした際に表示される画面 「製品開発者からの提供情報」のフィールドには6-2-4.の内容が記載されます。
（画面略）
「公表情報に記載するフリーフォーマットの文章 (URLや説明文など※注：6-3を参照のこと)」という説明になっているが、ここがわかりにくくなっているようだ。「JVN のシステムの話」によると、
マニュアルとか、フォームのそばにある説明を見ても「CERT/CCへの情報提供(任意)」だっけかな、そんな一文が書いてるだけで何を書いたらいいか分からないのですよ。そこに書いて欲しい具体的な内容があるなら具体的にどういうことを書くかとか、そういうのがないと分からないですね。
（略）
追記
一応誤解を与えないように追記しておきます。何か情報を書くのが嫌だっていうことではなくて、何を書いたらいいかが示されてないコメント欄で、且つ「任意」とまで書かれている箇所に書かれたことを批判されているのに対する疑問です。
だという。「任意」と書かれているらしいが、私は記入システムを見せてもらったことがないので、私も知らない。
この欄が「任意」というのはおかしいのではないか。おそらく、複数ベンダーのケースで、「該当製品なし」のベンダーが記入するときには書かなくて良い欄であるために「（任意）」と書かれているのではないか。それは誤解させるだろう。
2日の日記でJVNが駄目だと書いたのは、普段からJVNのページを見ている人でも、 「株式会社○○の JVN#XXXXXXXX への対応」のページを見ても、それがベンダー自身によって編集されているページだということが伝わっていない（JVNによって編集されていると思っている人も少なくない）のではないかと思っていたからだ。これを記入するベンダーは、この画面を見たことがあっても、自分が書いたものがここに表示されることに気付けないのではないか。
どうも、JVNは工夫が足りなさすぎるように思えてならない。他にも変なところがあって、たとえば、JVN#A7DA6818: WebUD における任意のプログラムが実行される脆弱性のケースでは、
製品開発者リスト登録ベンダ （＊2005年 6月 9日より リンク先を変更）
| ベンダ情報 | 提供情報(ステータス) | 更新日 |
|---|---|---|
| 富士通 | 該当製品あり | 2005/10/04 |
という表になっているが、「富士通」というリンクをジャンプしたときに、何が表示されるかが非直感的だ。
じつはこの「富士通」のリンク先は、この脆弱性の告知ページになっていて、公表当時、「該当製品あり」のリンク先の「製品開発者からの提供情報」は空白になっていた。そのとき、「該当ありなのに情報なし？」と思ったが、「富士通」のリンク先を見ればよかったわけだ。そんなことが誰にわかるというのか？
いちおう「＊2005年 6月 9日より リンク先を変更」という注意書きがあって、そこに「ベンダ情報」欄の読み方が説明されているわけだが、説明を読まないとわからないようなユーザインターフェイスは駄目だ*6。
表の左列はベンダーの一覧なのだから、そこに重要なリンクを設けるのは直感に反する。「ベンダ情報」では意味がかわからない。ステータス表示欄を重要情報へのリンクと兼ねるという設計も駄目だ。たとえば次のようにするのが普通だろう。
| ベンダ | ベンダの告知ページ | ステータス | ベンダからの提供情報 |
|---|---|---|---|
| 富士通 | WebUD における任意のプログラムが実行される脆弱性 | 該当製品あり | 2005/10/04 更新 |
| 四万十テクノロジー | 該当製品なし | なし |
こういうのって、読む人の立場を考えればわかるもんじゃないか？ これ作ってる人達は何も考えてないとしか思えないんだが。
■ 「はてなツールバー」がHTTPSサイトのURLを平文のまま送信していた問題
昨年11月27日に「ウイルスバスター2006はHTTPSサイトのURLもトレンドマイクロに送信する」と「Googleツールバーは「?」以降を送信しないしHTTPSのときも送信しない」という日記を書いた。
Googleツールバーでは httpsサイトの場合は何も送信しないようになっているし、ウイルスバスター2006の場合では、トレンドマイクロに送信されるURLは（いちおう）暗号化されていた。
この日記に対するはてなブックマークに、「はてなツールバーはどんな仕様？」というコメントがあったため、早速、はてなツールバーをダウンロードしてインストールし、確認してみた。 すると、はてなツールバーは、Googleツールバーと違って、「?」以降を送信するし、httpsのページのURLも送信するようになっていた。そのときの通信内容は次の通りであった。
GET /exist?mode=xml&url=%68%74%74%70%73%3a%2f%2f%77%77%77%2e%69%70%61%2e%67%6f%2e%6a %70%2f%66%6f%6f%3f%73%65%73%73%69%6f%6e%69%64%3d%30%30%30%30%30%30%30%30 HTTP/1.1 User-Agent: HatenaToolbar/20050607 Host: d.hatena.ne.jp HTTP/1.1 200 OK Date: Tue, 29 Nov 2005 19:07:55 GMT Server: Apache/1.3.27 (Unix) (Vine/Linux) mod_perl/1.29 Content-Type: application/xml; charset=utf-8 Vary: Accept-Encoding Transfer-Encoding: chunked 6f <?xml version="1.0"?> <existxml> <count name="diary">0</count> <count name="antenna">0</count> </existxml>
「%XX」でエンコードされているところをデコードしてみると、送信されている情報は以下であった。
/exist?mode=xml&url=https://www.ipa.go.jp/foo?sessionid=00000000
これは脆弱性に該当すると思い、11月30日にIPAにソフトウェア製品の脆弱性情報として届け出た。以下は、届け出た文書からの抜粋である。
2005年 11月 30日 （略） 2) 脆弱性を確認したソフトウエア等に関する情報 はてなツールバー http://www.hatena.ne.jp/tool/toolbar 3) 脆弱性の種類 ブラウザでHTTPSサイトにアクセスした際に、アクセス先URLの全部が、暗号化 されることなく、HTTPで d.hatena.ne.jp の 80 番ポートへ送信される。 4) 再現手順 1. http://www.hatena.ne.jp/tool/toolbar の手順によりインストールする。 2. はてなツールバーの設定で、以下などをオンにする。 「ページ移動時に言及している日記をチェックする」 この設定をオンにすると、 http://www.hatena.ne.jp/tool/toolbar に > はてなアンテナの「ページ移動時に含むアンテナをチェックする」、はてなブッ > クマークの「ページ移動時に追加しているユーザ数をチェックする」、はてな > ダイアリーの「ページ移動時に言及している日記をチェックする」のいずれか > の機能を有効にしている場合、はてな外を含めた全てのウェブページ閲覧時に、 > 閲覧中のウェブページのURLがはてなサーバーに送信されます。これは、その > ページに関する情報をはてなサーバーから受け取るためです。 と書かれているように、IEがどこかのURLにアクセスするたびに、そのURL がはてな側に送信されることになる。 3. パケットキャプチャで自分自身の通信内容のキャプチャを開始する。 4. IEで、 https://www.ipa.go.jp/foo?sessionid=00000000 にアクセスする。 5. パケットキャプチャの記録に、以下のHTTP通信があったことが示される。 --------------------------------------------------------------------- localhost -> 61.196.246.67(80) GET /exist?mode=xml&url=%68%74%74%70%73%3a%2f%2f%77%77%77%2e%69%70%61%2e%67%6f%2e%6a %70%2f%66%6f%6f%3f%73%65%73%73%69%6f%6e%69%64%3d%30%30%30%30%30%30%30%30 HTTP/1.1 User-Agent: HatenaToolbar/20050607 Host: d.hatena.ne.jp HTTP/1.1 200 OK Date: Tue, 29 Nov 2005 19:07:55 GMT Server: Apache/1.3.27 (Unix) (Vine/Linux) mod_perl/1.29 Content-Type: application/xml; charset=utf-8 Vary: Accept-Encoding Transfer-Encoding: chunked 6f <?xml version="1.0"?> <existxml> <count name="diary">0</count> <count name="antenna">0</count> </existxml> 0 --------------------------------------------------------------------- 上の「url=」の部分をURLデコードすると、 https://www.ipa.go.jp/foo?sessionid=00000000 となることから、はてなツールバーは、https:// のページにアクセスした場 合であっても、URLの全体（「?」以降を含む）を暗号化せずに TCPで送信して しまうことがわかる。 5) 再現の状況 （略） 6) 脆弱性により発生しうる脅威 ログイン機能を持つWebサイトの一部には、ログイン状態を保つために使うセッ ションIDなどの情報（秘密にすべき情報）を、URLに含める構成をとっている ものがある。これは、cookieをサポートしていないブラウザや、cookieをオフ にしているユーザからのアクセスがあったときに、自動的にセッションIDを URLに含めるようになっているものである。 そのようなサイトでは、もしURLを攻撃者に知られると、攻撃者によってその セッションIDを含むURLへアクセスされ、セッションをハイジャックされてし まうことになる。一般にURLはRefererによってリンク先のサイトに送信される 性質があるので、そのような構成をとるWebサイトでは、外部サイトへのリン クを設置しないことで、URLが他のサイトへ送信されないよう対策をとってい るはずである。 しかし、はてなツールバーを使用しているユーザは、たとえWebサイトがその ような対策をとっていても、ツールバーによって、アクセスするURLが暗号化 されずに送信されてしまう。そのため、攻撃者のパケット盗聴によってセッショ ンIDを盗まれてしまう。 すなわち、はてなツールバーのこの機能を使用することは、SSLで保護された Webサイトの一部の構成をとるものにおいて、セッションハイジャックの危険 性を新たに生じさせることになる。 7) 回避策 これらの機能をオフにする。 8) 検証コード* 再現手順の通り。 9) その他 標準に関する検討 HTTP/1.1を規定した RFC 2616 の「15 Security Considerations」には次の 記述がある。 > Clients SHOULD NOT include a Referer header field in a (non-secure) > HTTP request if the referring page was transferred with a secure > protocol. この規定は、https:// のURLが non-secure な通信に含まれることがないよ う配慮したものである。したがって、サードパーティのWebブラウザ拡張も、 https:// のURLが non-secure な通信に含まれないように配慮するべきであ ると一般に考えられていると類推できる。 解決策の案 (A) https:// ページへのアクセスではこの機能が働かないようにする。 (B) https:// ページへのアクセスでは d.hatena.ne.jp への接続も SSLで 行うようにする。 3. IPA 以外の組織への届出について （以下略）
11月30日に届け出たものが、1月27日に修正版が出ていた。
■ 閲覧しているページのURLを送信するツールバー類のリスクとその機能説明
はてなツールバーは、ダウンロードページにおいて、
閲覧中のウェブページの情報について
はてなアンテナの「ページ移動時に含むアンテナをチェックする」、はてなブックマークの「ページ移動時に追加しているユーザ数をチェックする」、はてなダイアリーの「ページ移動時に言及している日記をチェックする」のいずれかの機能を有効にしている場合、はてな外を含めた全てのウェブページ閲覧時に、閲覧中のウェブページのURLがはてなサーバーに送信されます。これは、そのページに関する情報をはてなサーバーから受け取るためです。
当社は、これらのプライバシー情報の保護に最大限の注意を払います。当社のプライバシーに対する考え方の詳細については、はてなプライバシーポリシーを参照ください。
と説明しているように、任意のサイトのページにアクセスするたびに、アクセスしたURLをはてなに送信するようになっている。これは、今見ているページが「はてなブックマーク」などに何件登録されているか（図1の矢印部分）をリアルタイムに表示するために必要としている仕掛けだ。
プライバシーに関わる機能であるので、「プライバシー情報の保護に最大限の注意を払います」とされて、プライバシーポリシーが示されているわけだが、企業などにおいては、たとえプライバシーポリシーが示されていても、こうした機能を社員に使わせない運用をしているところもあるかもしれない。
つまり、社内ネットワーク上の社外秘Webサーバに社員がアクセスするとき、そのURLが社外に送信されてしまう事態を避けるために、こうした機能を持つツールバーの使用を禁止するという運用があり得る。
そういうこともあるので、こうした機能が存在することの通知は重要であり、Googleツールバーもそうした告知をしている。Googleツールバーのインストール時には、図2の重要事項説明画面が現れる。
赤字で「このセクションをよくお読みください。重要な情報が含まれています。」と注意書きがあるうえ、「有効にする」か「無効にする」を選択しないと次のステップへ進めないようになっている。
これに比較すると、はてなツールバーのインストーラの説明（図3）はいささか心もとない。
含むダイアリー・アンテナ・ブックマーク機能を有効にする（見ているページの情報がはてなに送信されます）
はたして「見ているページの情報」という表現で、ユーザ達にその意味が伝わっているだろうか。
ダウンロードページには注意書きがあるわけだが、これまで使っていたユーザ達が、何が起きているかを理解して使っていたかどうか、気になるところだ。
ところで、ウイルスバスター2006はその後どうなっただろうか。
使用許諾契約書は改定されていないようだし、現在配布されているインストーラでも、URLが送信されることを通知する重要事項説明画面は出てこないようだ。
ただ、ウイルスバスター本体のUIが改善されたようだ。「フィッシング詐欺対策ツールバーを使用する」の設定を有効にする操作を行ったとき、図4の警告が出るようになった。
なお、本機能を有効にすると、お客様がアクセスしたURLの情報が、暗号化されたうえでサーバ送信されます。サーバ送信されたURL情報は、Webサイトの安全性の確認、および本機能の改良の目的にのみ利用されます。
これだけなのだろうか。これで意味がわかるのだろうか。一般のユーザ達に、これが何を意味するのか理解できたかと聞いてみたいところだ。
「サーバ送信」という謎の言葉が使われている。どこに送信するかは書かれていない。「サーバ送信」なのだから、普通のWebサーバアクセスのことを言っているかのように読み取る人もいそうだ。なぜ本当のことを書くことから逃げるのか。
*1 たとえば、最近でも2月3日に、指摘があってXSS脆弱性を修正したと報告されている。
*2 IPAの脆弱性情報届出制度の根拠となっている「ソフトウエア等脆弱性関連情報取扱基準」においては、Webアプリの脆弱性について、ウェブサイト側は事実関係を公表しなくてはならないとされているわけではない。次のように、公表の必要性を、個人情報漏えいが実際に起きた場合などに限定している。
ウェブサイト運営者は当該脆弱性に起因する個人情報の漏えい等の事案が発生した場合、二次被害の防止、類似事案の発生回避等の観点から、可能な限り事実関係等を公表するなど必要な対策をとること。
*3 「ソフトウエア等脆弱性関連情報取扱基準」には次のようにある。
（６）製品開発者は、対策方法を作成した場合、受付機関及び調整機関に報告し、脆弱性情報公 表日以降、自らもそれを利用者に周知すること。
*4 「JVN のシステムの話」が書かれた後の時刻に、「はてなツールバー、Hatenabar のアップデートのお願い」がはてなダイアリー日記に追加された。
*5 ユーザがアップデートの必要性を正確に理解できなくなるというデメリットがある。
*6 というか、読んでもわからない。さらに言えば、「製品開発者リスト登録ベンダ」のリンクも何が言いたいのだかわからない。どうしてこんな糞デザインで満足できるのか理解しかねる。
