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

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のセキュリティ問題について説明してきました。途中何度も間が空いてしまい申し訳ありません。今度は、別の分野でまたお目にかかれれば幸いです。