<前の日記(2010年02月23日) 次の日記(2010年02月28日)> 最新 編集

高木浩光@自宅の日記

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

2010年02月27日

なぜ一流企業はhttpsでの閲覧をさせないようにするのか

「かんたんログイン」などという似非認証方式は、たとえIPアドレス制限を実装したとしても安全でない。仕様が公開されていないからという点の他に、技術的な理由として、少なくとも次の2つがある。

  1. 「IPアドレス帯域」と俗称される重要情報が安全に配布されていない。
  2. SSLを必要とするケータイサイトでは、通信経路上の攻撃によってなりすましログインされてしまう。*1

2番目には解決策がない。

1番目については解決策はあるだろうが、携帯電話事業者がサボタージュしていて、実現される見通しがない。これについては、2008年7月27日の日記にも書いたが、その後どうなったかを調べてみたところ、ソフトバンクモバイル以外は、何ら改善されておらず、当時のままだった。

NTTドコモ
iモードセンタのIPアドレス帯域」のページをhttps:// でアクセスすると、404 Not Found となる。
KDDI
EZサーバのIPアドレス帯域」のページをhttps:// でアクセスすると、404 Not Found となる。
ソフトバンクモバイル
Yahoo!ケータイにて利用するIPアドレス帯域」のページは、https:// でもアクセスできる。
イー・モバイル
IPアドレス帯域」のページは、https:// でアクセスしようとしても、つながらない。ポートが遮断されている。

NTTドコモとKDDIは、ちゃんとSSLを稼働させているのに、なぜかあえて 404 Not Found にしている。せっかくSSLを正しく証明書を取得して稼働させているのに、どういうことなのか。

この違和感は、金融機関のサイトについても以前から気になっていた。

金融機関にとっては、連絡先の電話番号なども重要な情報であり、すり替えられたりしないよう、安全に閲覧できる手段を用意していてしかるべきである。それなのに、大手金融機関が、どういうわけか、それを実施していない。

以下は、「銀行」でGoogle検索して上から出てきた順に、各金融機関について現状を調べたものである。

三菱東京UFJ銀行

画面キャプチャ
上のページを https:// でアクセスした様子
(akamaiのサーバ証明書。ホームページをSSL対応にするつもりがないケース。)

三井住友銀行
画面キャプチャ
三井住友銀行の「お問い合わせ先」ページ
(重要な用件の連絡先が書かれている。)

画面キャプチャ
上のページを https:// でアクセスした様子
(EV SSLまで用意されているのに、404 Not Found になっている。)

りそな銀行
画面キャプチャ
りそな銀行の「お問合せ」のページ
(重要な用件の連絡先が書かれている。)

画面キャプチャ
上のページを https:// でアクセスした様子
(SSLは正常に用意されているのに、404 Not Found になっている。)

みずほ銀行

画面キャプチャ
上のページを https:// でアクセスした様子
(SSLのサーバが稼働していない。ホームページをSSL対応にするつもりがないケース。)

イーバンク銀行
「お問い合わせ」ページが見つからなかったのでスキップ。

ゆうちょ銀行

画面キャプチャ
上のページを https:// でアクセスした様子
(SSL用の別サーバ wwws.jp-bank.japanpost.jp の証明書。ホームページをSSL対応にするつもりがないケース。)

画面キャプチャ

別サーバ「wwws」の同じパス名に https:// でアクセスしてみた様子
(404 Not Found。別サーバで用意しているわけではないらしい。)

なんと、このように、上位5行のいずれも、問い合わせ先電話番号等を https:// ページで閲覧できるようにしてくれていない。

2008年9月にフィッシング対策協議会が公表した「フィッシング対策ガイドライン」にも、次のように書かれている。

【要件】 ◎Webサイト運営者の連絡先及びガイダンス等、顧客に間違いなく情報を伝える必要のあるページはSSL/TLSで保護すること

SSL/TLS には、機密性保護に加え、アクセスしている Web サーバの正当性(ドメイン名を含めたサーバ名と運営者との関係について認証局が確認をとっているということ)を検証する機能が備わっている。Web サイト、Web サービスに関する緊急時の連絡先及びガイダンス等、Web サイト運営者から正しく情報を伝える必要のあるページは SSL/TLS でのアクセスを可能とし、顧客が Web サイト運営者からページコンテンツが提供されていることを確認する手段を提供することが望ましい。

フィッシング対策ガイドライン, フィッシング対策協議会, 2008年9月10日

これがぜんぜん守られていない。どうしてこんなことになっているのだろうか。

ここで思い出すのが、昔からしばしば、「https:// のページは http:// でアクセスできてはいけない」などと、出鱈目なことを言う自称セキュリティ屋がいたことだ。インターネットバンキングのSSLサイトを http:// でアクセスして、アクセスできると「危ない銀行だ」などと出鱈目なことを言いふらしているのがいた。

最近でも、以下の文書がそういうことを言っている。

適切に HTTPS を使うことで通信の盗聴・改ざん・なりすましから情報を守ることができます。重要な情報を扱う場合には HTTPS で通信を行う必要があります。また特別な理由がない限りは HTTPS でアクセス可能なページは、HTTP でのアクセスを提供しないことが望ましいでしょう。

発注者のためのWebシステム/Webアプリケーションセキュリティ要件書, 株式会社トライコーダ, 2009年4月

「特別な理由がない限り」って何? 特別な理由って何? 理由があればいいの? 理由がないときはなぜ提供しちゃいけないの? *2

https:// のはずのページが攻撃者によって http:// にすり替えられることを懸念してのつもりかもしれないが、そんなのは、サーバ側で http:// を止めたところで解決にならない。攻撃者は https:// へ中継するだけだし、中継しないでそのまま偽ページを返してもいい。結局のところ、利用者自身が、見ている画面が https:// になっていることを自力で確認しないかぎり、SSLは機能しない*3のであって、サーバで http:// が稼働しているか否かは関係ない。

こういう似非セキュリティコンサルの指摘を真に受けて守ろうとするとどうなるか。

A社ホームページ http://www.example.jp/ のうち、重要な情報を掲載するページを https:// でも閲覧できるようにと、SSLを導入したとする。https://www.example.jp/important.html というページができることになるが、このSSLページは http:// でもアクセスできることになる。セキュリティコンサルが言う要件に違反してしまう。

こんな本末転倒な話があるか。似非コンサルの戯言など無視して、https:// でも閲覧できるようにするべきだ。http:// で閲覧するか https:// にするかは利用者が選ぶことだ。

このままでは、新幹線車内など公衆無線LANから銀行の電話番号を確認できないわけで、本来、こういうことは利用者がどんどん要望を出していってしかるべきことだ。私も、自分が使っている銀行については、週明けにでも電話で要望したい。

*1 これは、2007年6月29日の日記「サブスクライバーID をパスワード代わりに使うべきでない理由」に書いた。図を再掲しておく。

説明図
通信路上の攻撃者がキャリアのIPアドレスからの任意のサブスクライバーIDを送信する様子
(2007年6月29日の日記「サブスクライバーID をパスワード代わりに使うべきでない理由」の図2より再掲)

「通信路上の攻撃者なんているのか」という疑問に対しては、2008年6月3日の日記「通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか?」で紹介した、さくらインターネットのLAN上でARP spoofing攻撃が発生した事件がその実例にあたる。

*2 あいかあらず上野宣がテキトーなことを書いているわけだが、「特別な理由がない限り○○が望ましい」で通るんだったら、どんな要件だっていくらでも書ける。要件を書く方は何も考える必要がない。

*3 「安全なWebサイト利用の鉄則 / よくある質問と答え」参照。

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

今日は、企業サイトで意識するべき「正しい情報提供」の手法について。企業情報ページの連絡先情報やIRページなど、正しい情報を伝えるべきページは、httpsでアクセスできるようにして

検索

<前の日記(2010年02月23日) 次の日記(2010年02月28日)> 最新 編集

最近のタイトル

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|
<前の日記(2010年02月23日) 次の日記(2010年02月28日)> 最新 編集