Soft bank ssl仕様変更について

2,420 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,420
On SlideShare
0
From Embeds
0
Number of Embeds
90
Actions
Shares
0
Downloads
6
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Soft bank ssl仕様変更について

  1. 1. SoftBank SSL 仕様変更について 第 1 回神泉セキュリティ勉強会 2010 年 10 月 26 日 ( 火 )19:00- 於: ( 株 )EC ナビ様 林 正紀 (id:m_norii) +ちょっとおまけ有り
  2. 2. はじめに <ul><li>会場を提供していただきました ( 株 )EC ナビ様 LT の機会を設けていただきました haruyama 様 ありがとうございます! </li></ul>
  3. 3. 自己紹介 <ul><li>id: m_norii (twitter, hatena) </li></ul><ul><ul><li>読み方は「 m 」を読まずに「のりぃ」でどうぞ </li></ul></ul><ul><li>経歴 </li></ul><ul><ul><li>2000 年~ 渋谷区 SI 系企業 </li></ul></ul><ul><ul><li>2004 年~ 六本木ヒルズ森タワーの真ん中やや下あたり 携帯サイト ( 公式 ) 開発 </li></ul></ul><ul><ul><li>2008 年~ 文京区内でシステム開発 PC サイト、携帯サイト ( 公式・勝手 ) 、 OpenSocial </li></ul></ul>
  4. 4. 今日の LT のきっかけ
  5. 5. 2010 年 10 月 15 日
  6. 6. http://mb.softbank.jp/mb/information/details/101015.html
  7. 7. え?どういうこと? ( ; ´Д ` )
  8. 9. な・・・なんだって !? (((( ; ゚ д ゚ ))))
  9. 11. さらに開発者サイトを見ると
  10. 12. http://creation.mb.softbank.jp/web/web_ssl.html
  11. 15. ・・・と、つぶやいたら
  12. 17. ・・・で、今に至ります(・ ω ・;)
  13. 18. ということで。
  14. 19. SoftBank SSL 仕様変更について (2011 年 2 月より )
  15. 20. 現状 SSL SSL SoftBank 中間 GW コンテンツサーバ ・ SoftBank 中間 GW が SSL を中継 ・中間 GW はコンテンツサーバから返されるレスポンス内の https リクエストを中間サーバ経由に書き換える [ 書換前 ] https://example.com/index.html [ 書換後 ] https:// secure.softbank.ne.jp /example.com/index.html
  16. 21. 2011 年 2 月からの仕様 SSL コンテンツサーバ ・端末は中間 GW を経由せず、直接コンテンツサーバと SSL 接続を確立する
  17. 22. ( 主に携帯サイト開発未経験者からの )FAQ
  18. 23. 「つか、後者の方が普通じゃね?」
  19. 24. 「そうですね」
  20. 25. ( 主に携帯サイト開発未経験者からの )FAQ その 2
  21. 26. 「つか、何でそんな仕様なの?」
  22. 27. 「・・・・・」
  23. 28. 中間 GW の ( 真の ) 役目(想像) SoftBank 中間 GW コンテンツサーバ HTTP リクエスト HTTP リクエスト HTTP レスポンス HTTP レスポンス 中間 GW はコンテンツサーバへのリクエストに、個体識別 ID などの情報を付加する 中間 GW はコンテンツサーバへのレスポンスで、画像等の著作権保護設定(コピー禁止等)処理を入れる
  24. 29. 個体識別 ID など、中間 GW で 追加する情報のため(と思われる)
  25. 30. でもこの方式には問題が。
  26. 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 で ドメインが違う
  27. 32. なので・・・
  28. 33. (1) 非 SSL と SSL で cookie の共有ができない
  29. 34. (2) ダイジェスト認証が使えない
  30. 35. つまり、インターネット標準でない
  31. 36. なので・・・
  32. 38. となったようです・・・
  33. 39. ・・・・・
  34. 40. ともあれ、 変わるものは変わるので・・・
  35. 41. SoftBank SSL 仕様変更に伴う サイト側の注意点
  36. 42. 【注意点1】 https 通信時は SoftBank 独自ヘッダが付与されない <ul><li>特に要注意は </li></ul><ul><ul><li>個体識別 ID : x-jphone-uid </li></ul></ul><ul><ul><li>端末モデル識別用: x-jphone-msname </li></ul></ul><ul><li>対策 </li></ul><ul><ul><li>端末判定は UserAgent で </li></ul></ul><ul><ul><li>個体識別 ID は非 SSL 領域から hidden で渡す </li></ul></ul><ul><ul><ul><li>セッションでは ( 現行 SSL 仕様では)渡せないので注意 </li></ul></ul></ul>- 例えば、個体識別 ID を止める
  37. 43. 危険な実装 (1) <ul><li>x-jphone-uid が「来る前提」での実装 </li></ul>SSL SSL (1) 1 人目が個人情報登録。 UID が空文字で保存 (1) 2 人目が個人情報閲覧。 UID 空文字をキーに検索 -> 1 人目の情報が見えてしまう! UID 名前 住所 ( 空文字 ) hoge *****
  38. 44. 危険な実装 (2) <ul><li>セッション ID を、開発言語が提供する方式ではなく、 x-jphone-uid に差し替えている場合 </li></ul><?php ・・・・・ session_id($_SERVER['HTTP_X_JPHONE_UID']); session_start(); ・・・・・
  39. 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 著作権保護
  40. 46. 【注意点2】文字コード変換 <ul><li>中間 GW での文字コード変換が発生しない </li></ul><ul><ul><li>SoftBank では、 EUC/ISO-2022-JP 文字コードのデータが GET/POST パラメータで来た場合、中間サーバで Shift-JIS に変換して渡していた </li></ul></ul><ul><ul><ul><li>絵文字処理の都合と思われる </li></ul></ul></ul><ul><ul><li>仕様変更後は中間 GW を経由しないので そのままの文字コードで GET/POST パラメータが 来る </li></ul></ul><ul><li>これに伴う XSS の危険性は・・・? </li></ul><ul><ul><li>あってもかなりレアケースな気はするが・・・ </li></ul></ul><ul><ul><li>XSS はなくても普通に文字化けるw </li></ul></ul>
  41. 47. 【注意点3】その他 <ul><li>旧式の 5 バイト指定形式絵文字が利用不可に </li></ul><ul><li>一部の端末では、HTMLの記述に関わらず、リクエスト時に Host を小文字で送出するものがある </li></ul><ul><ul><li>ホスト部に英大文字を使うと、正規の証明書を認識しない可能性あり </li></ul></ul><ul><li>詳しくは SoftBank 開発者サイト参照 http://creation.mb.softbank.jp/web/web_ssl.html </li></ul>
  42. 48. 仕様変更後、よくなること <ul><li>非 SSL と SSL で cookie 共有可に </li></ul><ul><li>ダイジェスト認証が利用可能に </li></ul>
  43. 49. ところで・・・
  44. 50. 今、携帯 UID でホッテントリといえば
  45. 51. 何を言いたいかは察して下さいw
  46. 52. 顛末は http://togetter.com/li/62685 を見てもらうとして
  47. 55. http://takagi-hiromitsu.jp/diary/20101025.html#p01
  48. 56. おっしゃるとおりでは あるのですが・・・
  49. 57. 実はまだ障壁が・・・
  50. 58. 障壁1: DoCoMo <ul><li>Cookie が利用できる端末は 2009 年 5 月以降発売のもの </li></ul><ul><li>まだまだ Cookie 非対応端末シェア多い </li></ul><ul><li>ビジネス的には DoCoMo 非対応というわけにはいかない・・・ </li></ul>
  51. 59. 障壁2: Au <ul><li>実は SSL ・非 SSL で cookie 共有できない </li></ul><ul><ul><li>ドメインは変わらないが、 Cookie の保存場所が違うため </li></ul></ul><ul><li>※ これ自体は自動ログインには影響ないか? </li></ul>http://www.au.kddi.com/ezfactory/tec/spec/cookie.html
  52. 60. まとめ <ul><li>今回の SoftBank SSL 変更は 脱ガラパゴス仕様への一歩前進 </li></ul><ul><li>でもまだまだ壁は多い </li></ul><ul><li>もっとエンジニアが声を大にして主張すべき </li></ul><ul><ul><li>まずは社内の企画担当、経営サイドに </li></ul></ul><ul><ul><li>携帯キャリアにもどんどん意見していくべき </li></ul></ul>
  53. 61. ご静聴ありがとうございました

×