検索
連載

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

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

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

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

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

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

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

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

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

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

【関連記事】
iPad購入者のアドレス流出、原因はWebアプリケーションの脆弱性か(ITmedia News)
http://www.itmedia.co.jp/news/articles/1006/11/news034.html

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

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


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

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

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

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

画面7 Wiresharkで通信の内容を把握できる
画面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が統合される」と告知されています。

EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」および「ネットワーク環境」の見直しを行ないます。

これによる主な変更点は以下のとおりです。

<主な変更点>

 ・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。

 ・EZブラウザ、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モード」を普及の「武器」に──ドコモ夏モデル発表(ITmedia News)
http://www.itmedia.co.jp/news/articles/1105/16/news107.html

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

筆者紹介

京セラコミュニケーションシステム株式会社
プラットフォーム事業本部 技術顧問

HASHコンサルティング株式会社
代表取締役

徳丸 浩(とくまる ひろし)

 1985年京セラ株式会社入社、1995年京セラコミュニケーションシステム株式会社(KCCS)転籍、2008年HASHコンサルティング株式会社設立。現在、京セラコミュニケーションシステム株式会社 プラットフォーム事業本部 技術顧問を兼務。システム開発の経験を経て、2004年からWebセキュリティのサービスを開始。特にケータイWebサイトのセキュリティについては早くから着眼し、多くの講演、寄稿を手がける。

HASHコンサルティングを立ち上げてからは、企業のWebサイト開発のコンサルティングなどにも幅広く携わる。

最近、特に注目されているWAFについては、多くの実証実験を手がけ、自身のブログでもWAFについての見解を述べている。

▼徳丸浩の日記
http://www.tokumaru.org/d/

▼KCCSセキュリティサイト
http://www.kccs.co.jp/security/index.html


前のページへ |       

Copyright © ITmedia, Inc. All Rights Reserved.

Security & Trust 記事ランキング

  1. セキュリティ専門家も「何かがおかしいけれど、攻撃とは言い切れない」と判断に迷う現象が急増 EGセキュアソリューションズ
  2. 英国政府機関が取締役にサイバーリスクを「明確に伝える」ヒントを紹介
  3. 人命を盾にする医療機関へのランサムウェア攻撃、身代金の平均支払額や損失額は? 主な手口と有効な対策とは? Microsoftがレポート
  4. AIチャットを全社活用している竹中工務店は生成AIの「ブレーキにはならない」インシデント対策を何からどう進めたのか
  5. MicrosoftがAD認証情報を盗むサイバー攻撃「Kerberoasting」を警告 検知/防御方法は?
  6. 「このままゼロトラストへ進んでいいの?」と迷う企業やこれから入門する企業も必見、ゼロトラストの本質、始め方/進め方が分かる無料の電子書籍
  7. SBOMの本質を大阪大学 猪俣教授が語る――「うちのソフトは大丈夫なんです」とユーザーにどう証明する?
  8. Google、「パスキー」のアップデートを発表 新たに導入された「パスワードマネジャーPIN」とは?
  9. 「Amazonプライム感謝祭」に関するフィッシング攻撃を確認、注意すべき7つのポイントとは チェック・ポイント・ソフトウェア・テクノロジーズ
  10. 「PC操作が不能になる手口」が増加中 IPAが推奨される対処法を紹介
ページトップに戻る