soft bank ssl仕様変更について
TRANSCRIPT
SoftBank SSL仕様変更について
第 1回神泉セキュリティ勉強会2010年 10月 26日 (火 )19:00-
於: (株 )ECナビ様 林 正紀 (id:m_norii)
+ちょっとおまけ有り
自己紹介
• id: m_norii (twitter, hatena)– 読み方は「m」を読まずに「のりぃ」でどうぞ
• 経歴– 2000年~ 渋谷区 SI系企業– 2004年~ 六本木ヒルズ森タワーの真ん中やや下あたり
携帯サイト (公式 )開発– 2008年~ 文京区内でシステム開発
PCサイト、携帯サイト (公式・勝手 )、 OpenSocial
現状
SSL SSL
SoftBank中間 GW
コンテンツサーバ
・ SoftBank中間 GWが SSLを中継・中間 GWはコンテンツサーバから返されるレスポンス内の httpsリクエストを中間サーバ経由に書き換える[書換前 ] https://example.com/index.html[書換後 ] https://secure.softbank.ne.jp/example.com/index.html
中間 GWの (真の )役目(想像)
SoftBank中間 GW
コンテンツサーバ
HTTPリクエスト HTTPリクエスト
HTTPレスポンスHTTPレスポンス
中間 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】 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 著作権保護
【注意点2】文字コード変換
• 中間 GWでの文字コード変換が発生しない– SoftBankでは、 EUC/ISO-2022-JP文字コードのデータが GET/POSTパラメータで来た場合、中間サーバで Shift-JISに変換して渡していた• 絵文字処理の都合と思われる
–仕様変更後は中間 GWを経由しないのでそのままの文字コードで GET/POSTパラメータが来る
• これに伴う XSSの危険性は・・・?– あってもかなりレアケースな気はするが・・・– XSSはなくても普通に文字化けるw
【注意点3】その他
• 旧式の 5バイト指定形式絵文字が利用不可に
• 一部の端末では、HTMLの記述に関わらず、リクエスト時に Hostを小文字で送出するものがある–ホスト部に英大文字を使うと、正規の証明書を認識しない可能性あり
• 詳しくは SoftBank 開発者サイト参照http://creation.mb.softbank.jp/web/web_ssl.html
障壁1: DoCoMo
• Cookieが利用できる端末は2009年 5月以降発売のもの
• まだまだ Cookie非対応端末シェア多い• ビジネス的には DoCoMo非対応というわけにはいかない・・・
障壁2: Au
• 実は SSL・非 SSLで cookie共有できない–ドメインは変わらないが、
Cookieの保存場所が違うため※これ自体は自動ログインには影響ないか?
http://www.au.kddi.com/ezfactory/tec/spec/cookie.html
まとめ
• 今回の SoftBank SSL変更は脱ガラパゴス仕様への一歩前進
• でもまだまだ壁は多い• もっとエンジニアが声を大にして主張すべき–まずは社内の企画担当、経営サイドに–携帯キャリアにもどんどん意見していくべき