EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点
au/KDDIの技術情報サイトEZfactoryには、2011年秋冬モデル以降にEZwebの仕様変更がある旨表示されています。セキュリティ上の問題の可能性もあるため以下に報告します。
EZfactoryトップページでの告知内容
EZfactoryトップページには、2011年秋冬モデルでの変更を以下のように要約しています。
※お知らせ※
EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。
これによる主な変更点は以下のとおりです。＜主な変更点＞
・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。
・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。今後EZブラウザ向けコンテンツを作成する場合は、XHTML Basicを推奨します。
http://www.au.kddi.com/ezfactory/
これら以外の重要な変更として、Cookieに関する扱いが変更されます。このエントリでは、事業者ゲートウェイ（EZサーバ）のIPアドレスの問題と、Cookieの扱いについて報告します。
事業者ゲートウェイのIPアドレスについて
IPアドレスについてはKDDI au: 技術情報 > IPアドレス帯域に記載されています。「※2011年秋冬モデル以降の端末では、搭載されるEZブラウザ、PCSVの各ブラウザのIPアドレスが、統一されます」とのことですが、これはセキュリティの観点から重要な意味を持つと思われます。
三大キャリア（NTTドコモ、KDDI、ソフトバンク）のうち、NTTドコモとソフトバンクのケータイブラウザにはJavaScript機能が搭載されており、DNSリバインディングによる成りすましなどのリスクが生じていました。一方、KDDIの端末のみはJavaScript機能が提供されておらず、結果的にセキュリティ上のリスクも低い状態でした。
2011年秋冬モデルでもEZブラウザにJavaScript機能が搭載される予定はないようですが、JavaScript機能があるPCサイトビューアのIPアドレスが統一されることで、結果として、事業者ゲートウェイを経由する端末の中に、JavaScript機能を搭載したものが含まれる状態が生まれます。このため、JavaScriptを悪用した攻撃の可能性が生じてきます。具体的には、JavaScriptによるEZ番号（サブスクライバID）の偽装、DNSリバインディング攻撃などの可能性が生じます。
現時点では端末実機がない状態であるので検証はできませんが、現在流通している端末のPCサイトビューアで検証した結果を報告します。検証にはW52T（2007年2月発売）とbiblio（2009年6月発売）を用いました。検証内容は、XMLHttpRequestオブジェクトのsetRequestHeaderメソッドで、リクエストヘッダUser-AgentとX-UP-SUBNO（EZ番号）を変更できるかどうかを確認しました。結果は以下の通りです。
| ヘッダ | W52T | biblio |
|---|---|---|
| User-Agent | 変更できる | 変更できない |
| X-UP-SUBNO | 追加できる | 追加できる |
上記のように、現状のPCサイトビューアでは、EZ番号が追加できるほか、W52TではUser-Agentも変更できます。2011年秋冬モデルの仕様はわかりませんが、上記と同じ仕様である場合、EZ番号の偽装が可能になります。具体的な攻撃手口はi-mode2.0セキュリティの検討: 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 - 徳丸浩の日記(2009-08-05)を参照ください*1。現時点で、EZブラウザとPCサイトビューアを区別する確実な方法は、EZfactoryには告知されていないようですし、現在稼働しているサイトが無修正で安全かどうかも不明です。
この問題に対する確実な対策は、ケータイサイトもPC向けの一般的なWebサイトと同じ作り方とすることです。具体的には、EZ番号を認証等に使用せず、Cookieによるセッション管理を行うことです。PC向けのサイトではJavaScriptが使用できるのは当然の前提であり、セキュリティ上の問題の解決方法も周知されているからです。
上記の内容について、秋冬モデルの実機が入手できれば再度検証する予定です。
Cookieの仕様変更
EZfactoryのトップページには明記されていませんがCookieに関する仕様も変更されているようです。
EZwebのCookieは、HTTPでセットされたCookieは事業者ゲートウェイ（EZサーバ）に保存され、HTTPSでセットされたCookieは端末に保存される仕様です（下記）。
EZweb対応端末においてCookieは、EZサーバに保管されます。
http://www.au.kddi.com/ezfactory/tec/spec/cookie.html
※ただし、WAP2.0ブラウザ搭載端末ではEnd to EndのSSL通信時は端末に保管されます。
ところが、その下の表を見ると、2011年秋冬モデル以降では「EZブラウザにて保存・管理される場合」のみが記載されています。以下に引用します。
さらに、Cookieの有効期限の項を見ると、以下の記載があります。
デフォルトの有効期限
http://www.au.kddi.com/ezfactory/tec/spec/cookie.html
「max-age」の有効期限の指定がない場合、2011年夏モデル以前のEZブラウザと2011年秋冬モデル以降のEZブラウザとで仕様が異なります。
2011年夏モデル以前 ：デフォルトで「1日 (24時間)」。
2011年秋冬モデル以降 ：ブラウザ起動中のみ有効、ブラウザ終了時に削除。
「2011年秋冬モデル以降 ：ブラウザ起動中のみ有効、ブラウザ終了時に削除」という仕様は、Cookieをゲートウェイに保存する方法は実装が難しいと考えられます。「ブラウザ終了」というイベントをゲートウェイに確実に伝えることが難しいからです。ブラウザを終了した時点の電波状態によっては、サーバーに「ブラウザ終了」というイベントを伝えることができません。少し発想を変えて、ブラウザ起動時に、デフォルトの有効期限を持つCookieをクリアすれば、「ブラウザ終了時に削除」と同じ結果になると思われますが、わざわざそのような実装にしてまで仕様変更する動機を思いつきません。先の表の内容とあわせて考えると、Cookieが常に端末に保存される仕様になったと考える方が自然です。
仮に、Cookieが常に端末に保存されるとすると、HTTP/HTTPS混在のサイトでのCookieの挙動が現在と変わります。現在は、「HTTPでセットされたCookieはHTTPSでは参照できない」という状態ですが、HTTPSでも参照できるようになるからです。詳しくは、「体系的に学ぶ 安全なWebアプリケーションの作り方」の「7.2.2 クッキーの仕様(P408)」を参照してください。仕様変更後は、通常のPCやiモードブラウザ2.0等と同じ挙動となるので、これらで正常に動作するアプリケーションであれば、Cookieの挙動が変更された後でも正常に動作するはずです。ただし、キャリア判定により動作を変えている場合は、その部分の実装を変更する必要があります。
上記も現時点では推測であるため、実機入手後に検証したいと思います。
EZ番号に関する注意
EZfactoryには、EZ番号に関して、以下のような情報も追加されていました。
※EZ番号に関する注意
http://www.au.kddi.com/ezfactory/tec/spec/4_4.html
EZ番号はスマートフォン等では詐称可能なため、ユーザー認証に用いる場合には、EZ番号と併せてEZサーバのIPアドレス等、複数手段で確認してください。
これはダメでしょう。EZ番号をユーザ認証に用いる状況をキャリアとして公式に認めている一方で、安全な確認方法は具体的に示されていないからです。
KDDIは以下のいずれかの告知方法を選択するべきだと考えます。
- EZ番号を認証に用いるための公式な実装方法を具体的に告知する
- EZ番号を認証に用いることを禁止する
現在の状況では、安全な方法は保証されておらず、かつスマートフォンの登場や2011年秋冬モデルでの仕様変更によりリスクが高まっているため、EZ番号を認証に用いることは廃止すべきだと考えます。すなわち、いわゆる「かんたんログイン」をやめ、パスワード認証とCookieによる認証状態保持というPCと同じ実装に移行することを推奨します。
[PR]
第3回アイティメディア チャリティイベントにて、「パスワード保護の現状と課題」と題して講演します。Webアプリケーションでパスワードをハッシュなどで保存する方法について解説します。興味のある方はこちらからお申し込みください。紹介ブログ。
体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
- 作者: 徳丸浩
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2011/03/01
- メディア: 単行本
- 購入: 119人 クリック: 4,283回
- この商品を含むブログ (146件) を見る
