ケータイWebの今後を安全に保つには：再考・ケータイWebのセキュリティ（最終回）（1/3 ページ）

“特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部）

[徳丸浩，京セラコミュニケーションシステム株式会社]

　前回では、URLにセッションIDを埋め込むことの問題点を指摘した上で、今後はできるだけケータイでもCookieを使うことを提案しました。それを受けて今回は、前半で、ケータイWebでCookieを使う際の注意点について説明します。

　そして後半では、連載の終わりに当たり、スマートフォンが普及しつつある状況下でのケータイWebの今後について説明します。

ケータイWebにおけるCookieは「取り扱い注意」

　これまで説明したように、KDDIとソフトバンクのケータイでは従来からCookieが利用でき、NTTドコモの端末でも2009年夏モデル以降でCookieが利用できます。セッション管理にCookieを利用することで、セッション管理の安全性を高めることが可能です。

　ただしKDDIの端末では、Cookieの扱いに注意が必要です。KDDIの仕様書には、以下の記載があります。

EZweb対応端末においてCookieは、EZサーバに保管されます。

※ただし、WAP2.0ブラウザ搭載端末ではEnd to EndのSSL通信時は端末に保管されます。なお、EZサーバに保管されたCookieはKDDI設備のメンテナンスなどによりリセットされる場合があります。

　すなわち、HTTPSでSet-CookieされたCookieは端末に保存されますが、HTTPでSet-CookieされたCookieは事業者のゲートウェイ（EZサーバ）に保存されます。

　HTTPSの場合、ゲートウェイでCookie処理はできなくなるため、HTTPSのページではHTTPでセットされたCookieが参照できないことになります。

　またCookieの仕様として、secure属性のついたCookieはHTTPのページでは参照できません。これらをまとめると、下表のようになります。

設定時の条件	HTTPでの参照	HTTPSでの参照
HTTPで設定	○	×
HTTPSで設定（セキュア属性なし）	○	○
HTTPSで設定（セキュア属性付き）	×	○

　このため、EZwebで、HTTPとHTTPS両方から参照できるCookieを設定するためには、HTTPS側でCookieを設定する必要があるということです。一般的にはそのような制約はなく、EZweb独自の制約です。

　しかし、この制限は近く変更されるようです。au/KDDIの「KDDI au: そのほかの技術情報 > Cookie」によると、2011年秋冬モデル以降の端末では、下図のようにCookieの保管場所による区別がなくなっています。

画面1　「au/KDDIの「KDDI au: そのほかの技術情報 > Cookie」にある情報

　同様に、Cookieのデフォルト有効期限についても、2011年秋冬モデル以降で変更されるようです。

Cookieの有効期限

デフォルトの有効期限

「max-age」の有効期限の指定がない場合、2011年夏モデル以前のEZブラウザと2011年秋冬モデル以降のEZブラウザとで仕様が異なります。

2011年夏モデル以前 ：デフォルトで「1日 (24時間)」。

2011年秋冬モデル以降 ：ブラウザ起動中のみ有効、ブラウザ終了時に削除。

　これらの発表から、筆者は、2011年秋冬モデル以降では、Cookieは常に端末に保存される仕様に変更されるのではないかと予想しています。そうなると、HTTPでセットされたCookieもHTTPSのページから読み出せることになるはずですが、そこまで明確には発表されていません。これは筆者の推測です。

　筆者の推測が当たっていても外れたとしても、現在のEZwebの仕様に合わせてアプリケーションを開発しておけば間違いありません。すなわち、HTTPとHTTPSの両方から参照する必要のあるCookieはHTTPSでセット・変更するということです。

　これはかなり厳しい制約になりますが、携帯電話ブラウザ向けにHTTPとHTTPS混在のサイトを開発する上では避けては通れない制約です。

ソフトバンクのゲートウェイ型SSLに潜んでいた問題

　実は少し前まで、ソフトバンクでも、HTTPとHTTPS混在のサイトでCookieの扱いが難しい状態でしたが、今年の6月30日午前3時にこの問題は解消されました。以下、この問題について説明します。

　図1は、一般的なSSLを示しています。ケータイブラウザとWebサーバの間には事業者のゲートウェイがありますが、ゲートウェイは単に通信を中継するだけで、通信内容を見たり改変したりすることはできません。

図1　一般的なSSL

　これに対してソフトバンクの旧来のSSLは、ケータイブラウザとWebサーバの間にsecure.softbank.ne.jpというゲートウェイが割り込む形になっていました（図2）。SSLの暗号化通信は、secure.softbank.ne.jpで受信する際に復号され、再度暗号化されて送信されます。この方式では、ゲートウェイ（secure.softbank.ne.jp）が通信内容を見たり、改変したりすることができてしまいます。

図2　ソフトバンクの旧来のSSL

　この形態は、通常、中間者攻撃（Man-in-the-Middle Attack）と呼ばれる攻撃手法と同じです。

　そこでSSLには、このような盗聴・改ざんができないような仕組みが用意されています。具体的には、画面2のようにブラウザが証明書のエラーを表示して、利用者が中間者攻撃に気付くことができる仕掛けです。ここでは、secure.softbank.ne.jpにはexample.jpの証明書がないため、以下のようなエラーになります。

画面2　証明書情報が一致しないときに表示されるエラー画面

　このようなエラーを防ぐ方法はいくつかあります。このうちソフトバンクの採用していた方法は、SSLのサイトにアクセするURLを書き換えるというものです。すなわち、https://example.jp/というURLは、https://secure.softbank.ne.jp/example.jp/という形になります。

　この場合、ブラウザ側が認識するドメインはsecure.softbank.ne.jpなので、証明書のエラーにはなりません。利用者はソフトバンクの運営するsecure.softbank.ne.jpを信頼してSSLのサイトを利用することになります。

HTTPとHTTPSとでドメインが違う!?

　しかし、この方法にはいくつか問題があります。

　サイト開発者たちがまず問題にしたのは、HTTPとHTTPSが混在するサイトで、ブラウザから見たドメインが異なることです。以下は、example.jpというサイトにHTTPとHTTPSでアクセスした場合のURLです。

HTTP　　 http://example.jp/

HTTPS　　https://secure.softbank.ne.jp/example.jp/

　HTTPの際にはexample.jpドメイン、HTTPSの際にはsecure.softbank.ne.jpドメインとなるので、Cookieを共有することができません。この問題には有効な解決策がなく、secure.softbank.ne.jpの廃止によってようやく解決されました。