<前の日記(2005年11月27日) 次の日記(2005年12月02日)> 最新 編集

高木浩光@自宅の日記

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

2005年11月30日

SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも

24日のIT Proの記者の眼に「なぜSSL利用をケチるのか」という記事が出ていた。筆者の阿蘇氏には勤務先でWebアプリケーションセキュリティについて取材を受けたことがある。この記事の主張はこうだ。

Webサイトはログイン画面からSSLを使い,利用者はログイン時に鍵マークを確認するのが常識。

阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日

正しい。より正確には「ログイン時」というのは、パスワードを入力する前にということだろう。ただ、その根拠としてこの記事は、フィッシング対策としてサイトが本物かを確かめるためという点だけを挙げているが、その根拠はやや弱い。

SSLをパスワード送信先の画面からではなく、入力画面から使わなくてはならない理由のもうひとつの重大な理由は、パケット改竄可能な状況での盗聴が可能になってしまうからだ。このことについては、だいぶ前から講演で述べてきた。たとえば、2003年9月の「安全なWebサイト設計の注意点」のスライド4から始まるそのビデオで説明している。

なかなかわかってもらいにくい話なので、そのような画面構成になっていたある公共料金の明細閲覧サイトに対して、今年8月にメールで問い合わせをしてみた。以下はそのやりとりである。


質問一回目: ○○○○○のログイン画面が https:// になっていません。暗号化に不備があるのではないでしょうか?

回答: ○○○○○ログイン後のホームページは、セキュリティを強化したページになっております。そのため、○○○○○○のIDとパスワードも、保護されて送信されております。ご安心下さいませ。


質問二回目: ログイン後のページが https:// になっていることは、パスワード送信前の段階で、どのようにして確認できるのでしょうか?

回答: ○○○○○○のホームページ http://○○○.○○.com/○○○○○○/ の一番下にございます、『プライバシーを保護します』という項目にて、『ホームページに掲載する情報は暗号化して送受信されます。(SSL技術使用)』というご説明を掲載させていただいております。わかりづらくて申し訳ございませんでした。


質問三回目: いくらそのように文章で書かれていても、今私が見ているログイン画面が本当に、送信先が https:// になっているかどうかは、どうやって確認できるのでしょうか?たとえば、通信路上でパケット改竄されていれば、今見ている画面のリンク先(パスワードの通信先)は、https:// ではなく http:// に改竄されているかもしれないわけですが。

回答: Internet Explorerをご利用の場合は、ページ上部のメニューの『ツール』⇒『インターネットオプション』をお選びいただき、『セキュリティ』の項目で『保護付き/保護なしのサイト間を移動する場合に警告する』にチェックを入れていただければ、保護されているサイトに接続される際にメッセージが表示されます。

また、改竄につきましてご心配を頂いておりますが、弊社では、リンク先等を改竄されないようホームページを構成いたしております。ご安心してご利用いただければと存じます。


質問四回目: それは、パスワードの送信を開始させた後に表示されるメッセージですね。しかもそれは、正常な場合(https:// でのパスワード送信となっていた場合)に出るメッセージであって、異常な場合(引き続き http:// のままでアクセスする(パスワードを送信する)場合)には、出ないメッセージではありませんか?つまり、あなたの言うように設定していても、パスワードの送信を開始した後、そのメッセージが出なくて異常に気付いても、後の祭なのではないですか?

私は前回、「通信路上でパケット改竄されていれば」と書きました。通信路上でのパケット改竄を防ぐには SSL を使用して https:// にするしかありません。しかし、○○○○○○のパスワード入力画面は http:// であり、通信路上での改竄防止措置がとられていません。「改竄されないよう構成しています」というのは、明らかな嘘偽りです。

回答: ○○○○○○では、パケット改竄などの不正アクセスの防止等に日々努めております。誠に申し訳ございませんが、何卒ご理解頂きますようお願い申し上げます。


質問五回目: 通信路上でのパケット改竄をどうやって御社が防ぐのですか?御社のコンピュータから私の家のコンピュータまでの通信路上で、パケットが改竄されることを、どうやって御社が防いでいるというのかを教えてください。

回答: 高木様のおっしゃる通り、ログイン画面では、httpsによる暗号化が望ましいと思います。 ○○○○○○では、SSLを利用したログイン画面
https://○○○.○○.com/○○○○○○/login.html
も設けておりますが、現状の○○○○○○トップページ
http://○○○.○○.com/○○○○○○/
からは、暗号化されたログインページにアクセスすることができなくなっております*1

そのため、今後はトップページより、暗号化されたログインページへのアクセスをご選択いただけるような形に変更するよう対応していきたいと思います。


このような質問をするなどして、ご自身で考えて頂かない限り、運用中のサイトの管理責任者にこの問題を理解していただくことは難しい。

その後このサイトの画面構成は改善され、トップページのパスワード入力欄は撤去され、「ログイン」ボタンを押すと https:// のページにジャンプするようになり、そこにパスワード入力欄が現れるという構成になった。

クレジットカード業界は最もWebセキュリティを理解していない業界

阿蘇氏の「 なぜSSL利用をケチるのか」には、次の記述がある。

今や重要な情報を扱うWebサイトは,SSLを使うのが常識。しかし,ログイン後はSSLを使うのに,ログイン画面の表示にはSSLを使用していない Webサイトが意外に多い。銀行のサイトではさすがに減っているが,Webメールやクレジットカード会社などにはまだある。そのようなサイトに限って,「ログイン時にSSLを使うのでIDやパスワードは暗号化されます」とわざわざ注意書きがあったりする。

阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日

銀行のインターネットバンキングでは、以前から、パスワード入力画面は、サイトのトップページにはなく、ボタンを押して進んで現れる専用画面に設置されていて、入力画面からして https:// になっているというところがほとんどだった。

それに対しクレジットカード会社は、どういうわけか、そのような構成ではなく、カード会社トップページにパスワード入力欄を設けており、画面は SSLを使わずに http:// のままとなっているところがやたら目につく。

クレジットカード産業協会の会員企業一覧から、いくつかのメジャーなカード会社のサイトについて調べてみた。

このように、21のクレジットカードのうち、ID、パスワード入力画面がSSLになっていないところは 15サイト、つまり7割を超える。

どうしてこんなことになっているのだろうか。銀行とは対照的である。作っている業者が閉じた世界の業界に限定されているのか、それとも、同業他社のサイトを真似て作るために、どこかが始めたものが伝染してしまっているのか。

銀行業界では、昨年秋のフィッシング詐欺報道の機会に、一斉にアドレスバーを隠さない画面構成に改善するということがあった。業界内での情報伝達がある程度できているのだろう。

クレジットカード業界は、フィッシングやスパイウェアの報道に対して、高額なセキュリティ対策製品を購入するという方向に出た。ろくに対策にならない、それどころか誤ってユーザを安心させるような、つまらない「対策ソフト」がこぞって導入されたことは、業界通にはよく知られているところだ。

どうやら、クレジットカード業界は、Webセキュリティに関する正しい情報が伝達されない状況にあるらしい。これはクレジット産業協会の認識不足に原因があるのではなかろうか。

*1 「できなくなっております」とは、https:// ページへのリンクがないという意味で、ユーザが自力でアドレスバーに「s」を挿入して https:// で同じページにアクセスすることはできるようになっていた。

本日のTrackBacks(全15件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20051130]

Amazonって、TOPページからの「サインイン」リンクがSSLになっていないのでIDとパスワードが盗まれてしまう脆弱性がある。 このことをAmazonに伝えても全く理解できていないようで、なかなか改善されない。 で、もしかするとサインインページの「http://」を「https://」..

Amazonって、TOPページからの「サインイン」リンクがSSLになっていないのでIDとパスワードが盗まれてしまう脆弱性がある。 このことをAmazonに伝えても全く理解できていないようで、なかなか改善されない。 で、もしかするとサインインページの「http://」を「https://」..

詳しいことは 高木浩光さん の 「高木浩光@自宅の日記」 の記事 や 日経 IT Pro の 「なぜ SSL 利用をケチるのか」 を読んでいただくとして、クレジットカード会社のログインフォームが SSL 化されていないの、自分も前から気になっていたんですよね。 自分は三井住友カ..

 ちょうど、[http://takagi-hiromitsu.jp/diary/tb.rb/20051130:title=高木さんの所]でも言われていた内容ですね。  あの警察庁の電子申請で、オレオレ証明書が使われているって内容です。

ぶろぐ:SSLの利用価値 (2005年12月01日 20:30)

インターネットが普及することによって色々便利なことが出来るようになりましたが、その中のひとつに銀行やクレジットカード会社などの金融機関のWebサイトから自分の口座の残高照会や振り込みやカードの利用状況などが照会できることがあります。

さて、そのようなサイ..

Hotspring inside:OMCカード (2005年12月02日 00:57)

また[http://takagi-hiromitsu.jp/diary/20051130.html:title=高木先生のサイト]なんだけど、電話したことがあってほぼ同じ対応されたね。結局何の対策もされない。 http://www.omc-card.co.jp/ これの左側のログインのとこ。 個人情報が流出する可能性があるとはっきり言..

高木さんのところにSSLは入力画面から使用すべきといった内容のことが書かれている。 [http://takagi-hiromitsu.jp/diary/20051130.html#p01:title=SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも] (高木浩光@自宅の日記, 11/30) [http://..

クレジットカード産業協会の会員企業一覧から、いくつかのメジャーなカード会社のサイトについて調べてみた。 クレディセゾン × ソニーファイナンス × 三井住友カード × 私は上記3会社のカードをつかっていますが、 三井住友カードの場合。実はこの会社のサイトでは、..

フィッシング詐欺やなんやでクレジットカードの番号やユーザー名・パスワードなどの大事な情報を入力するときにはSSLをつかうことが常識となっています。

xap:memo:本日のTech:memo (2005年12月05日 22:24)

◆MP3tunes Locker:容量無制限・iTunes互換の音楽ストレージサービス (Engadget Japanese)
mp3tunes.comから、ローカルにある音楽ライブラリを容量無制限でオンラインにバックアップ、どのコンピュータ

以下のような記事を読んだ。 [http://takagi-hiromitsu.jp/diary/20051130.html:title] 以前に、このBlogでもSQLインジェクションについて書いた。 [http://d.hatena.ne.jp/bellin/20050524:title] Webセキュリティ対策に関してはその必要性がかなり認識されてきたことも..

文中にある「安全なWebサイト設計の注意点」も是非一読を。

昨日Black Hatで「New Tricks For Defeating SSL in Practice」という発表がありました。海外のメディアでは既に早とちりして、適切でないタイトルで記事にしてしまっているところも見受けられます。 Website danger as hacker breaks SSL encryption タイトルだけ読むと、..

検索

<前の日記(2005年11月27日) 次の日記(2005年12月02日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

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|04|07|11|
<前の日記(2005年11月27日) 次の日記(2005年12月02日)> 最新 編集