1. SoftBank SSL 仕様変更について 第 1 回神泉セキュリティ勉強会 2010 年 10 月 26 日 ( 火 )19:00- 於： ( 株 )EC ナビ様 林 正紀 (id:m_norii) ＋ちょっとおまけ有り

2. はじめに 会場を提供していただきました ( 株 )EC ナビ様 LT の機会を設けていただきました haruyama 様 ありがとうございます！

3. 自己紹介 id: m_norii (twitter, hatena) 読み方は「 m 」を読まずに「のりぃ」でどうぞ 経歴 2000 年～ 渋谷区 SI 系企業 2004 年～ 六本木ヒルズ森タワーの真ん中やや下あたり 携帯サイト ( 公式 ) 開発 2008 年～ 文京区内でシステム開発 PC サイト、携帯サイト ( 公式・勝手 ) 、 OpenSocial

4. 今日の LT のきっかけ

5. 2010 年 10 月 15 日

6. http://mb.softbank.jp/mb/information/details/101015.html

7. え？どういうこと？ ( ； ´Д ｀ )

9. な・・・なんだって !? (((( ; ﾟ д ﾟ ))))

11. さらに開発者サイトを見ると

12. http://creation.mb.softbank.jp/web/web_ssl.html

15. ・・・と、つぶやいたら

17. ・・・で、今に至ります（・ ω ・；）

18. ということで。

19. SoftBank SSL 仕様変更について (2011 年 2 月より )

20. 現状 SSL SSL SoftBank 中間 GW コンテンツサーバ ・ SoftBank 中間 GW が SSL を中継 ・中間 GW はコンテンツサーバから返されるレスポンス内の https リクエストを中間サーバ経由に書き換える [ 書換前 ] https://example.com/index.html [ 書換後 ] https:// secure.softbank.ne.jp /example.com/index.html

21. 2011 年 2 月からの仕様 SSL コンテンツサーバ ・端末は中間 GW を経由せず、直接コンテンツサーバと SSL 接続を確立する

22. ( 主に携帯サイト開発未経験者からの )FAQ

23. 「つか、後者の方が普通じゃね？」

24. 「そうですね」

25. ( 主に携帯サイト開発未経験者からの )FAQ その 2

26. 「つか、何でそんな仕様なの？」

27. 「・・・・・」

28. 中間 GW の ( 真の ) 役目（想像） SoftBank 中間 GW コンテンツサーバ HTTP リクエスト HTTP リクエスト HTTP レスポンス HTTP レスポンス 中間 GW はコンテンツサーバへのリクエストに、個体識別 ID などの情報を付加する 中間 GW はコンテンツサーバへのレスポンスで、画像等の著作権保護設定（コピー禁止等）処理を入れる

29. 個体識別 ID など、中間 GW で 追加する情報のため（と思われる）

30. でもこの方式には問題が。

31. 現状 SSL SSL SoftBank 中間 GW コンテンツサーバ ・ SoftBank 中間 GW が SSL を中継 ・中間 GW はコンテンツサーバから返されるレスポンス内の https リクエストを中間サーバ経由に書き換える [ 書換前 ] https://example.com/index.html [ 書換後 ] https:// secure.softbank.ne.jp /example.com/index.html 非 SSL と SSL で ドメインが違う

32. なので・・・

33. (1) 非 SSL と SSL で cookie の共有ができない

34. (2) ダイジェスト認証が使えない

35. つまり、インターネット標準でない

36. なので・・・

38. となったようです・・・

39. ・・・・・

40. ともあれ、 変わるものは変わるので・・・

41. SoftBank SSL 仕様変更に伴う サイト側の注意点

42. 【注意点１】 https 通信時は SoftBank 独自ヘッダが付与されない 特に要注意は 個体識別 ID : x-jphone-uid 端末モデル識別用： x-jphone-msname 対策 端末判定は UserAgent で 個体識別 ID は非 SSL 領域から hidden で渡す セッションでは ( 現行 SSL 仕様では）渡せないので注意 － 例えば、個体識別 ID を止める

43. 危険な実装 (1) x-jphone-uid が「来る前提」での実装 SSL SSL (1) 1 人目が個人情報登録。 UID が空文字で保存 (1) 2 人目が個人情報閲覧。 UID 空文字をキーに検索 -> 1 人目の情報が見えてしまう！ UID 名前 住所 ( 空文字 ) hoge *****

44. 危険な実装 (2) セッション ID を、開発言語が提供する方式ではなく、 x-jphone-uid に差し替えている場合 <?php ・・・・・ session_id($_SERVER['HTTP_X_JPHONE_UID']); session_start(); ・・・・・

45. https 通信時に使用できなくなる SoftBank 独自 HTTP ヘッダ 種別 HTTP ヘッダ名 内容 リクエストヘッダ x-jphone-color メインディスプレイの色数 x-jphone-display 端末の画面サイズ x-jphone-msname 機種名称 x-jphone-region リージョン情報 x-jphone-smaf 再生できる SMAF x-jphone-uid 利用者の識別子 x-s-bearer ネットワーク種別 ( 無線 LAN 利用の場合 ) レスポンスヘッダ x-jphone-copyright 著作権保護

46. 【注意点２】文字コード変換 中間 GW での文字コード変換が発生しない SoftBank では、 EUC/ISO-2022-JP 文字コードのデータが GET/POST パラメータで来た場合、中間サーバで Shift-JIS に変換して渡していた 絵文字処理の都合と思われる 仕様変更後は中間 GW を経由しないので そのままの文字コードで GET/POST パラメータが 来る これに伴う XSS の危険性は・・・？ あってもかなりレアケースな気はするが・・・ XSS はなくても普通に文字化けるｗ

47. 【注意点３】その他 旧式の 5 バイト指定形式絵文字が利用不可に 一部の端末では、ＨＴＭＬの記述に関わらず、リクエスト時に Host を小文字で送出するものがある ホスト部に英大文字を使うと、正規の証明書を認識しない可能性あり 詳しくは SoftBank 開発者サイト参照 http://creation.mb.softbank.jp/web/web_ssl.html

48. 仕様変更後、よくなること 非 SSL と SSL で cookie 共有可に ダイジェスト認証が利用可能に

49. ところで・・・

50. 今、携帯 UID でホッテントリといえば

51. 何を言いたいかは察して下さいｗ

52. 顛末は http://togetter.com/li/62685 を見てもらうとして

55. http://takagi-hiromitsu.jp/diary/20101025.html#p01

56. おっしゃるとおりでは あるのですが・・・

57. 実はまだ障壁が・・・

58. 障壁１： DoCoMo Cookie が利用できる端末は 2009 年 5 月以降発売のもの まだまだ Cookie 非対応端末シェア多い ビジネス的には DoCoMo 非対応というわけにはいかない・・・

59. 障壁２： Au 実は SSL ・非 SSL で cookie 共有できない ドメインは変わらないが、 Cookie の保存場所が違うため ※ これ自体は自動ログインには影響ないか？ http://www.au.kddi.com/ezfactory/tec/spec/cookie.html

60. まとめ 今回の SoftBank SSL 変更は 脱ガラパゴス仕様への一歩前進 でもまだまだ壁は多い もっとエンジニアが声を大にして主張すべき まずは社内の企画担当、経営サイドに 携帯キャリアにもどんどん意見していくべき

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