au,SoftBankでSSLでCookieセッションを使用する場合の問題点
前回、「auのSSLでのCookieの挙動がおかしい - maru.cc@はてな」というエントリを書いたところ @suzukiさんから次のような発言をいただきました。
http://twitter.com/suzuki/statuses/809076312
@maru_cc https+Cookieでのセッション管理にはsecure属性付けようよ説が基本とのこと http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html
http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html
(一部抜粋)
SSL/TLS でクッキーを使うときはsecure 属性を付けるのを基本とする
・方法 A: すべてのページを https://...にしてセッション管理用のクッキーに secure 属性をつける
・方法 B: 2つのクッキーを使い分ける
ちょっと、自分のSSLをまたいだセッションを考え方が勘違いしているのかと思い、同僚に確認したりしたのですが、上記の方法でいうと、方法Bが一般的だと思います。全てのページをSSLにするのは、負荷的な意味でもあまり採用されていないのではないでしょうか?また、モバイルの場合、SSLページを開くと、都度メッセージを出す端末もあるので、必要最低限の領域以外は、非SSLで作成するのが一般的だと思います。
Cookieを使い分けた場合
http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html
・方法 B: 2つのクッキーを使い分ける
サイトの設計上、http://... の画面と https://... の画面をまたがってセッション管理を行う必要がある場合は、2つのクッキーを発行し、一方を「secure 属性なし」にし、一方を「secure 属性付き」にします。http://... の画面ではセッション管理に前者のクッキーを使用し、https://... の画面では後者のクッキーを使うようにします。このとき、暗号化で保護が必要な画面(https:// を使うことにした画面)に対して、http:// でアクセスされても情報を表示しないように作る必要があります。そうしないと、攻撃者が、盗聴で盗み出した http:// 用のクッキーを使って、重要情報にアクセスできてしまうからです。
SSL用のsecure属性付きのCookieセッション
SoftBankは、そもそもSSL領域のCookieを、http領域で取得できないので、ある意味secure付きのような動作になります。
auの仕様は、secure属性を付ければ、http領域でCookieは送ってきません。
ですので、SSL領域だけで使用する、secure付きのCookieを使用したセッションは問題ないことになります。
非SSL、SSL共通のsecure属性無しのCookieセッション
こちらが大問題。
まず、SoftBankはこういった使い方が出来ません。ドメインが違うから、SSLと非SSLで Cookieを維持することが出来ませんが、SoftBankの場合には、そもそも共有できないので、別の方法を模索する必要がありますが、ある意味「使えない」だけだとも言えるかと思います。
一方、auの場合には、一見共有して使えているように思えるところが落とし穴です。
例えば、SSL領域で以下のような Cookieを使用したセッションIDを振り出したとします。
2の非SSL/SSL共有のCookieセッションは、前回書いた仕様の通りに、非SSL領域からも参照できますが、次のような問題があります。
実際にアプリを作る時に、結構致命的な感じがするのですが、いかがでしょうか?