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