ガラケー×SSLTips開発Tips

2011/10/27 高倉利明2011/10/27 高倉利明

今日の内容

いまさらガラケー？

→現実的に案件はまだまだあるよね。

今日の内容

なぜSSLに特化した話？SSL

→PCサイト構築中心にやってた人は甘く見がちだが、特にはまりやすいのがSSL関連。のがSSL関連。

今日の内容

目次

•テストサイトでも証明書買え！•リダイレクトとSSL• SSL下でのセッション維持• SSL下でのセッション維持

その１

テストサイトでもテストサイトでも証明書買え！

PCの場合PC→自己認証証明書でとりあえず確認できる。

ガラケー実機の場合

＼(＾o＾)／

自己認証証明書では自己認証証明書ではガラケー実機でSSLの確認できない！

•ガラケーサイトでは必ず認証局認証済みの証明書を準備する必要がある

まとめ：テストサイトでも証明書買え！

証明書を準備する必要がある※特にauは勝手証明書アクセス全滅

•どこの証明書買えばいいの？→迷ったらVeriSign

その２

リダイレクトとSSLリダイレクトとSSL

・リダイレクト回数・リダイレクト回数

・au×SSLリダイレクト時のLocation指定のLocation指定

リダイレクト回数

キャリア（＆機種）毎にリダイレキャリア（＆機種）毎にリダイレクト可能な回数がある

※エミュレータでは起きないの※エミュレータでは起きないので気づきにくい。

一般的にはDoCoMo: 最大4回（超えた場合は「無効なデータを受信しました」）（超えた場合は「無効なデータを受信しました」）

Softbank: 最大4回（超えた場合は「このページは表示できません」）

au: 最大6回（超えた場合は「このページへのｱｸｾｽは拒否されました」）（超えた場合は「このページへのｱｸｾｽは拒否されました」）

※非公式調査なので注意

で、リダイレクト回数がSSLと関係あるの？SSLと関係あるの？

→大あり

SSLなしの場合%http://hoge.jp→ http://hoge.jp/→ http://hoge.jp/→ http://hoge.jp/m/→ http://hoge.jp/m/mypage

リダイレクト3回→セーフリダイレクト3回→セーフ

SSLだと%https://hoge.jp→ https://hoge.jp/→ https://hoge.jp/→ http://hoge.jp/→ http://hoge.jp/m/→ http://hoge.jp/m/mypage→ https://hoge.jp/m/mypage→ https://hoge.jp/m/mypage

リダイレクト5回→アウト

au×SSLリダイレクト時のLocation指定

au × SSL環境下の場合、リダイレクトのau × SSL環境下の場合、リダイレクトのLocationに相対パスで指定する必要がある。

※これもエミュレータでは起きないので気※これもエミュレータでは起きないので気づきにくい。

例：PHPの場合

https://www.sample.com/aaa/で～

<?phpheader(locaiont”https://www.sample.com/aaa/bbb.php”);?>

→502エラー

<?phpheader(location:”bbb.php”);?>

→正常にリダイレクト

•キャリア毎にリダイレクト回数制限がある＆SSLかけるとリダイレクト回数増加

まとめ：リダイレクトとSSL

•au × SSLの場合、リダイレクトのLocationに相対パスで指定する必要あり。

•エミュレータでは起きないのでテストフェーズ•エミュレータでは起きないのでテストフェーズまで気づかないことが多い→回避するには大幅なプログラム修正要→開発の早い段階で実機確認を行うべし。

その３

SSL下でのSSL下での

セッション維持

前提PCでのセッション維持→Cookie一択→Cookie一択

前提ガラケーでのセッション維持→いろいろ→いろいろ(1)セッションID(2)UID(3)Cookie(3)Cookie

(1)セッションID古くからある方法。リンクパラメータでIDを引き回す。リンクパラメータでIDを引き回す。http://hoge.jp/?sid=0011AABBCC....

問題点リンクが分かればセッション乗っ取れる。→「認証前にセッションを有効にしない」、→「認証前にセッションを有効にしない」、「Refererでの漏洩を防ぐ」「セッションIDの一定期間での振り替え」などを考慮。

(2)UID (個体識別情報)キャリア毎に用意されている回線契約や端末に紐づくID。これを使用してセッショ端末に紐づくID。これを使用してセッション維持する。

注. 今回は説明割愛します。※UIDに種類がいろいろあり説明が複雑にな※UIDに種類がいろいろあり説明が複雑になるのと、セキュリティ的に今後非推奨になっていくと思われるので。

(3)CookiePCと同じように使う。Web標準。

問題点以下の理由によりガラケーでは最近まであまり使われていなかった。

•DoCoMoのiモードブラウザ1.0では使えな•DoCoMoのiモードブラウザ1.0では使えない！※2009/6 以前発売端末•SSL絡みの挙動※後述

ということで・・・•Cookie使える端末

→Cookie→Cookie•Cookie使えない端末

→セッションID

T木先生もT丸先生も推薦。T木先生もT丸先生も推薦。セキュリティもばっちり！ b(^-^)o

よし、SSLでよし、SSLでテスト！

( ﾟдﾟ)( ﾟдﾟ)ａu端末でセッション切れる・・・ン切れる・・・

HTTPで発行したCookieのHTTPSとの共有

・DoCoMo できる・DoCoMo できる・Softbank できる・au できない・au できない

※注．2011/10末現在

DoCoMoの場合。。。

HTTPで発行したCookieのHTTPS間HTTP Cookie HTTPSとの共有ができる。

→しかしiモードブラウザ1.0端末ではCookie使えない。。。ではCookie使えない。。。

Softbankの場合。。。

HTTPで発行したCookieのHTTPS間HTTP Cookie HTTPSとの共有ができる。

※余談：旧仕様 2011/6/30で廃止・HTTP接続：http://hoge.jp/http://hoge.jp/・ HTTPS接続：https://secure.softbank.ne.jp/hoge.jp/

→ドメインが違うので、Cookieを引き継げない。

auの場合。。。

HTTPで発行したCookieのHTTPS間との共有はできない。有はできない。→理由・HTTPS接続：端末にCookie保存・HTTP接続：GWサーバにCookie保存

→普通に実装すると、 HTTP⇔HTTPSの遷移でCookieが変わる（＝セッションが引き継がれない）

auの場合。。。

設定時の条件設定時の条件設定時の条件設定時の条件 HTTPHTTPHTTPHTTPでのでのでのでの参照参照参照参照 HTTPSHTTPSHTTPSHTTPSでのでのでのでの参照参照参照参照

HTTPで設定 ○ × （本来○であるべき）

→このためセッション維持のためHTTPとHTTPS両方か

HTTPSで設定（セキュア属性なし）

○ ○

HTTPSで設定（セキュア属性付き）

× ○

→このためセッション維持のためHTTPとHTTPS両方から参照できるCookieを設定するためには、HTTPS側でCookieを設定する必要がある。＝プログラム側で大幅な改造が必要。

余談：2011年秋冬モデル以降は、この縛りはなくなるものと思われる。

au/KDDIの「KDDI au: そのほかの技術情報 > Cookie」au/KDDIの「KDDI au: そのほかの技術情報 > Cookie」→Cookieはブラウザ側に全て保存される予定。

上記により以下のケースでセッション維持方針がかわってくる。

(1)サイト全てをHTTPSページとする場合※問題点あり(2)サイトでHTTP、 HTTPSページを使い分ける場合使い分ける場合

※(1)の問題点画面遷移やリダイレクト毎にいちいち「SSLで接続します」等のダイアログが出てしまうので、UI的に非常にイケていない。

まとめ：SSL下でのセッション維持

(1)サイト全てをHTTPSページとする場合場合

•Cookie使える端末の場合→Cookie

•Cookie使えない端末の場合•Cookie使えない端末の場合→セッションID（等）

まとめ：SSL下でのセッション維持

(2)サイトでHTTP、 HTTPSページを使い分ける場合使い分ける場合

（ｉ） au以外•Cookie使える端末の場合

→Cookie→Cookie•Cookie使えない端末の場合

→セッションID（等）

まとめ：SSL下でのセッション維持

(2)サイトでHTTP、 HTTPSページを使い分ける場合使い分ける場合

（ｉｉ） auセッションID（等）を使用 ｏｒセッション維持用のCookieはHTTPSでセット・セッション維持用のCookieはHTTPSでセット・変更する

まとめ：SSL下でのセッション維持

補足：Ｃｏｏｋｉｅ使えない場合に「セッションＩＤＣｏｏｋｉｅ使えない場合に「セッションＩＤ（等）」としたのは、実案件ではUIDを併用したセッション維持を行わざるを得ないケースも多いため。

※かんたんログイン%etc

おさらいおさらい

•ガラケーサイトでは必ず認証局認証済みの証明書を準備する必要がある

まとめ：テストサイトでも証明書買え！

証明書を準備する必要がある※特にauは勝手証明書アクセス全滅

•どこの証明書買えばいいの？•→迷ったらVerisign

•キャリア毎にリダイレクト回数制限がある＆SSLかけるとリダイレクト回数増加

まとめ：リダイレクトとSSL

•au × SSLの場合、リダイレクトのLocationに相対パスで指定する必要あり。

•エミュレータでは起きないのでテストフェーズ•エミュレータでは起きないのでテストフェーズまで気づかないことが多い→回避するには大幅なプログラム修正要→開発の早い段階で実機確認を行うべし。

まとめ：SSL下でのセッション維持

(1)サイト全てをHTTPSページとする場合場合

•Cookie使える端末の場合→Cookie

•Cookie使えない端末の場合•Cookie使えない端末の場合→セッションID（等）

まとめ：SSL下でのセッション維持

(2)サイトでHTTP、 HTTPSページを使い分ける場合使い分ける場合

（ｉ） au以外•Cookie使える端末の場合

→Cookie→Cookie•Cookie使えない端末の場合

→セッションID（等）

まとめ：SSL下でのセッション維持

(2)サイトでHTTP、 HTTPSページを使い分ける場合使い分ける場合

（ｉｉ） auセッションID（等）を使用 ｏｒセッション維持用のCookieはHTTPSでセット・セッション維持用のCookieはHTTPSでセット・変更する

まとめ：SSL下でのセッション維持

補足：Ｃｏｏｋｉｅ使えない場合に「セッションＩＤＣｏｏｋｉｅ使えない場合に「セッションＩＤ（等）」としたのは、実案件ではUIDを併用したセッション維持を行わざるを得ないケースも多いため。

※かんたんログイン%etc

質疑応答質疑応答

ご静聴ご静聴ありがとうございました。ございました。