御社の企業情報ページはhttpsでアクセスできますか?
今日は、企業サイトで意識するべき「正しい情報提供」の手法について。企業情報ページの連絡先情報やIRページなど、正しい情報を伝えるべきページは、httpsでアクセスできるようにしておきましょう。
セキュリティ専門家の高木浩光氏が、ブログで「なぜ一流企業はhttpsでの閲覧をさせないようにするのか」という記事を出しました。銀行など金融機関のサイトで、電話問い合わせ番号を掲載しているページがhttpsではアクセスできない場合があることを警告している記事です。
・なぜ一流企業はhttpsでの閲覧をさせないようにするのか (高木浩光@自宅の日記)
→ http://takagi-hiromitsu.jp/diary/20100227.html#p01
元は携帯サイトの「かんたんログイン」の仕組みのセキュリティ上の問題点を述べる話題ですが、金融機関の問い合わせ先電話番号を掲載しているページがhttpsでアクセスできないことに言及しています。今回のテーマはそちら。
なぜ問い合わせ先電話番号が掲載されているページなど、顧客に間違いなく情報を伝える必要のあるページはhttpsでアクセスできるべきなのでしょうか? それは、SSLを使っていれば、その内容が正しいサーバーから送られた情報であることを確認できるからです。逆に言うと、SSLを使わない通常のhttpページでは、偽のサーバーに誘導されていたり、経路上で内容が改ざんされていたりしても、それに気づかないことがあるのです。
たとえば、あなたが外出先で財布をなくしたとします。幸い手元にノートパソコンがあったので、野良WiFi(だれかが設置している無線LANアクセスポイント)からインターネットに接続してクレジットカード会社の問い合わせ先ページを見て、カードの停止を依頼したとします。しかし、その無線LANアクセスポイントが悪意をもって設置されたもので、そのネットワークではクレジットカード会社や金融機関の問い合わせ先電話番号ページへのアクセスが偽のページに誘導されていたとすると、あなたは偽ページの情報を見て、悪意をもった罠の番号に電話をかけることになります。あなたは当然、正しいクレジットカード会社の問い合わせ先に電話していると思っているので、クレジットカード番号と名義、さらに「本人確認のために」と言われたら、カードの有効期限やその他の個人情報も伝えてしまうでしょう。
問い合わせ先電話番号ページがhttpsで提供されていれば、あなたは証明書を確認して、それが正しいサーバーから送られてきた情報であり、経路の途中で改ざんされていないことをチェックできますが、httpsでなければそれすら確認できません。
野良アクセスポイントでなくても、パソコンに入り込んだウイルスがブラウザの通信を途中で書き換えたり、イベントスペースが提供しているネットワークが悪意をもったハッカーにやられていたりなど、悪意をもって偽の情報に誘導される状況はさまざまです。でも、サーバー側がhttpsでページを提供していれば、少なくともSSL証明書を確認して正しいサイトにつながっているかどうかをチェックできます。
もちろん、そんなことを言い出したら、ネットで出す情報はすべてhttpsにしなければいけなくなりますし、サイト側がhttpsでページを提供しているからといって、フィッシングを防げるわけではありません。というのも、何らかの悪意でサイト訪問者がまったく別のコンテンツに誘導されていたら、訪問者が自分でhttpsでアクセスし直してSSL証明書を確認しない限り、正当な内容ではないことを知り得ないからです。おそらく多くの消費者はそんなことはしてくれないでしょう。
でも、企業活動にとって重要性を増しつつあるWebサイトだからこそ、重要な情報はhttpsで提供することを当然にしていくべきなのではないでしょうか。「クレジットカード番号を入力するフォームでは、ブラウザの鍵マークを確認する」文化は、10年以上かけてネット利用者に浸透していきました。次は、「重要な情報はブラウザの鍵マークをクリックして本物かどうか確認する」になるのかもしれません。
まずは、間違った情報が伝わるとまずいページに関しては、httpsで提供できるようにしてみませんか? そうすれば、セキュリティの意識をもった人は証明書を確認してあなたのサーバーから送られた情報であることを確認できるようになります。
それができたら、次は、サイト内からそのページへのリンクをすべてhttpsにして、そのページにhttpでアクセスされたらhttpsに強制的にリダイレクトするようにするといいでしょう。。
あなたの企業サイトの問い合わせ先ページは、httpsでアクセスできますか?
コメント
一般的に、HTTPとHTTPSのドキュメントルートって同じ?
高木先生のページを読みました。
改竄された際の影響が大きい情報を掲載するページに関して
HTTPSで公開すべきという意見には、その通りだと思います。
ただその後の、HTTPでアクセスして、そのURLのメソッドを
HTTPSに変えてアクセスしようとして、できないのでダメだ、
と主張しているのだけはいただけません。
そもそも高木先生の頭の中で、
「同じサーバ名のHTTPとHTTPSは、全く同じドキュメントルートを指しているはずだ」
という思い込みがあるように思います。
企業が自社のホームページを開設しようとする場合、どのくらいの
アクセス数に耐えられるようにするかという要件を決めてから、
実際のシステム構成を決定し、サイトを開設することになります。
その際に、HTTPとHTTPSではサーバに与える負荷ではHTTPSの
方が重いため、HTTPとHTTPSのアクセス数を別々に想定する
場合が多いと思います。
そのように要件定義された場合、HTTPとHTTPSのドキュメント
ルート設定は異なるものに設定し、
・HTTP用のドキュメントルート配下にはHTTP用のコンテンツを
・HTTPS用のドキュメントルート配下にはHTTPS用のコンテンツを
配置することになるのではないでしょうか。
さらに、HTTPSのアクセス数が多いという場合には、負荷分散装置や
SSLアクセラレータなどを使用して、物理的にHTTP用のサーバと
HTTPS用のサーバを分離することもあり得ます。
そのようなシステム構成の場合、HTTPのURLのメソッド部分を
HTTPSに変えてアクセスしようとしても、「404 Not Found」になる
のは当然で、非難されるべき謂れは無いように思えます。
繰り返しますが、連絡先などの改竄されるべきでない情報をHTTPSで
提供する必要が無いと主張している訳では、決してありません。
Re: 一般的に、HTTPとHTTPSのドキュメントルートって同じ?
yakuさん、返信が遅れました。
示唆的なコメントありがとうございます。
たしかにhttpとhttpsで別のdocrootを設定することもいですが、イマドキの話でいうと、httpもhttpsも同じdocrootにして、CMSのコントローラ部分でリストに応じて適切なプロトコルにディスパッチするという形にする流れだと思っています。
もちろん、サーバー側の静的キャッシュへのアクセスとの兼ね合いなどありますし、パフォーマンス面でいうと、おっしゃるような点でいろいろと難しいのですが。
> そのようなシステム構成の場合、HTTPのURLのメソッド部分を
> HTTPSに変えてアクセスしようとしても、「404 Not Found」になる
> のは当然で、非難されるべき謂れは無いように思えます。
非難というか、「システム構成上そうなるのはわかるけど、Webサイトがどう使われるべきかを念頭に、少しずつ、あるべき姿に近づけていきましょう」という提案だととらえていただければと。はい。
暫定的な措置として、一部分だけシンボリックリンクで対応するなりもあるのかな、と(ディレクトリトラバーサルが起きるからダメなのかな? 調べていませんが)。