最新 追記

高木浩光@自宅の日記

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

2006年02月02日

掲載されなかったamazon書評

1月14日の日記を書いた後、amazon.co.jpの当該書籍に書評を投稿した。amazonの書評の投稿は初めてだったので、レビューガイドラインを読みながら書いたのだったが、残念ながら採用されなかったようだ。以下に投稿した文を掲載しておく。

セキュリティへの配慮が欠落した脆弱本, 2006/1/15

レビュアー: 高木浩光 (東京都) - レビューをすべて見る

この本にはセキュリティ脆弱性を防止する観点が完全に欠落している。サンプルコードの大半にクロスサイトスクリプティング脆弱性があり、ログイン機能を作ってみせる例題では、典型的なSQLインジェクション脆弱性があって、パスワードに「'or'A'='A」と入力するだけで誰でも認証をスキップして不正ログインできてしまう。これらHTML出力、SQL文の構成に関する正しいコーディング手法は、後付けの「対策」として学ぶのではなしに、最初の段階で叩き込むべき最も基礎的な事項である(でなければ、セキュリティ以前に正しい動作さえしない。例えばログイン機能の例題プログラムでは「'」を含むパスワードを利用するとエラーになってしまう)PHPはそれ自身Web用言語であるのだから、「セキュリティのことは後で」という言い訳はありえない。消費者の個人情報を危険にさらす欠陥Webサイトは、孫請け零細業者に雇われた素人プログラマが、こうした本だけを頼りに作っている。脆弱プログラマを量産する著名な脆弱書籍の罪は大きい。著者らはその社会的責任を知るべきである。

JVNはやっぱり駄目

以下はJVN: 株式会社はてなの JVN#77886599 への対応 から 2月1日時点の内容の転載。

公表日 2006/02/01
最終更新日 2006/02/01
状態 : 該当製品あり 	JVN#77886599
 
製品開発者からの提供情報

    修正済みです。

更新履歴
(略)

何?これ。「修正済みです。」だけ?

誰(どの組織)が書いたか不明(JVN編集者が書いているようにも読めなくもない)なのは、システムに問題があるのではないか。署名欄でも設けたらどうか。自由書式だからこういう輩が出てくるのだから、記入様式を用意したらいいのに。

本日のリンク元 TrackBacks(100)

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が発表されるより前の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.調整:公表日時の決定

■脆弱性情報の一般公表日の設定に際して

冒頭の「覚えて頂きたい事項」にて記述した通り、脆弱性情報には一般公表日が設定されます。製品開発者の方は、対策情報なども含む脆弱性関連情報の公表に関して、一般公表日を遵守してください。

4-1. JPCERT/CC における公表日時の決定

脆弱性情報の一般公表日時は、製品開発者とJPCERT/CCが協議の上決定します。(略)

JPCERT/CCでは、一般公表日の決定の際には、JPCERT/CCが脆弱性関連情報の取り扱いを開始した日時から起算して45日後を目安とします。ただし、公表日時の決定の際には以下の点も考慮します。

(略)

6-1. 製品開発者における公表情報の作成

製品開発者の方は、脆弱性情報に関して公表可能な情報がある場合には、一般公表日までに、公表情報の作成もお願いします。内容は、以下の項目が含まれることを推奨します。参考にしてください。

  • 脆弱性に該当する製品名およびバージョン
  • 脆弱性の概要
  • 脆弱性への対応状況 (注:詳細は6-2に記述)
  • ワークアラウンドやパッチなどの対策方法
  • 関連情報へのリンク
  • 当該脆弱性情報に関する連絡先 (略)

JPCERT/CC 脆弱性関連情報取り扱いガイドライン

どんな情報を公表するのが推奨されるかは、上のように一応書かれてはいる。だが、これではわからないベンダーも少なくないのではないか。なぜその情報の公表が求められるのか理由を示しつつ、具体的なお手本例を示すなどしないと、慣れていない人にはパッと見でわからないのだろうと思う。

そして、2日の日記で駄目だと書いた、消費者側に見えるJVNの「製品開発者からの提供情報」の部分が、ベンダー側にどのように説明されているかは、この文書の 6-2.節から窺い知ることができる。

6-2. JPCERT/CCへの対応状況の連絡

製品開発者の方は、自社の対応状況についてJPCERT/CCに連絡してください。その際には以下の項目を含めてください。JPCERT/CCではこれらの情報を元に、一般公表情報を作成します。

  1. JPCERT/CCが発行した識別番号
  2. 製品開発者名称(会社名)
  3. 製品の該当状況(以下1-4より選択)
    1) 該当製品あり
    2) 該当製品あり:調査中
    3) 該当製品なし
    4) 該当製品なし:調査中
  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.の内容が記載されます。

(画面略)

JPCERT/CC 脆弱性関連情報取り扱いガイドライン

「公表情報に記載するフリーフォーマットの文章 (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の矢印部分)をリアルタイムに表示するために必要としている仕掛けだ。

図1: はてなツールバーが、閲覧中ページのブックマーク等への登録件数を表示している様子

プライバシーに関わる機能であるので、「プライバシー情報の保護に最大限の注意を払います」とされて、プライバシーポリシーが示されているわけだが、企業などにおいては、たとえプライバシーポリシーが示されていても、こうした機能を社員に使わせない運用をしているところもあるかもしれない。

つまり、社内ネットワーク上の社外秘Webサーバに社員がアクセスするとき、そのURLが社外に送信されてしまう事態を避けるために、こうした機能を持つツールバーの使用を禁止するという運用があり得る。

そういうこともあるので、こうした機能が存在することの通知は重要であり、Googleツールバーもそうした告知をしている。Googleツールバーのインストール時には、図2の重要事項説明画面が現れる。

図2: Googleツールバーのインストーラが表示する重要事項説明画面

赤字で「このセクションをよくお読みください。重要な情報が含まれています。」と注意書きがあるうえ、「有効にする」か「無効にする」を選択しないと次のステップへ進めないようになっている。

これに比較すると、はてなツールバーのインストーラの説明(図3)はいささか心もとない。

図3: はてなツールバーのインストーラにおけるプライバシー関連機能の選択画面

含むダイアリー・アンテナ・ブックマーク機能を有効にする(見ているページの情報がはてなに送信されます)

はたして「見ているページの情報」という表現で、ユーザ達にその意味が伝わっているだろうか。

ダウンロードページには注意書きがあるわけだが、これまで使っていたユーザ達が、何が起きているかを理解して使っていたかどうか、気になるところだ。

ところで、ウイルスバスター2006はその後どうなっただろうか。

使用許諾契約書は改定されていないようだし、現在配布されているインストーラでも、URLが送信されることを通知する重要事項説明画面は出てこないようだ。

ただ、ウイルスバスター本体のUIが改善されたようだ。「フィッシング詐欺対策ツールバーを使用する」の設定を有効にする操作を行ったとき、図4の警告が出るようになった。

図4: ウイルスバスター2006でフィッシング詐欺対策ツールバー設定時に出る警告

なお、本機能を有効にすると、お客様がアクセスしたURLの情報が、暗号化されたうえでサーバ送信されます。サーバ送信されたURL情報は、Webサイトの安全性の確認、および本機能の改良の目的にのみ利用されます。

これだけなのだろうか。これで意味がわかるのだろうか。一般のユーザ達に、これが何を意味するのか理解できたかと聞いてみたいところだ。

「サーバ送信」という謎の言葉が使われている。どこに送信するかは書かれていない。「サーバ送信」なのだから、普通のWebサーバアクセスのことを言っているかのように読み取る人もいそうだ。なぜ本当のことを書くことから逃げるのか。

*1 たとえば、最近でも2月3日に、指摘があってXSS脆弱性を修正したと報告されている。

*2 IPAの脆弱性情報届出制度の根拠となっている「ソフトウエア等脆弱性関連情報取扱基準」においては、Webアプリの脆弱性について、ウェブサイト側は事実関係を公表しなくてはならないとされているわけではない。次のように、公表の必要性を、個人情報漏えいが実際に起きた場合などに限定している。

ウェブサイト運営者は当該脆弱性に起因する個人情報の漏えい等の事案が発生した場合、二次被害の防止、類似事案の発生回避等の観点から、可能な限り事実関係等を公表するなど必要な対策をとること。

*3 「ソフトウエア等脆弱性関連情報取扱基準」には次のようにある。

(6)製品開発者は、対策方法を作成した場合、受付機関及び調整機関に報告し、脆弱性情報公 表日以降、自らもそれを利用者に周知すること

*4 「JVN のシステムの話」が書かれた後の時刻に、「はてなツールバー、Hatenabar のアップデートのお願い」がはてなダイアリー日記に追加された。

*5 ユーザがアップデートの必要性を正確に理解できなくなるというデメリットがある。

*6 というか、読んでもわからない。さらに言えば、「製品開発者リスト登録ベンダ」のリンクも何が言いたいのだかわからない。どうしてこんな糞デザインで満足できるのか理解しかねる。

本日のリンク元 TrackBacks(100)

2006年02月06日

Mozillaで弱い暗号を使わない設定と銀行サイトで利用可能な暗号

以下は、昨年10月16日に書き始めたものの、頓挫していた日記ネタである。書き終わっていないが、ワケあって今日、取り急ぎ放出する。以下の表にある調査内容は、昨年10月16日時点のものであり、現在もこの状態であるとは限らない。


職場では隣の席にいる大岩さんの自宅の日記に、Mozillaで弱い暗号の使用を無効にする方法が書かれている。

私は9月8日の日記で、

サーバ側がSSL 2.0しかサポートしていないWebサイトにアクセスすると、弱いプロトコルで通信させられることになるので、ユーザの自衛策として、ブラウザの設定で「SSL 2.0を使用する」をオフにしておいた方がよいということになる。

と書いたが、本来は、SSLをオフにすることは必須ではない。なぜなら、アクセス先がSSL 3.0以降を稼動させているサイトだと信用済みであるなら、SSL 2.0のチェックボックスはオンでもかまわないからだ。

というのは、SSL 3.0以降を使用しているサーバへの接続において、通信路上における第三者の攻撃によって、SSL 2.0へバージョンロールバックする攻撃はできないように、SSL 3.0が設計されているからだ。

ところが、先日の(編集時註: 昨年10月11日のこと)JVN#23632449: OpenSSL におけるバージョン・ロールバックの脆弱性がサーバ側に存在すると、通信路上の攻撃によって、SSL 2.0の使用を強要されてしまうことになる。

そうした事態に備えた自衛策として、ブラウザの設定で「SSL 2.0を使用する」をオフにしておくことは有効である。

また、サーバ側で、SSL 2.0を使えなくしてしまうことも意義があるかもしれない。

さて、「128ビットSSL」の使用を謳っている銀行各社は、SSL 2.0の設定をどのようにしているだろうか。これを調査してみた。

調査方法は、ブラウザの設定でSSL 2.0だけを有効にして(SSL 3.0とTLSを無効にする)、当該SSLサイトにアクセスし、正常に接続されたなら、サイト側でSSL 2.0を利用可能にする設定がされていると判断した。

加えて、各暗号アルゴリズムが利用可能になっているかも調査してみた。「Mozilla Firefox における弱い暗号化を無効化する設定」と同様の方法で、逆に特定の暗号方式(弱いもの)だけを有効にして、正常に接続してしまうかを調査したものである。

(編集時註: 昨年10月16日の時点での調査結果)

AES*13DES*2128ビットRC4*3低程度暗号*4*5SSL2.0*6
郵便貯金 対応 利用可能 利用可能 利用可能 利用可能
東京三菱銀行 非対応 利用可能 利用可能 エラー表示(A)*7 拒否
みずほ銀行 非対応 利用可能 利用可能 利用可能 拒否
三井住友銀行 非対応 エラー表示(B)*8利用可能 エラー表示(B) 拒否
UFJ銀行 非対応 利用可能 利用可能 利用可能 拒否
りそな銀行 対応 利用可能 利用可能 動作不良(空白画面が現れる) 利用可能
新生銀行 非対応 利用可能 利用可能 エラー表示(C)*9 利用可能
イーバンク銀行 非対応 利用可能 利用可能 動作不良(応答しない) 動作不良「このページにはデータがありません。」
ジャパンネット銀行 非対応 利用可能 利用可能 拒否 利用可能
ソニー銀行 非対応 利用可能 利用可能 拒否 利用可能
アイワイバンク銀行 非対応 非対応 利用可能 拒否 利用可能
シティバンク 非対応 エラー表示(D)*10 利用可能 エラー表示(D) 拒否
横浜銀行*11 www2.ib-center.gr.jp*12 非対応 利用可能 利用可能 利用可能 利用可能
北海道銀行 www2.paweb.anser.or.jp 対応 エラー表示(E)*13 利用可能 エラー表示(E) または 動作不良(空白画面が現れる) 利用可能
八十二銀行 www8b.cyber-biz.ne.jp 非対応 エラー表示(F)*14 利用可能 利用可能 拒否
北陸銀行 非対応 利用可能 利用可能 利用可能 利用可能
百五銀行 非対応 利用可能 利用可能 エラー表示(G)*15 利用可能
十六銀行 www9a.cyber-biz.ne.jp 非対応 エラー表示(F) 利用可能 エラー表示(F) 拒否
百十四銀行 www9d.cyber-biz.ne.jp 非対応 エラー表示(F) 利用可能 エラー表示(F) 拒否
足利銀行 www11a.cyber-biz.ne.jp 非対応 エラー表示(F) 利用可能 エラー表示(F) 拒否

この結果から、次のことが言えそうだ。

  • AESはまだあまり普及していない。これが普及するのが理想的。
  • 128ビットRC4は、すべてで利用可能になっている。
  • 3DESは、利用できないようにしているところもある。
  • 低程度暗号の利用を許している銀行がある。これ自体は脆弱性ではないが、許しておく必要性がないと思われる。
  • SSL 2.0の利用を許している銀行がある。これ自体は脆弱性ではないが、許しておく必要性がないと思われる。

ブラウザ側でのAES対応が普及していない現時点では、理想はこうだろうか。

AES3DES128ビットRC4低程度暗号SSL2.0
対応利用可能利用可能エラー表示拒否

もしくは、こう?

AES3DES128ビットRC4低程度暗号SSL2.0
対応利用可能エラー表示エラー表示拒否


以上、10月に書き始めた際には、ここまでしか書いていなかった。この後、書きたかったことは、次などであった。

  • 3DESと128ビットRC4ではどっちが強い?
  • 3DESを拒否して、128ビットRC4を許しているところがあるのはなぜ?
  • 低程度暗号を許していると何か問題があるか? (ブラウザ設定が通常であれば、AESか 3DESか 128ビットRC4が選択されるはず)
  • SSL2.0を許していると何か問題があるか? (ブラウザ設定が通常であれば、SSL 3.0か TLSが選択されるはず)
  • 低程度暗号で「エラー表示」が理想的とする理由
  • SSL 2.0で「拒否」が理想的とする理由
  • この表から、どの銀行が良いとか悪いとか言える?

*1 aes以外を全部オフにしてアクセスしたときSSL接続できるかどうか。

*2 rsa_rc2_40_md5 と rsa_rc4_40_md5 以外を全部オフにしてアクセスしたとき、非対応: SSL接続できない, エラー表示: SSL接続はできるがログイン画面が出ない, 利用可能: ログイン画面が正常に表示される

*3 rsa_rc4_128_md5 と rsa_rc4_128_sha 以外を全部オフにしてアクセスしたとき、以下同上。

*4 「低程度」はFirefoxが出す警告の表現から。

*5 rsa_rc2_40_md5 と rsa_rc4_40_md5 以外を全部オフにしてアクセスしたとき、拒否: SSL接続できない, 以下同上。

*6 SSL 2.0だけをオンにしてアクセスしたとき、以下同上。

*7 エラー表示(A): 「ご利用のブラウザではセキュリティ上、アクセスできません。」

*8 エラー表示(B): 「ご利用頂けないブラウザをお使いになっているか、ブラウザの設定が正しくない可能性があります。」

*9 エラー表示(C): 「The page must be viewed with a high-security Web browser」

*10 エラー表示(D): 「お使いのインターネットブラウザはシティバンク オンラインの標準セキュリティを使えませんのでシティバンク オンラインをご利用いただけません。」

*11 地銀はGoogle検索順。

*12 同一サーバで稼動しているものは以下では省略。

*13 エラー表示(E): 「ご使用のブラウザがSSL128ビットに対応していないため、サービスをご利用できません。」

*14 エラー表示(F): 「お使いのブラウザの暗号化方式では、お客様の情報を安全に保護することが出来ません。SSL128ビット対応のブラウザをご使用いただくか、ブラウザのセキュリティ設定をご確認ください。」

*15 エラー表示(G): 「Forbidden あなたのクライアントはオブジェクトに対するアクセスを許可されていません。」

本日のリンク元 TrackBack(0)

2006年02月09日

フィッシング対策協議会が、VISAの信用を貶める誤報を誘発

1月27日付で「VISAのシステムがハッキング被害、フィッシングに注意」という報道が飛び交っていた。記事の内容はこうだ。

フィッシング詐欺対策協議会は1月26日、VISAカードをかたるフィッシングメールとサイトについて注意を呼びかけている。これは、Visaのシステムがハッカーによる被害を受けたためで、「システムの変更が発生するため、自身のアカウントを確認する」といった内容の英文のメールが出回っている。(略)

VISAのシステムがハッキング被害、フィッシングに注意, Scan Daily Express, 2006年1月27日

何か変だ。

フィッシング対策協議会のサイトを見に行ってみると、1月26日付で、こんなものが掲示されていた。

図1: フィッシング対策協議会の「最新フィッシング情報」

概要:
Visaのシステムがハッカーによる被害を受けたため、システムの変更が発生するため、自身のアカウントを確認を促されます。

なんじゃこりゃ。

しばらく目が点になったが、ようするにこういうことらしい。「画像のクリックで大きな画像がご覧いただけます」とある画像(当該偽サイトの画面)*1を見てみると、偽サイトにはこう書かれていたそうだ。

Attention

Because of frequent hacker and charlatan attacks several visa bases have been stolen. Your card might be in the lost base and have already fallen among thieves. (略)

訳: 度重なるハッカーと大ぼら吹きの攻撃により、いくつかのVISA母体は盗難に遭いました。あなたのカードは、盗まれた母体に含まれていて既に泥棒たちの手に落ちているかもしれません。

つまり、「Visaのシステムがハッカーによる被害を受けたのでカード番号を入れてね」と、偽サイトでphshing詐欺師が言っているということだ。

それを指して、フィッシング対策協議会は、

概要:
Visaのシステムがハッカーによる被害を受けたため、システムの変更が発生するため、自身のアカウント確認促されます。

とおっしゃる。日本人じゃない人が書いているのだろうか?

正しくはこう言いたいのだろう。

偽サイトは、「Visaのシステムがハッカーによる被害を受けてシステムの変更が必要になった」と称して、アカウントの確認を促してきます。

だが、さらによくわからないのは、この部分だ。

事例:VISAカードをかたるフィッシングメールとサイト

題名:Visaをかたるフィッシングメール(英文)とサイト

なぜ、「事例」と「題名」が同じになっているのだろう? というか、「題名」って何だ?

「送信者」と「送信日時」という項目と並んでいることから察するに、ようするにこの「題名」というのは、phishingメールの「Subject:」欄に何が書いてあったかを表示する場所じゃないのか? つまり、この「最新フィッシング情報」というのは、偽メールの、From:、Subject:、Date:、と本文を掲示するところとして設計されている*2のではないか。「題名」は偽メールの題名を書くところなのに、「Visaをかたるフィッシングメール(英文)とサイト」というのはおかしくないか?

「概要」欄というのは、偽メールの本文の概要を示すところではないのか? だから、偽サイトに書いてあったことをそのまま「概要」欄に書いたということではないか? そのわりには、「確認を促されます」というのはおかしい。

なんか、もうグダグダだ。書いているのは、phishingが何であるかすら理解していない素人事務作業員か、はたまた、日本語さえ不自由な機械翻訳ボットなのか。

「VISAがハッキング被害」などという報道被害を自ら招くフィッシング対策協議会って、いったい? こんなクソサイトはさっさと閉鎖してしまえばいいのに。

まあ、「部屋だけ作って中には誰もいない」というのは、サイトのイメージ画像が最初から暗示していたのだが。

図2: フィッシング対策協議会のイメージ画像

追記(2月10日)

Scanの記事については訂正が出た。

それに対して、原因を作ったフィッシング対策協議会の方はというと、問題の「最新フィッシング情報」をこっそり修正しているが、訂正の知らせや事情説明などはない。

訂正 (2月11日)

「フィッシング詐欺対策協議会」と書いていた部分を「フィッシング対策協議会」に訂正した。協議会の名前は「フィッシング対策協議会」が正しいところ、Scanの記事の冒頭が、

フィッシング詐欺対策協議会は1月26日、

VISAのシステムがハッキング被害、フィッシングに注意, Scan Daily Express, 2006年1月27日

となっていたため、それにつられて間違えてしまった。

*1 この画像がまたひどい。無駄に画面サイズをでかくキャプチャしているうえ、ウィンドウサイズを巨大にしてサイズ変更を禁止しているというバカっぷりはともかくとして、アドレスバーの内容がなぜか消してある。偽サイトを見分ける手段としてのアドレスバーの確認というリテラシーを啓蒙するべき立場にある同協議会が、偽サイトのアドレスバーの内容を空白にしてどうする。偽だとわかるアドレスだったのだろうから、それを見せることにこそ、こうした画像を掲示する意義がある。米 Anti-Phishing Working Groupは、ちゃんとアドレスバーの中身を見せている。

*2 この設計自体が、無思慮も甚だしいところだが。

本日のリンク元 TrackBacks(2)

2006年02月10日

「ファーミング」さえ理解していないフィッシング対策協議会

昨日の話もひどかったが、よく見てみれば、他にも杜撰なところだらけだ。

全く気付かなかったが、フィッシング対策協議会は、今年の1月に初のレポートを発表していた。この内容がひどい。2006年1月12日に公表された「2005/11 国内フィッシング情報届出状況」と題された文書*1には次の記述がある。

1.5. フィッシングサイトの動向

11 月度に報告のあったフィッシングサイト2 件に関してはURL の偽装や紛らわしいURL の使用などは認められませんでしたが、今月発見されたYahoo!オークションのフィッシングサイトに関してはメールと共に、ブログやSNS にIP アドレスのリンクが記載されており、ファーミングの手法も取り入れられていることが確認されました。

(略)

1.8. 総括

11 月度は7 月度以来の日本企業のフィッシングサイトが確認されました。このフィッシングサイトは米国にホスティングされておりました。フィッシングメール自体は確認されておりませんが、インターネット上のブログや掲示板の書き込みにこのサイトにリンクを張ったIP アドレスの表記が多数確認されました。また、フィッシングサイトに使用されていたHTML ファイルの日付を確認したところ2 月になっておりました。かなり長い時間このフィッシングサイトが仕掛けられていた可能性が伺えます。これはファーミングの手口のひとつであるとも言えます。

フィッシング対策協議会 月次報告書(2005年11月分)フィッシング情報届出状況

そんなのは「ファーミング」じゃない。出鱈目言うなよ。「ファーミング」とは、

ファーミングとは、ユーザが正しいURLを入力しても、自動的に偽のサイトに誘導して個人情報を詐取する行為です。

ファーミングの犯人は、ウィルスやワームを使って利用者のコンピュータの hosts ファイルを書き換えたり、DNS サーバに虚偽の情報を書き込んだりすることによって、利用者が URL を入力して正規のサイトにアクセスしようとする際に偽サイトに誘導しようとします。(略)

フィッシングとは, フィッシング対策協議会

だろうが。

オレオレ証明書で本物だと太鼓判を押すフィッシング対策協議会

フィッシング対策協議会の「フィッシングに対する注意」のページに、「フィッシンングサイトではないとの確認方法」という解説が載っているが、これがまた杜撰だ。

そもそも、説明用の画像が小さいうえ汚くて内容が読み取れない*2のだが、それでも目を凝らして見るとする。

フィッシンングサイトではないとの
確認方法:その3

すると電子証明書の内容が確認できます。証明書中に銀行の名称が書かれていれば本物のインターネットバンキングの画面です。

フィッシングに対する注意, フィッシング対策協議会

というのだが、その説明図はこれだ。

図1: フィッシング対策協議会が本物サイトの「確認方法」として示すサーバ証明書の読み方説明図(原寸大)

なんじゃこりゃ。

「銀行の情報を確認」という丸があるが、左の丸の中に「銀行の情報」など書かれていない(URLはあるが)し、右の丸の中にも「銀行の情報」など書かれていない(ドメイン名はあるが)。「銀行の名称が書かれていれば」というが、それは、この画面ではなく、「詳細」タブの中ににあるはずのものだ。

そんなことさえわかってないド素人に、こんな大事なコンテンツを書かせているわけだ。

しかも、右の丸の部分をよく見てみると、

図2: 発行者が銀行になっている様子(図1の拡大図)

おいおい、証明書の発行者まで銀行になっているじゃないか*3。そんなオレオレ証明書で、

証明書中に銀行の名称が書かれていれば本物のインターネットバンキングの画面です。

フィッシングに対する注意, フィッシング対策協議会

と言うのか。

訂正 (2月11日)

「フィッシング詐欺対策協議会」と書いていた部分を「フィッシング対策協議会」に訂正した。協議会の名前は「フィッシング対策協議会」が正しいところ、9日の日記で参照した、Scanの記事の冒頭が、

フィッシング詐欺対策協議会は1月26日、

VISAのシステムがハッキング被害、フィッシングに注意, Scan Daily Express, 2006年1月27日

となっていたため、それにつられて間違えてしまった。

*1 しかも、2005年11月分の発表なのに表紙の日付が「2005年1月4日」になっているという間抜け付き。

*2 「(画像のクリックで大きな画像がご覧いただけます。)」とあるが、クリックしても、たった 1.2倍大きいだけの、相変わらず小さくて不鮮明な画像が表示されるという、バカっぷり。

*3 しかも、「Incorp.by Ref. LIABILITY LTD. (c)97 VeriSign」という部分を残して他の部分を改竄するという、強気ぶり。

本日のリンク元 TrackBack(0)

2006年02月22日

スパイウェア対策としてのTrusted Computingへの期待

今日は休暇中。明後日はWebアプリケーションセキュリティフォーラムの第3回コンファレンスだ。

  • 第3回コンファレンス, Webアプリケーションセキュリティフォーラム

    日時: 2006年2月24日(金) 10:30〜18:00 受付開始:10:00
    会場: 丸の内コンファレンススクエアM+ 1階 サクセス

    13:20〜14:20 基調講演
    『根源的なスパイウェア対策としてのTrusted Computing』
    丸山 宏 日本アイ・ビー・エム株式会社 東京基礎研究所

今回は、IBM東京基礎研の丸山宏先生を基調講演にお招きし、スパイウェア対策にからめて、Trusted Computingについてご講演いただけることになった。このテーマとWebアプリケーションセキュリティの関係は、次のように言える。

昨年は、スパイウェアが原因とされるインターネットバンキングを悪用した不正送金事件が多数明るみになったことから、各金融機関はこぞって、「ソフトウェアキーボード」やら「ワンタイムパッド」だの、ワンタイムパスワードなどを導入した。

しかし、これらの大半は、スパイウェア対策になっておらず、単なるキーロガー対策でしかない。

「『スパイウェア』といえば『キーロガー』のことである」というのは間違いであり、他にも様々な方法で不正送金をたくらむスパイウェア(「マルウェア」、「クライムウェア」などとも呼ばれる)が出現し得るからだ。

用語「スパイウェア」を文言に忠実に定義しようとすれば、「スパイ」という文字通り「情報を盗む」機能を有するものだけを指すことになるかもしれないが、重要なのは、「ユーザが信用すべきでないプログラムを誤って実行してしまうような状況がある」という共通の前提条件であり、そのような前提で有害となるもの全体を指して「スパイウェア被害」と呼ぶことにした方がよい*1

そのような広義のスパイウェアならば、ブラウザを自動操作するなどの方法によって、パスワードを盗む方法ではなく、Webサイトに対して不正な操作を間接的にすることができてしまう。このことは、普通レベルのWebアプリケーション技術の仕組みを知る者なら、容易に気付くことであろう。

この懸念は英語圏では既に現実のものとなってきているようで、ちょうど一昨日、こういう報道も出ていた。

  • 口座預金を略奪するトロイの木馬がまん延--セキュリティ研究者が注意を呼びかけ, CNET News, 2006年2月20日

    サイバー犯罪者がユーザーとともにオンラインバンキングを利用し、口座の金を盗むという事態が起こっている。

    (略)

    Shippは米国時間2月16日、当地で開催された「RSA Conference 2006」において、「最近では、ユーザー名やパスワードの盗難は減少している」と発言した。代わりに、「(口座から金を盗む目的で作成された)トロイの木馬」が、ユーザーがオンラインバンキングを利用するのを待ち受けるようになり、「金を外部へ送金している」のだという。

    「いかなる認証システムが導入されていようと、ちょっとした仕掛けが施されていようと、生体認証が適用されていようと、役に立たない。犯罪者はユーザーを待ち伏せて、口座預金を盗み出している」(Shipp)

おそらく今年は、その種のタイプのスパイウェアによる被害を食い止めることが、Webサイト運営者達の課題となると思われる。

しかしながら、Webアプリケーション側で、そうしたスパイウェアによる攻撃を防ぐことは、原理的に見て、不可能である*2

ある程度「やらないよりはやった方がまし」な対策とかは存在するし、「同じ効果を期待するならその方法は脆弱である」といった議論はあり得るので、その意味で、このテーマはWebアプリケーションセキュリティと関係はあるものの、根本的には、そうした攻撃の原因はユーザ側の過失にある(Webアプリの欠陥ではない)とせざるを得ない。

そうすると、ユーザ側のスパイウェア対策は可能なのか? ということが議論の焦点となってくる。ひとつにはリテラシ教育であるが、クライアント側のシステムでの対策として、従来のワクチンソフトや既知のスパイウェア検出ソフトのようなアドホックな方法ではなく、根本的で本質的な対策はできないのかということになる。

そこでTrusted Computingへの期待――ということになる。丸山先生に、Trusted Computingがスパイウェア対策の本命となり得るかをお尋ねしたところ、今回のご講演をいただけることになった。私としても興味津々で明後日がたいへん待ち遠しい。

Webアプリケーションセキュリティに携わる技術者としては、広義のスパイウェアによる攻撃の可能性と、Webアプリケーション脆弱性との関係を正しく理解し、責任分界点の明確化に務めたいところであろう。

*1 不正確な用語定義かもしれないが、日本において消費者に注意喚起するために使えるキーワードが「ウイルス」と「スパイウェア」くらいしかないため、現時点ではやむをえないだろう。

*2 米国では、FFIEC (US Federal Financial Institutions Examination Council: 連邦金融機関検査委員会) が2006年末までに2要素認証を導入しなければならないとするガイドラインを制定したことが話題となっているが、そうしたスパイウェアによる被害は2要素認証でも防げないのであり、既に被害が出ているというのであれば、ともすれば、米国でもその方向性は見直しになる可能性さえあるのではないか。

本日のリンク元 TrackBack(0)

2006年02月27日

「やさしいセキュリティ教室」が朝日新聞にも出ていた

新聞記事を検索していて気付いたのだが、12月6日の日記に書いていた、三井住友銀行の素晴らしいセキュリティ教室が、1月に朝日新聞でも報道されていた。一般の人の視点で見たときにも本当に「やさしい」ものに映ったということだろうか。

1月14日朝刊の9面に「偽造カードやスパイウエア予防策をHPで指南 三井住友銀」という見出しで掲載されたようだ。(新聞まだ入手していない。)

偽造キャッシュカードやスパイウエアなど預金者を脅かす犯罪が相次ぐなかで、三井住友銀行がホームページで公開した対策集が話題を呼んでいる。実際の犯行の手口を具体的に紹介した上で、どんな対策がなぜ必要なのかを丁寧に説明している点が好評の理由。アクセスは1日9000件にもなるという。

昨年10月末に公開された「簡単! やさしいセキュリティ教室」は、(以下略)

1日9000件……。多いような少ないような。

本日のリンク元 TrackBack(0)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

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|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
最新 追記