再考・ケータイWebのセキュリティ（最終回）：ケータイWebの今後を安全に保つには

“特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部）

2011年08月16日 00時00分 更新

　前回では、URLにセッションIDを埋め込むことの問題点を指摘した上で、今後はできるだけケータイでもCookieを使うことを提案しました。それを受けて今回は、前半で、ケータイWebでCookieを使う際の注意点について説明します。

　そして後半では、連載の終わりに当たり、スマートフォンが普及しつつある状況下でのケータイWebの今後について説明します。

ケータイWebにおけるCookieは「取り扱い注意」

　これまで説明したように、KDDIとソフトバンクのケータイでは従来からCookieが利用でき、NTTドコモの端末でも2009年夏モデル以降でCookieが利用できます。セッション管理にCookieを利用することで、セッション管理の安全性を高めることが可能です。

　ただしKDDIの端末では、Cookieの扱いに注意が必要です。KDDIの仕様書には、以下の記載があります。

　すなわち、HTTPSでSet-CookieされたCookieは端末に保存されますが、HTTPでSet-CookieされたCookieは事業者のゲートウェイ（EZサーバ）に保存されます。

　HTTPSの場合、ゲートウェイでCookie処理はできなくなるため、HTTPSのページではHTTPでセットされたCookieが参照できないことになります。

　またCookieの仕様として、secure属性のついたCookieはHTTPのページでは参照できません。これらをまとめると、下表のようになります。

　このため、EZwebで、HTTPとHTTPS両方から参照できるCookieを設定するためには、HTTPS側でCookieを設定する必要があるということです。一般的にはそのような制約はなく、EZweb独自の制約です。

　しかし、この制限は近く変更されるようです。au/KDDIの「KDDI au: そのほかの技術情報 > Cookie」によると、2011年秋冬モデル以降の端末では、下図のようにCookieの保管場所による区別がなくなっています。

画面1　「au/KDDIの「KDDI au: そのほかの技術情報 > Cookie」にある情報

　同様に、Cookieのデフォルト有効期限についても、2011年秋冬モデル以降で変更されるようです。

　これらの発表から、筆者は、2011年秋冬モデル以降では、Cookieは常に端末に保存される仕様に変更されるのではないかと予想しています。そうなると、HTTPでセットされたCookieもHTTPSのページから読み出せることになるはずですが、そこまで明確には発表されていません。これは筆者の推測です。

　筆者の推測が当たっていても外れたとしても、現在のEZwebの仕様に合わせてアプリケーションを開発しておけば間違いありません。すなわち、HTTPとHTTPSの両方から参照する必要のあるCookieはHTTPSでセット・変更するということです。

　これはかなり厳しい制約になりますが、携帯電話ブラウザ向けにHTTPとHTTPS混在のサイトを開発する上では避けては通れない制約です。

ソフトバンクのゲートウェイ型SSLに潜んでいた問題

　実は少し前まで、ソフトバンクでも、HTTPとHTTPS混在のサイトでCookieの扱いが難しい状態でしたが、今年の6月30日午前3時にこの問題は解消されました。以下、この問題について説明します。

　図1は、一般的なSSLを示しています。ケータイブラウザとWebサーバの間には事業者のゲートウェイがありますが、ゲートウェイは単に通信を中継するだけで、通信内容を見たり改変したりすることはできません。

図1　一般的なSSL

　これに対してソフトバンクの旧来のSSLは、ケータイブラウザとWebサーバの間にsecure.softbank.ne.jpというゲートウェイが割り込む形になっていました（図2）。SSLの暗号化通信は、secure.softbank.ne.jpで受信する際に復号され、再度暗号化されて送信されます。この方式では、ゲートウェイ（secure.softbank.ne.jp）が通信内容を見たり、改変したりすることができてしまいます。

図2　ソフトバンクの旧来のSSL

　この形態は、通常、中間者攻撃（Man-in-the-Middle Attack）と呼ばれる攻撃手法と同じです。

　そこでSSLには、このような盗聴・改ざんができないような仕組みが用意されています。具体的には、画面2のようにブラウザが証明書のエラーを表示して、利用者が中間者攻撃に気付くことができる仕掛けです。ここでは、secure.softbank.ne.jpにはexample.jpの証明書がないため、以下のようなエラーになります。

画面2　証明書情報が一致しないときに表示されるエラー画面

　このようなエラーを防ぐ方法はいくつかあります。このうちソフトバンクの採用していた方法は、SSLのサイトにアクセするURLを書き換えるというものです。すなわち、https://example.jp/というURLは、https://secure.softbank.ne.jp/example.jp/という形になります。

　この場合、ブラウザ側が認識するドメインはsecure.softbank.ne.jpなので、証明書のエラーにはなりません。利用者はソフトバンクの運営するsecure.softbank.ne.jpを信頼してSSLのサイトを利用することになります。

HTTPとHTTPSとでドメインが違う!?

　しかし、この方法にはいくつか問題があります。

　サイト開発者たちがまず問題にしたのは、HTTPとHTTPSが混在するサイトで、ブラウザから見たドメインが異なることです。以下は、example.jpというサイトにHTTPとHTTPSでアクセスした場合のURLです。

　HTTPの際にはexample.jpドメイン、HTTPSの際にはsecure.softbank.ne.jpドメインとなるので、Cookieを共有することができません。この問題には有効な解決策がなく、secure.softbank.ne.jpの廃止によってようやく解決されました。

secure.softbank.ne.jpに潜んでいた真の重大な問題

　secure.softbank.ne.jpの廃止に際して、公式には「サイト開発の利便性向上などを目的とした」仕様変更とありますが、実はsecure.softbank.ne.jpには、もっと切実な問題がありました。secure.softbank.ne.jpを利用したWebサイトは、アプリケーションに脆弱性がなくてもなりすましを許してしまうという問題があったのです。

　詳しい内容は、「高木浩光＠自宅の日記 - SoftBankガラケーの致命的な脆弱性がようやく解消」、「徳丸浩の日記: ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る」をお読みいただくとして、ここでは概要を紹介します。

　ソフトバンクのケータイ端末は、かなり昔からJavaScriptが非公式に使えるようになっていました。画面3はソフトバンク910T（2006年10月発売）の設定画面ですが、「スクリプト設定」という項目があり、JavaScriptをサポートしていることが分かります。

画面3　ソフトバンク910Tの設定画面

　ケータイブラウザがJavaScriptに対応していれば、secure.softbank.ne.jp上に表示されたコンテンツを読み出すことができます。そこで筆者は図3のような検証用画面を作成しました。これを用い、iframe上に表示させたGmail（ケータイ版）の表示内容を、iframeの外側に配置したJavaScriptを用いて読み出せてしまうことを確認しました。

図3　罠サイトを想定した検証用画面

　この検証ページは、攻撃者の罠を想定して作られています。

　実際の攻撃シナリオを説明しましょう。罠サイトではGmailの表示は隠され、別の内容（例えば芸能人のゴシップ、マル秘のお得情報、その他の話題）が表示されます。うっかり罠のサイトを閲覧してしまうと、Gmail、あるいはその他のサイトがiframe上に呼び出され、罠サイトのJavaScriptにより、秘密情報が攻撃者の管理するサーバに送信されます。

　この攻撃により、メールアカウントやパスワードといった秘密情報の漏えいのほか、利用者のアカウントによるWebサイトの操作（買い物、オークション出品・応札、送金、投稿など）も可能になります。非常に影響の大きな脆弱性といえるでしょう。画面4と画面5に、検証結果と読み出したHTMLの拡大図を示します。

画面4　図3の検証用画面にアクセスした結果

画面5　画面4の拡大図。重要な情報が読み取られていることが分かる

　この問題はケータイWeb史上最大の脆弱性と思われますが、本年6月30日のsecure.softbank.ne.jpの停止により解決されたことになります。

スマートフォンアプリとケータイWebアプリの共通点

　ここで視点を変えて、スマートフォン対応のアプリケーションの脆弱性について少し説明しましょう。

　まず、スマートフォン向けのアプリケーションには2種類あります。

• スマートフォンのブラウザで動くWebアプリケーション
• スマートフォン向けのクライアントアプリケーション

　このうち、スマートフォン向けのWebアプリケーションは、一般の（PCなどの）Webアプリケーションと技術的には同等です。従って、スマートフォン「固有」の注意点はあまりありません。スマートフォンのブラウザではJavaScript、Cookieなどが使えますし、事業者のゲートウェイの存在を意識する必要もありません。ケータイIDも送信されません。

　これに対して、スマートフォンのクライアントアプリケーション（以下、スマートフォンアプリ）の方は注意が必要です。筆者は、ケータイWebアプリケーションとスマートフォンアプリには共通するセキュリティ上の注意点があると考えています。それを考える上では、以下の着眼点が重要と考えます。

• WebサーバとHTTPで通信するが、安全な開発方法が確立しているとはいえない
• ケータイIDを使うことができるを使うことができる
• 「PCから見えないはず」という思い込みによる油断がもたらす脆弱性があるによる油断がもたらす脆弱性がある

　このうち、ケータイIDの問題と「PCから見えないはず」という思い込みについて説明します。

iPadのメールアドレス流出、背後には不用意な「ケータイID」利用

　iPhoneやAndroid端末では、端末固有のID（ケータイID）を取得できます。Webアプリケーションからは利用できませんが、スマートフォンアプリからは、権限があれば取得できます。

　例えばAndroid端末の場合、getSimSerialNumber()やgetSubscriberId()、getDeviceId()というメソッドにより、端末あるいは契約者にひも付けられたIDが取得可能です。

　iPhoneやiPadにも、端末およびSIMにひも付けられたIDを取得する機能があります。以下は、iPhoneの固有IDを閲覧する画面です（注1）。これらの値をアプリケーションから取得することもできます。

画面6　iPhoneの固有ID閲覧画面

　そして、これらのIDを不用意に用いたために脆弱性が生じ、個人情報が流出した事件が発生しています。

　2010年6月に、米国AT&Tが運営するWebサイトから、11万4000人分のメールアドレスが漏えいするという事件が起きました。このWebサイトは、ケータイIDの一種ICC-ID（SIMのシリアル番号）のみでユーザー認証を行っており、パスワードなど他の秘密情報を認証時に要求していませんでした。このため、攻撃者はICC-IDを総当たり的に試行して、認証に成功した利用者のメールアドレスを取得できたということです。

　これは、連載第2回で説明した、グダグダSNSの「かんたんログイン」においてIPアドレスの制限がかかっていなかった状態に相当するものです。スマートフォンの場合は、Wi-Fiからのアクセスもあるので、原理的にIPアドレス制限はできません。

　しかし、次のような疑問を持つ方がいるかもしれません。Webアプリケーションの実装方法に問題があったとしても、攻撃者はどうやってその問題点に気付くのでしょうか。

実は外から、多彩な方法で「見えている」スマートフォン

　ケータイの場合でも「PCから見えないはず」は間違いで、実際にはHTMLなどを見る方法がありました（連載第1回参照）。しかしスマートフォンの場合は、「PCから見る」方法がずっと多彩になります。

　一例として、スマートフォンアプリの通信の様子をネットワークキャプチャする例を紹介しましょう。

　画面7は、あるTwitterアプリケーション（Android用）の通信の様子をWiresharkというソフトによりキャプチャしている様子です。筆者のアカウント（@ockeghem）で認証後、コンテンツをAPI経由で取得している様子を図示しています。

画面7　Wiresharkで通信の内容を把握できる

　ご覧のように、HTTPヘッダも含めたリクエスト全体が取得できています。

　また、SSLにより暗号化されたリクエストも違う手法で取得できます。SSLによる暗号化は、第三者による盗聴を防ぐためのものです。従って、利用者本人がネットワークの内容を取得する場合、SSLによる暗号化では防ぐことはできません。

　このように、ケータイWebの場合以上に、スマートフォンアプリの場合も「PCから見えないはず」という思い込みは大変危険です。ケータイIDによる認証も使うべきではありません。

　それでは、どうすればよいか。

　答えは簡単で、一般の（PC向けの）Webアプリケーションと同じ方法を使えばよいのです。例えば、認証後のセッション維持には疑似乱数によるセッションIDを使えばよいし、それはPHPなどの開発ツールがサポートするもので十分です。難しい仕組みを再発明する必要はまったくないのです。

ケータイWebアプリの今後を安全に保つには

　さて、連載の締めくくりとして、ケータイWebアプリケーションを取り巻く環境が今後どのように変化するかを考えてみましょう。

　第1回の終わりで説明したように、ケータイWebも2008年からWi-Fiに対応しています。ただしこれは、携帯電話と事業者ゲートウェイをVPN接続するという方法により、閉じたケータイネットワークを維持したままで行われました。

　今後、ケータイネットワークに影響を与えるかもしれないイベントが2つ計画されています。1つは、EZwebのゲートウェイの集約、もう1つは、NTTドコモのスマートフォンによるiモード認証・課金の提供です。

• EZwebゲートウェイの集約

　EZwebの技術サポートサイトEZfactoryには、以下のように「EZwebとPCサイトビューアのゲートウェイIPが統合される」と告知されています。

　従来、EZwebのブラウザはJavaScriptに対応しておらず、主要キャリア中でセキュリティ上の危険性が最も低い状態でした。しかしPCサイトビューアとIPアドレスが統合されることは、EZwebコンテンツを閲覧するブラウザの中に、JavaScriptに対応したものが含まれることを意味しています。

　歴史的に、ケータイWebとJavaScriptの相性はよくありません。これは、閉じた世界を前提として開発されたWebアプリケーションに対して、JavaScriptが攻撃手段を提供するからと考えられます。例えば、第2回に紹介したDNSリバインディング攻撃や、今回紹介したsecure.softbank.ne.jpに対する攻撃は、いずれも、従来JavaScriptが使えないことを想定していた環境で突然JavaScriptが使えるようになったために起こった問題と考えられます。

• スマートフォン向けのiモード認証・課金の提供

　NTTドコモは、5月16日の夏モデル発表の際に、「今冬にはiモード課金コンテンツをスマートフォンでも利用できるようにする」旨を発表しました。この発表も、ケータイWebが動作する環境の広がりを意味します。

　筆者は、スマートフォン上で動くiモードコンテンツは、次のように実現されると予想しています。まずiモードコンテンツは、スマートフォン上の標準ブラウザではなく、iモード専用のブラウザ上で表示されます。そして、iモード専用ブラウザはNTTドコモのゲートウェイとの間をVPN接続されます。これは、前述のケータイWi-Fiと同じ方式です。

　この方式によるリスクは何でしょうか。スマートフォン上のアプリケーションは、携帯電話に比べ、逆コンパイルなどによるリバースエンジニアリング（内部の解析）が容易になります。従って、スマートフォン用iモードブラウザを改造して、攻撃機能を追加することなどが現実味を帯びてきます。

　ケータイIDについてはどうでしょうか。現在ゲートウェイで付与しているiモードIDやキャリア公式サイトで使用されているUIDについては、技術的には、改ざんされずに付与することが可能です。一方、端末側で付与しているFOMA端末製造番号とFOMAカード製造番号は改ざんされる可能性があります。

　このようにブラウザが攻撃ツールに改造されるかもしれない、ケータイIDが改ざんされるかもしれないなどと聞かされると、びっくりするケータイ開発者がいるかもしれませんね。

　しかし、PCから閲覧されるWebアプリケーションでは、これらは当然の前提です。PC向けのサイトは常に攻撃ツールから狙われており、それで異常なことが起これば、アプリケーションの脆弱性として扱われます。

　すなわち、これまで何度も書いてきたように、ケータイWebであっても、PC向けサイトと同じ技術を使っていれば、ブラウザなどの進化を恐れる必要はありません。Webの一般的なルールに従ってアプリケーションを記述してそれで問題が起こるのであれば、ブラウザやインフラの脆弱性なのです。その例は、secure.softbank.ne.jpの事例で紹介したとおりです。

　今後、ケータイWebは緩やかに衰退すると予想されますが、それと入れ替わるようにして、スマートフォンアプリにおいて、ケータイIDの問題や「PCから見えないはず」という思い込みに起因した問題が必ず起こります。むしろ、AT&Tの事例で説明したように、すでに起き始めているといっていいでしょう。

　従って、安全なWebアプリケーションや安全なスマートフォンアプリを開発する上でも、安全なWebアプリケーションを書くための基本がとても重要になります。それを確認する上では、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」を参考にしていただければと思います。

　これまで4回にわたり、ケータイWebのセキュリティ問題について説明してきました。途中何度も間が空いてしまい申し訳ありません。今度は、別の分野でまたお目にかかれれば幸いです。