 |
 |
記事検索 |
バックナンバー |
 |
||
|
||
【 2008/10/08 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/24 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/17 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/03 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/08/27 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/30 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/23 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/16 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/09 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/02 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/06/25 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/06/18 】 |
||
|
||
|
||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
| あなたの身近なセキュリティ | ||||||||||||||||||||||||||
|
第9回：WWW編（7）「SSLだから安全」は不十分 |
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
● 「SSL＝安全」ではない 前回はWebの暗号化転送としてのSSLとRSA暗号の話をした。繰り返しになるが、SSLが行なっていることは次の3つだ。・サーバーのドメインとアクセスしているドメインが本当に同じか確認する ・サーバーとパソコンの間で安全に共通鍵を交換する ・サーバーとパソコンの間で共通鍵を使ってデータのやり取りをする では、SSLで守られていれば安全だろうか？ これは違うと思って欲しい。 もしもサーバーやクライアントマシンが何らかの方法で「覗かれている」場合、SSLだから安全ということは一切ない。いわゆるスパイウェアが仕込まれているなら、暗号化通信をしていても関係なく情報を盗み出せる。また、サーバーに保管されたデータを何らかの形で盗まれても意味がない。このため、サーバー側の安全策を認定する制度もある。 筆者がこの手のセキュリティに興味を示した背景には、情報流出事件があった。例にするのはちょっと微妙だが、この原稿が掲載される2週間前、Amazon.co.jpの「ほしい物リスト」が基本公開されることを知らない人が、「あまり人前に出したくない趣味」や「世間に秘匿していたハンドルと本名」を“暴露”されたケースがある。これは、サーバーのセキュリティの問題ではなく、運用方針と説明の仕方の問題だろう。 もう1つ例を挙げると、相手のサーバー管理そのものに悪意があるケースも考えられる。「安全です」と言ってデータを騙し取るという可能性がないとは言えない。フィッシング詐欺サイトは「話題になる前に逃げる」ので、サーバー証明書を用意するフィッシングは通常ないが、サーバー証明書と一言で言っても会社の登記簿などがないと取得できないものから、比較的容易に取れるものまで色々な会社がある。極論となるが「SSLでやり取りをするフィッシングサイト」が出ないという保証はない。 ● 「オレオレ証明書」など「ダメなサーバー証明書」が使われることも
前回例に挙げたインプレスグループのオンラインショップ「インプレスダイレクト」では、サーバー証明書が「2009/01/09まで保証している」と書いた。しかし、証明書が期限切れを起こすことがままある。この場合、保証期限切れゆえ証明書としての効力はない。また、何らかのケースでサーバーのドメインが変わってしまった場合、「ドメインの証明」としての効力がなくなる。 ダメな証明書の典型例が「オレオレ証明書」と通称されている（この言葉はおそらく日本だけの独自用語だ）。むろんこれはオレオレ詐欺に由来している。オレオレ証明書でも典型的なのが、自分で自分自身の証明書を作った「正当性を自称する」ものだ。 なお、サーバー証明書は作成に費用と時間がかかるので、テスト用に自己署名の証明書を使うことはよくある。また、社内用証明書を使用しているケースもある。ただ、これを社外の人に閲覧させると問題が出るわけだ。 社外、あるいは一般のPCに「新たなルート証明書を入れさせる」という解決策もないわけではない。ただし、そのルート証明書に問題がないことを証明するのは難しいので、これも薦められるままに行なうのは危険だろう。Webからルート証明書をダウンロードして入れさせられるのは、少なくても筆者としては「相当キモチワルイ」。この実例として、財務省サイトのルート証明書について後述する。 一方、何らかの拡張方式でユーザーに問題がないことをわかりやすく表示しようという試みもある。その1つは「EV SSL証明書」で、先に書いたような存在証明をCA認証局が行なっているものだ。Internet Explorer 7（+Windows Vista）では、このEV SSL証明書に対応しており、このSSL証明書を使っているとアドレスバーが緑色になる。ただし、EV SSL証明書を使っているサイトはあまり多くなく、元に戻したサイトもあるという。 ● 暗号化転送をしているのに鍵マークがないケースも SSLでやり取りされているかどうか初心者に確認させる方法は2つある。1つ目は、アドレスバーが「https://」で始まっていること。2つ目は、Webブラウザの鍵マークが付いているかどうかを確認することだ。これは通常、初心者向けの安全利用のための文章には入っている項目だ。なお、鍵マークは、IE6ではブラウザの右下、IE7ではURLの右側、Firefox 2ではURLの右側とブラウザの右下に表示される。ところが、鍵マークが付かないというケースがたまにある。筆者は実際いくつかのショッピングサイトでこのような状況に出くわしたことがある。 大手サイトは自前でショッピングサイトを構築できるが、中小サイトの場合セキュアなサーバー管理が技術的や費用的に難しい。そこで、ショッピングカートをASP業者が運営して、それを借りることで安全なショッピングサイトを実現しているところはそれなりにある。 むろんカートシステムは安全に作られている（のだろう）。ところが、カートシステムの一部をカスタマイズする過程で暗号化転送を行なっていることを意識していないのか、一部のアイテムをhttpsで処理していないケースがある。この場合、「このページにはセキュリティで保護されている項目と保護されていない項目が含まれています。保護されていない項目を表示しますか？」という不要な警告ダイアログが表示され、さらに鍵マークが表示されないことがある。 警告ダイアログが表示された場合の選択は2つある。暗号化転送を行なわない転送について、許可するか禁止するかのどちらかだ。前者の場合、画面全体の安全性が保証されないためIEは鍵アイコンを表示しない。また、この選択ダイアログのメッセージもややわかりにくい。 現実的には「保護されていない項目を表示しない」ことで安全性を確保しつつ、「ほぼ」問題なく処理が行なわれる。だが、いくつかの項目（たいていアイコン画像）が表示されず、「必要な情報が出ていないのでは？」という不安がある。意地悪く言えば「安全なサイト構築でユーザーに不安なく利用できる」ように作っていない。他に同じ商品を売っているサイトがあれば、わざわざ不安感を持ったまま利用する必要はないと思う。 ● e-taxで「すごく気になったこと」
17日17時30分の窓口受付締め切りに間に合わせるのは絶望的だったが、消印有効の郵送申請か電子申請を使えば6時間ほどの猶予が生まれる。こんなこともあろうかと住基カードは作ってあったので、電子申請に挑戦してみたというわけだ。ところがこのe-taxは入り口から問題があるように見える。 電子申請は財務省（MOF）のルート証明書をインストールする必要がある（と書いてある）。ところが、この電子証明はWebからダウンロードすることになっており、先に書いたように信頼度に欠ける。このサイトも出来が悪く、httpsとhttpを混在しているために警告ダイアログが表示される。 また、ルート証明書のインストール方式は、インストーラを実行させる形式だが、これには有用なデジタル証明がされていないという警告が出る。つまり、改竄されたルート証明書をインストールしてもおかしくない。 実はこのインストーラはデジタル署名が施されているが、そのデジタル署名を確認するためには「これからインストールするルート証明書が必要」なのだ。いわゆる「缶切りは缶詰の中」状態で、これはまったく意味がない。時間に追われていたのでそのまま申請作業をしたが、正直、時間があれば通常の申告方法にしたかった。 ルート証明書はこれまで書いているように「信頼の根幹」なので、もう少し配布方法を考えたほうがよい。例えば、住基カードを作った際に申請の基礎プログラムが入っているCD-ROMを渡されるので、ここに入れておくべきだろう。
● 先週の気になったニュース（3/17～3/23） ◆Googleのドメインを使ってマルウェアを感染させる手法が発見されるhttp://www.avertlabs.com/research/blog/index.php/2008/03/17/google-ads-abused-to-serve-spam-and-malware/ Googleの広告リンクっぽく見せてマルウェア感染サイトに誘導される手法が使われていることをMcAfeeが報告している。McAfeeの報告事例とは少々違うものも筆者に届いた。 ◆@niftyでもウイルス仕込まれる、ヨン様主演ドラマの公式サイトなど改竄 http://internet.watch.impress.co.jp/cda/news/2008/03/18/18851.html SQLインジェクションによるWebサーバー改竄頻発のニュースが出たなら、自社の管理体制を調べて「他山の石」にすると思ったのだが……。 ◆「Vector」で公開されていたソフト2種、PC情報を無断送信 http://internet.watch.impress.co.jp/cda/news/2008/03/18/18858.html 「日本的」には一切認められない行為だろうが、「米国的」の場合、EULAに書いてあるとある程度セーフだ。つまりEULAはちゃんと読まないといけないのだが、ムダに分量が多かったり、サマリーを作ってないから厳しい。 ◆ゆうちょ銀行を装ったフィッシング詐欺メールが出回る http://internet.watch.impress.co.jp/cda/news/2008/03/18/18857.html 先週のイーバンクから、立て続けにフィッシングサイト事例が出ている。今回のフィッシングサイトは「いつものゆうちょログイン画面」とは異なるため、見た目で判断できる。普段の観察でフィッシング被害を止めることができるだろう。 ◆マレーシアF1サイトにアクセスしようとすると不正サイトへ誘導される http://internet.watch.impress.co.jp/cda/news/2008/03/21/18894.html DNSサーバーを書き換えることによって不正サイトへ誘導されるケースだ（道路標識が書き換えられたと思えばわかりやすい）。この場合Webサーバーは改竄していない。性善説に基づくインターネットは、この手の悪意に弱さを抱えている。 ◆アイ・オー・データ機器の無線ルーターに脆弱性 http://www.ipa.go.jp/security/vuln/documents/2008/200803_iodata.html 外部から管理画面に入ることができ、さらに初期状態でパスワードがかかっていない。東芝のHDDレコーダーの話を思い出した。 ◆Excelの「緊急」パッチを「計算間違い」の問題を修正して再リリース http://internet.watch.impress.co.jp/cda/news/2008/03/21/18890.html 今回はすべて定時のリリースになったことで、Microsoft側の検証も十分にできたというコメントがあったのだが、それでもバグが出た。ユーザーサイドの対応法は2つあり、1つは素直にパッチを当て続けること。もう1つは、「1日様子を見る」ことだ。後者は当て忘れと既知のリスクを抱える可能性がある。 2008/03/26 15:35
- ページの先頭へ-
|
