再考・ケータイWebのセキュリティ（1）：「PCでは見えないはず」に頼ることの危険性

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

2009年11月17日 00時00分 更新

無視できない“ケータイWeb”セキュリティ

　はじめまして。今回からこの連載を担当することになりました徳丸浩といいます。この連載では、携帯電話向けWebアプリケーション（以後「ケータイWeb」と表記します）のセキュリティについて解説します。ここでいう携帯電話とは、iモードやEZweb、Yahoo!ケータイなど、日本で従来、広く利用されているサービスを指します。一方、いわゆるフルブラウザやiPhone、Android端末などは含みません。

　ケータイWebは、一般のPCなどから利用されるWebと比較して、使用技術の90％くらいは共通です。しかし、残りの10％のために、ケータイWebならではのセキュリティ上の注意点があります。この連載では、そのケータイWebならではの部分にフォーカスして解説していきます。

　本連載の想定読者は、PHPやJavaなどでWebアプリケーションを開発しているプログラマやプロジェクトマネージャなど、「開発側」の方々、およびケータイWebを開発会社に発注する側の担当者など、現場寄りの方々です。できるだけ具体的な説明を心掛けますので、実務に役立てばと希望します。

ケータイWebはどこが違うのか

　さきほど、ケータイWebは、PCなどのWebと「10％程度違う」と説明しましたが、その10％とは具体的にはどこでしょうか。セキュリティに関係の深い部分のみ取り出すと、以下のようになります。

• 携帯電話事業者のゲートウェイの存在
• Cookieに対応していないブラウザ
• JavaScript非対応
• HTMLソースの表示機能がない
• 契約者固有IDの存在
• 手軽さを求める要求
• そのほか

　以下、順に説明しましょう。

携帯電話事業者のゲートウェイの存在

　図1に、ケータイで用いられるネットワークの構成を示しました。

図1　ケータイWebネットワークの構成

　この図のように、ケータイWebでは端末が直接インターネットに接続されているのではなく、いったん携帯電話会社のゲートウェイを通って、そこでさまざまな処理がされてからインターネットにつながるように構成されています。ゲートウェイの機能や構成の詳細仕様は公開されていませんが、一種のプロキシとして動作し、認証情報を付加するなどの処理が行われていると推測されます。

　携帯電話会社のゲートウェイのIPアドレス一覧表が公表されていますので、Webサーバ側でリモートIPアドレスを調べることにより、確かにケータイからの接続であることを確認することが可能になります。いい換えれば、IPアドレスを調べることで、PCなどからの接続を拒否することができます。PCからの接続拒否は必須ではありませんが、拒否した場合、近年問題になっているボットやツールなどからの攻撃に対して効果的に防御することが可能となります。

Cookieに対応していないブラウザの存在

　NTTドコモのケータイブラウザは、最近までCookieに対応していませんでした。詳しくいえば2009年の夏モデル以降、「iモードブラウザ2.0」としてCookie対応がなされましたが、それ以前の機種ではCookieには対応していないのです。NTTドコモのシェアから考えて、インターネットに接続されているケータイのざっと半分がCookie非対応のブラウザを搭載していることになります。

　Cookieは通常、セッション管理のためにセッションIDと呼ばれる識別子を保持するために用いられますが、Cookie非対応のケータイ端末を考慮して、ケータイWebの場合は、セッションIDをURLに埋め込むことが一般に行われています。

　しかしこの方法はセキュリティ上の問題を発生させる可能性があるため、注意が必要です。詳しくは、連載第3回のセッション管理のところで説明します。

ケータイブラウザはJavaScriptにも対応する

　NTTドコモは、前述のiモードブラウザ2.0の目玉機能として、2009年5月にJavaScript機能を搭載した携帯電話を発売しました。しかし、セキュリティ上の問題があったようで、リリース後すぐにJavaScript機能はいったん停止されました。

　しかし、2009年10月23日にNTTドコモからアナウンスがあり、10月末から段階的にJavaScript機能が再開されつつあります。従って、今後はケータイでJavaScriptが動作しても大丈夫なようにWebアプリケーションを開発しておかなければなりません。具体的にはクロスサイトスクリプティング（XSS）対策を怠らないことですが、詳しくは連載第4回（最終回）で説明します。

HTMLソースの表示機能がないことへの過信

　ケータイブラウザにはHTMLのソースを表示する機能がありません。このため、PCからはできる攻撃の一部がケータイブラウザからはできない場合があります。例えば、ケータイブラウザではhiddenフィールドの値を参照することができないので、その値を書き換えて攻撃することもできません。同様に、ラジオボタンやSELECT要素の値を参照したり、書き換えたりすることもできません。

　ケータイブラウザではHTMLソースを表示できないことを理由として、ケータイWebは、PC用の一般サイトよりも安全性が高いと思っている方がいますが、これは誤解であり、少なくとも過信はしない方がいいようです。その理由は、本来見えないはずのHTMLソースが閲覧できる場合があるからです。それは以下のような場合です。

PCからの閲覧を制限していない場合

　ケータイブラウザからHTMLソースを閲覧できなくても、そのWebサイトをPCから閲覧できれば、HTMLソースの表示は容易です。前述した携帯電話事業者のゲートウェイIPアドレスにより閲覧制限をかけている場合は閲覧できませんが、この方法は運用が面倒なため、UserAgentというHTTPリクエストヘッダ中の機種情報を用いて、閲覧制限しているサイトもあります。この場合は、PCからUserAgentを書き換えて閲覧することにより、当該のサイトを表示させることができ、HTMLソースも閲覧が可能です。

検索エンジンのキャッシュを用いる方法

　最近はケータイでもGoogleなどの検索エンジンの利用が広がってきました。携帯電話事業者の公式メニューに掲載されていないサイトにとって、SEO（Search Engine Optimization）は重要であるため、Googleなどの検索サイトが検索用インデックスを作成できるように、IPアドレス制限を解除することが行われます。

　しかし、検索エンジンには「キャッシュ」と呼ばれる機能があるため、この機能を利用してHTMLソースが閲覧できる可能性があります。以下に、その例をお見せしましょう。

　実験用にWebサイトを作成して、PCからの閲覧を拒否する設定をしました。この状態でPCから閲覧すると、図2のように、「Forbidden」というエラーメッセージが表示されます。

図2

　次に、このサイトをGoogleに登録した後、PCから適当なキーワードで検索すると、図3の検索結果が表示されます。

図3

　ここで、図3のキャッシュというリンクをたどると、図4のようにPCからサイトの内容を閲覧できます。

図4

　さらに、ブラウザの機能によりリスト1のようなHTMLソース（抜粋）が得られます。

<form action="/cgi-bin/epx0530.cgi" method="POST">
   名前:<input type="text" name="name"><br>
   メールアドレス:<input type="text" name="email"><br>
 <input type="submit" value="実行">
 <input type="hidden" name="usertype" value="normal">
 <!-- <input type="hidden" name="usertype" value="admin"> -->
</form>

　ご覧のように、ACTIONのURLやhiddenフィールド、コメントアウトした内容などの情報が閲覧できています。特に、権限を示すらしいusertypeというhiddenフィールドがあることや、コメントアウトされた内容を手掛かりとして、上位の権限を得られる可能性があることが分かります。

クロスサイトスクリプティング脆弱性の悪用

　このほか、クロスサイトスクリプティング（XSS）脆弱性が当該サイトに存在すると、HTMLソースの一部あるいは全部が閲覧される可能性があります。特に、ケータイのJavaScriptが利用できるようになると、サイトの1個所でもXSS脆弱性があれば、任意のページのHTMLを閲覧できるようになります。

　これまで見てきたように、ケータイWebのHTMLは外部から参照できないと思われていますが、実はさまざまな手法により閲覧できる場合があります。そして、いったんHTMLソースからhiddenフィールドの内容などの情報が得られると、ケータイを用いて当該サイトへの攻撃ができるのです。

契約者固有IDの存在

　ケータイブラウザからのHTTPリクエストには、契約者固有IDという一意のID番号が付与されています。

　契約者固有IDは、もともとはケータイコンテンツの課金認証などに用いられてきたもので、かつては、公式メニューに掲載されたコンテンツ（公式コンテンツ）にのみ送信されていました 。しかし、近年では、公式サイトでないサイト（いわゆる勝手サイト）でも送信される契約者固有IDが提供されており、認証などに利用されています。

　図5に契約者固有IDの一種である、iモードIDの取得方法を示します。図のように、URLにguid=ONを指定することにより、リクエストヘッダにiモードIDと呼ばれる7桁の識別子が付与されます。

図5　リクエストヘッダに含まれるiモードID

　契約者固有IDは、1つの端末からすべてのサイトに対して同一の値が送出されるため、プライバシー上の問題とセキュリティ上の問題があります。特に、契約者固有IDのみを利用する認証（かんたんログイン）は、近年広く利用されているものの、実装方法や運用方法によってはセキュリティ上の問題が生じます。これに関しては、次回詳しく説明します。

ケータイWebへの「手軽さを求める要求」

　これはケータイブラウザの機能とは直接関係はありませんが、ケータイ向けサイトには、通常のサイトよりも手軽に利用したいというユーザーからの「圧力」が強い傾向にあります。例えば、PC向けのサイトであれば英数字や記号を交えた8桁以上のパスワードを要求することは普通のことですが、ケータイWebでは、パスワード自体の省略や、数字4桁の「暗証番号」で代替する場合が珍しくありません。これは、ケータイWebに求められる「手軽さ」に対して、セキュリティ面で妥協した結果といえます。

ケータイWebの神話～通常のWebに比べて安全か危険か

　ここまで見てきた特性をセキュリティ上の安全性という観点からまとめてみましょう(表1)。

　表をご覧いただければ分かるように、いままで漠然と考えられてきた「ケータイだから大丈夫」という感覚は、実は非常に心許ないものなのです。

　ここまで見てきたように、ケータイWebの安全神話は、以下の2点を根拠として支えられてきたものです。

• ケータイWebが閉鎖的なサービスであった
• ケータイブラウザの機能が低かった

　そして、これらが将来にわたって、いまのままであるとはいえないのです。今回の終わりにあたり、今後の展望について少し説明してみましょう。

今後もケータイは閉鎖的なネットワークを維持するのか

　本連載では、iPhoneやAndroid端末は対象としないと書きましたが、これら海外で設計された携帯電話は、Wi-Fi（無線LAN）対応により、インターネットに直接接続する機能があります。このため、日本のケータイのような閉鎖的なネットワークを前提にしていませんし、PC向けサイトと同レベルのセキュリティ対策が必要です。

　一方、日本型のケータイでも、Wi-Fiに対応した機種が登場しつつあります。NTTドコモは昨年からWi-Fi対応機種（N906iL onefoneおよびN-06A）を販売しており、KDDI（au）は2009年の夏モデル、biblioにてWi-Fiに対応しました。これらはいずれも、Wi-Fi接続時にも、従来型のケータイインターネット（iモード、EZweb）が利用できることが特徴です。

　これを実現するために、国産のWi-Fiケータイは、端末から直接インターネットに接続するのではなく、いったん事業者のゲートウェイを通るように構成されています。すなわち、Wi-Fi利用であっても、閉鎖的なネットワークは維持されています。このように、当面は閉鎖的なネットワークは維持されると思われますが、将来については分かりません。この問題については第4回（最終回）で再度触れる予定です。

iモードブラウザ2.0～従来型ケータイの進化

　ケータイWebの機能強化については、iモードブラウザ2.0が挙げられます。これは、先にも触れたように、NTTドコモの2009年の夏モデル以降に搭載されるブラウザを指します。

　iモードブラウザ2.0では、先に説明したJavaScriptのほかに、CookieとRefererに対応したことにより、機能的にはほぼフルのPCブラウザと同等の仕様になりました。

　これによるセキュリティ上の影響としては、やはりJavaScriptが大きいと考えられます。現状ではJavaScriptは停止された状態ですが、2009年10月末から段階的に再開されるとのアナウンスがありましたので、サイト側でもその対応を急ぐ必要があります。

　といっても、特別なことをしなければならないわけではありません。PC用の通常のサイトと同じように、クロスサイトスクリプティング（XSS）対策をしておけばよいのです。JavaScriptが搭載される前から、XSS対策が不要というわけではなかったのですが、現実には、前述のようなケータイWebの「安全神話」により、十分にXSS対策していないサイトが多数あります。しかし今後はそのような「手抜き」に対する危険度が増加するため、一般のPCサイトと同じレベルでXSS対策を実施するべきでしょう。

　第1回では、ケータイWebのセキュリティを解説するための準備として、ケータイWebの特性を説明しました。日本のケータイWebは、事業者のゲートウェイに守られた閉鎖的なネットワークを持つという特徴があり、その特徴に依存したサイトの作り方が広く行われています。しかし、サイトの作り方によっては大きな危険性があることと、将来ネットワークやケータイブラウザの仕様が変化した場合に、新たな危険が生まれることを説明しました。NTTドコモが2009年の夏モデルで発表したiモードブラウザ2.0はその一例であり、サイト作成者側でも、現状と将来のリスクに備えたサイト開発が要求されます。

　次回は、ケータイWebアプリケーションの認証、特に「かんたんログイン」の問題について説明します。