auのSSLでのCookieの挙動がおかしい

auはCookieを使うことが出来る。キャリアの公式情報としても公開されている。
「404 Not Found」

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

つまり

httpの非SSL領域では、ゲートウェイ（EZサーバ）がCookieを保管する
httpsのEnt to EndのSSL領域では、端末がCookieを保管する

ということだ。

これが結構曲者である。

さらに、公式な資料はないけど、端末の挙動から想像するに以下のような挙動をする。

http領域では、GWと端末の両方のCookieを送ってくる
http領域で、GWと端末に同じ名前でCookieが設定されている場合、端末のCookieが優先する
http領域からは、端末のCookieを操作することは出来ない
https領域では、当然GWのCookieは参照できない

実験

ためしに以下のようなファイルを同一ドメインの http と https
領域に置いて、確認をしてみる。

<html>
<head>
<meta http-equiv="Pragma" content="no-cache">
</head>
<body>
<pre>
<?php
print_r($_COOKIE);

$value = "test:".date('H:i:s').' '.$_SERVER['SERVER_PORT'];
$timeout = time() + 30;
setcookie("test",$value,$timeout);
setcookie("test".$_SERVER['SERVER_PORT'],$value,$timeout);
?>
</pre>
<hr>
<a href="http://example.com/?nocache=<?php echo md5(microtime())
?>">http</a><br>
<a href="https://example.com/?nocache=<?php echo md5(microtime())
?>">https</a><br>
</body>
</html>

http、https 領域でそれぞれ設定した cookie
をそれぞれの環境で確認してみるというものだ。
Cookie
の有効期限を指定しない場合には、デフォルトで1日になるため、テストのために短めに時間設定をしている。

確認手順

1.http側にアクセス
2.リロード
3.https側へ遷移
4.リロード
5.http側へ遷移（2から30秒以内に）
6.リロード（2から30秒以内に）
7.リロード（2から30秒以降に）

それぞれ次のようになる。
角括弧の中は、アクセスした時間です。

1.[12:00:00]http側にアクセス

Array
(
)

2.[12:00:05]リロード

Array
(
    [test] => test:12:00:00 80
    [test80] => test:12:00:00 80
)

3.[12:00:10]https側へ遷移

Array
(
)

4.[12:00:15]リロード

Array
(
    [test] => test:12:00:10 443
    [test443] => test:12:00:10 443
)

5.[12:00:20]http側へ遷移（2から30秒以内に）

Array
(
    [test] => test:12:00:15 443
    [test80] => test:12:00:05 80
    [test443] => test:12:00:15 443
)

6.[12:00:25]http側へ遷移（2から30秒以内に）

Array
(
    [test] => test:12:00:15 443
    [test80] => test:12:00:20 80
    [test443] => test:12:00:15 443
)

7.[12:00:45]リロード（2から30秒以降に）

Array
(
    [test] => test:12:00:25 80
    [test80] => test:12:00:25 80
)

この変な挙動がわかるだろうか？
6の処理の時に、https側の値が書き換えられないので、キーが「test」の値が更新できないでいる。
(追記:7の値が変だったので修正)

問題点

http<->https をまたいで Cookie を、直接使うことはないと思うが、セッションで
Cookieを使用し、問題が出ることが大いにありそうだ。

考えられる可能性として同じセッション名を使っているとして

http側で発行した Cookieを使用したセッションが、https側で継続できない
逆にhttpsで発行したセッションIDを、http側でも送ってくる
http,httpsで違うセッションIDを発行している場合に、httpsを経由し、http側に戻ってきた場合にhttp側のセッションID取得できない
httpsを経由すると、http側で有効期限の更新などができない

まとめ

auの Cookieの仕様は、SSLがからむとかなり微妙な動きをするので要注意。
Cookieを使用したセッションを使う場合には、httpとhttpsで違うセッション名にするの吉。

ってか、最近セキュリティ関連の中で、Cookieを使用したセッション使おうよ。みたいなのを目にするけど、どうなのだろうか？

ついでに

SoftBankの場合には、SSL領域では、secure.softbank.ne.jp というドメインが使用されます。

httpの非SSL領域
- http://example.com/
httpsのSSL領域
- https://secure.softbank.ne.jp/example.com/

ドメインが違うので、そもそもCookieを引き継ぐことが出来ない。
※メール文面から起動すると、https://example.com/ で開けるけど。

一般的な、SSL領域でログインして、そのセッションを引き継いで非SSLサイト側で会員向け表示といった使い方が出来ない。

で、結局

Cookieベースのセッション使って、SSLページがあるモバイルサイト作ってるとこってあるのでしょうか？

追記

SSLをまたいだセッションで使用する場合の問題点を考えてみました。
「au,SoftBankでSSLでCookieセッションを使用する場合の問題点 - maru.cc@はてな」

追記

docomoの場合も調べてみました
「DoCoMo iモードブラウザ2.0でCookie - maru.cc@はてな」