再考・ケータイWebのセキュリティ（2）：間違いだらけの「かんたんログイン」実装法

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

2011年03月01日 00時00分 更新

情報漏えい事故にもつながった「かんたんログイン」の問題

　第1回「『PCでは見えないはず』に頼ることの危険性」を公開してから今回まで、しばらく間が空いてしまいましたが、その間、携帯電話向けWebサイトをめぐってはいろいろな動きがありました。

　ざっと振り返ってみても、2010年夏モデルからソフトバンクの携帯電話でもJavaScriptが正式に対応となりましたし、2011年6月末からソフトバンクのゲートウェイ方式のSSLが廃止されることが決まりました。これらの動きはいずれも、セキュリティ上の影響を及ぼすものです。

　2010年10月には、宅配便大手の携帯電話向けサイトで「かんたんログイン」の脆弱性が原因となって個人情報1件が流出する事故が発生しました。

　今回は、そのかんたんログインの問題点について説明します。

「契約者固有ID」を用いるかんたんログイン

　かんたんログインとは、携帯電話の「契約者固有ID」を用いたログイン手法です。

　第1回で説明したように、携帯電話のブラウザのリクエストヘッダには契約者固有IDと呼ばれるIDを付けることができます。契約者固有IDは、携帯電話事業者によって詳細は異なりますが、すべての携帯電話事業者が対応しています。

図1　リクエストヘッダに含まれるiモードID（契約者固有ID）

　図1は、NTTドコモの携帯電話がサポートしている契約者固有IDである「iモードID」がサーバに送信される様子です。この情報は、ユーザーがそれと意識することなく送信されます。携帯電話のかんたんログインとは、契約者固有IDのみを用いて認証を行い、ログイン機能を実現することです。

　かんたんログインは、ベーシック認証のようにIDとパスワードを管理する必要もなく、Cookieのように対応する端末を考慮する手間がいらず、ワンタイムパスワードなどに比べ追加コストもほぼ不要なことから、携帯電話向けWebアプリケーション（ケータイWeb）で広く利用されています。しかし、安易な実装によってセキュリティ上の問題を引き起こすことも事実です。

　そこで今回は、A社が提供する「グダグダSNS」という架空のSNSサイトを舞台にかんたんログインの問題点を説明し、最後に実施可能な対策を紹介します。この例を読んでいただければ、脆弱性の指摘を受けるたびに場当たり的に対処することの危険性がお分かりいただけると思います。

ネットを参考に「かんたんログイン」対応したものの……

　A社は「グダグダSNS」サイトを携帯電話に対応させることを決め、かんたんログインもサポートすることにしました。しかしA社はそれまでかんたんログインを実装した経験がありませんでした。

　そこでインターネットの情報などを参考に、「契約社固有IDを取得して、会員データベースと突き合わせて、登録されている場合はログイン成功と見なす」という以下のスクリプトを作成し、運用を開始しました（注意：この方法には脆弱性があります）。

$guid = '';
$carrier = '';
if ($_SERVER['HTTP_X_DCMGUID']) {           // NTTドコモの場合
$carrier = 'docomo';
$guid = $_SERVER['HTTP_X_DCMGUID'];
} else if ($_SERVER['HTTP_X_UP_SUBNO']) {   // auの場合
$carrier = 'au';
$guid = $_SERVER['HTTP_X_UP_SUBNO'];
} else if ($_SERVER['HTTP_X_JPHONE_UID']) { // ソフトバンクの場合
$carrier = 'softbank';
$guid = $_SERVER['HTTP_X_JPHONE_UID'];
} else if ($_SERVER['HTTP_X_EM_UID']) {     // イー・モバイルの場合
$carrier = 'emnet';
$guid = $_SERVER['HTTP_X_EM_UID'];
} else {
// エラー（携帯電話からのアクセスではありません）
} 

「PCからなりすましログインできるんですが？」

　「グダグダSNS」のかんたんログインは順調に稼働しているように見えました。ところがある日、「別人になりすましてログインできてしまう」という指摘を受けたのです。

　攻撃手法の一例を紹介しましょう。PC上でFirefoxの「Modify Headers」というアドインソフトを用いて、「X-DCMGUIDヘッダ」（キャリアのゲートウェイからiモードIDを取得できる）を送信するよう設定を変更すると、ドコモユーザーになりすましできるというものです（画面1）。

画面1　Modify Headersを用いれば、X-DCMGUIDヘッダを送信するように設定を変更できる

　このような手法を用いてHTTPリクエストヘッダを指定すれば、実際にはPCからのアクセスであるにもかかわらず、サーバは携帯電話からのリクエストと判断して処理します。つまり、誰かが任意の利用者になりすまし、個人情報を盗み見るといったことが可能になるのです。

　PCを用いたHTTPリクエストヘッダ改変に対抗する手法として、携帯電話のゲートウェイのIPアドレスを確認し、携帯電話以外からのアクセスには応答を拒否するという方法があります。

　A社は当初、携帯電話事業者のIPアドレスの確認方法を知りませんでした。そこでまたもやインターネットで検索すると、親切にも設定済みの.htaccessファイルが紹介されていることが分かりました。A社は早速それをApacheに導入して、IPアドレス制限を掛けることにしました（注意：この方法は間違っています）。

.htaccess
Order Deny,Allow
Deny from all
# docomo
Allow from 210.153.84.0/24 210.136.161.0/24 210.153.86.0/24
...

　.htaccess設定後にPCからもう一度接続してみると、画面2のように403エラーが表示されます。これでもう大丈夫だと判断しました。

画面2　403エラーが表示されるので一安心、と思ったが……

　これで一件落着と思ったのですが……そうはいきません。

「携帯電話で接続できない!?」

　「グダグダSNS」がIPアドレス制限を掛けてからしばらくすると、今度は利用者から「携帯電話で接続できない」というクレームがくるようになりました。ログを調べてみると、こうした利用者は.htaccessの制限外のIPアドレスから接続していたことが分かりました。

　実は、携帯電話ゲートウェイのIPアドレスは、時々追加されたり、削除されたりします。このため、新規追加されたゲートウェイを介したアクセスがエラーになっていたのです。

　携帯電話ゲートウェイのIPアドレスの最新情報は、各携帯電話事業者のホームページで公開されています。

　これらの情報は不定期に更新されます。IPアドレスの追加や削除にタイムリーに対応するには、上記のサイトを地道に見張るしかありません。携帯電話向け情報サイトの中には、IPアドレスの変更情報を配信しているところもあるので、参考にするのもよいでしょう。ただし、IPアドレスの情報は、直接携帯電話事業者のサイトを参照して得るようにしてください。

　A社も、携帯電話事業者の情報を基に、すべての携帯電話利用者が接続できるようにIPアドレス制限を変更しました。

イー・モバイル端末をモデムに使ってなりすまし

　IPアドレス制限を更新して一安心と思った「グダグダSNS」ですが、実はそれでもまだ、なりすまし攻撃の余地がありました。

　PCにイー・モバイルの端末を接続してダイヤルアップで接続し、EMnetというサービス用のプロキシサーバ経由でアクセスする場合を考えてください。サービス側から見ればこのアクセスは、イー・モバイル（EMnet）ゲートウェイからのリクエストとなります（図2）。すなわち、PCからの接続でもIPアドレス制限を回避してアクセスできてしまうのです。

図2　イー・モバイルの端末をモデムとして使い、EMnet経由でアクセスすると、PCからでも接続できてしまう

　この状態では、PCからX-EM-UID（イー・モバイルの契約者固有ID）は改変できませんが、それ以外の項目、例えばX-DCMGUIDなどの追加はできます。リスト1の契約者固有ID取得ロジックの場合、PCなどで追加した他キャリアの契約者固有IDを拾うことになり、なりすましが可能になっていました。

　A社はこの事態を受け、イー・モバイル向けの対応をやめることにしました。具体的には、Webサーバの.htaccessからイー・モバイルのIPアドレスを削除してしまいました（注意：これは間違った対応の例であり、実際にはイー・モバイルのIPアドレスを削除する必要はありません）。

非公式JavaScript機能を使った攻撃

　しかし、イー・モバイルからのアクセスを禁止するだけでは、根本的な問題は解決していません。

　かんたんログインに対する攻撃手法の1つとして、携帯電話ブラウザによるJavaScriptを使った攻撃があります。

　ここでは、ソフトバンク端末の非公式JavaScript機能を使った攻撃方法を紹介します。ソフトバンクは2010年夏モデルの一部から公式にJavaScriptに対応していますが、実はその前から、一部端末で非公式にJavaScriptに対応していました。現在では、非公式JavaScript機能は利用者がオフにするようにソフトバンクが案内していますが、使用が禁止されているわけではなく、機能も停止されていません。

　さて、攻撃者がグダグダSNSサイト上でJavaScriptを実行するには、何らかの脆弱性を悪用する必要があります。もしケータイWebに以下の脆弱性があれば、攻撃者が用意したJavaScriptを実行できてしまいます。

• クロスサイトスクリプティング脆弱性
• DNSリバインディング脆弱性

　このうち、DNSリバインディング脆弱性については後述します。ここでは、攻撃者の用意したJavaScriptが実行できるという前提で説明を続けます。

　JavaScriptを悪用した攻撃の基本的なアイデアは、XMLHttpRequestオブジェクトのsetRequestHeaderメソッドを使って、契約者固有IDを設定するという方法です。以下は、XMLHttpRequestとsetRequestHeaderにより、各携帯電話事業者の契約者固有IDを追加したリクエストを送信するスクリプトです。

function goAjax() {
var requester = new XMLHttpRequest();
requester.open("GET", "/dispguid.php", true);
requester.onreadystatechange = function() {
if (requester.readyState == 4) {
onloaded(requester);
}
};
requester.setRequestHeader("X-DCMGUID", "fake1");
requester.setRequestHeader("X-UP-SUBNO", "fake2");
requester.setRequestHeader("X-JPHONE-UID", "fake3");
requester.setRequestHeader("X-EM-UID", "fake4");
requester.send(null);
}

　画面3は、ソフトバンクの非公式JavaScript対応機である821Nによる実行結果です。ご覧のように、ソフトバンク以外の契約者固有IDは、スクリプトで設定したとおりに偽装されています。

画面3　非公式JavaScript対応機である821Nでは、契約者固有IDがリスト3のとおりに偽装される

　もし、リスト1のスクリプトを用いて契約者固有IDを取得している場合、このJavaScriptを悪用してアクセスすると、契約者固有IDは「ドコモのfake1というiモードID」と判定されます。なりすましの成立です。実際の攻撃では、前もって契約者固有ID収集用にフェイクのケータイWebを運営し、そこで収集した情報をなりすましに悪用する手法が考えられます。

　JavaScriptを使った契約者固有IDのなりすまし手法については、残念ながら、携帯電話事業者が対策に関する公式な情報を出しておらず、保証された対策手法はありません。しかし、次の方法を用いて契約者固有IDを取得した場合、なりすまし手法はまだ見つかっていないようです。

1. HTTPSによる通信を避ける（HTTPSの場合ゲートウェイのチェックが入らなくなるため）
2. ゲートウェイのIPアドレスを元に携帯電話事業者を判定する
3. 2で判定した携帯電話事業者を基に、該当するHTTPリクエストを取得する

「DNSリバインディング」による攻撃

　今度は、契約者固有IDのなりすまし（変更）をしないでかんたんログインを攻撃する、「DNSリバインディング（DNS Rebinding）」と呼ばれる手法を紹介します。

　DNSリバインディングは受動的攻撃の一種です。なりすましのターゲット（対象者）の携帯電話ブラウザ上で攻撃用スクリプトが動作することで攻撃が起こります。図3を用いて、DNSリバインディング攻撃の概要を説明します。

図3　DNSリバインディングを用いた攻撃シナリオ

　図3のexample.jpが攻撃対象サーバ、trap.example.comは攻撃者が管理している「罠」のサーバです。攻撃者は罠サイト上に、JavaScriptを仕込んだHTMLを用意し、example.jp利用者が閲覧するのを待ちます。以下に攻撃シナリオを示します。

　この問題は、筆者が2009年11月24日にアドバイザリとして公開したものですが、まだ十分に認知されていないようです。この問題が当てはまるケータイWebサイトはかなりの数に上ると推測されます。

　対策としては以下の2つの方法があります。

• HTTPリクエスト中のHostヘッダが正規のホスト名となっていることを確認する
• 名前ベースのバーチャルホストを設定する（より簡便な方法）

　ここでは、バーチャルホストの設定による対策方法を紹介します。

　大切なポイントは、先頭のバーチャルホスト設定はダミーとすることです。ホスト名がマッチしないリクエストについては、先頭のバーチャルホストのルールがデフォルトとして利用されるからです。正規のバーチャルホストは2番目に置きます。

NameVirtualHost *:80
# ダミーのバーチャルホスト
<VirtualHost *:80>
# ダミーなので正規のホスト名以外であれば何でもよい
ServerName example.com
DocumentRoot /var/www/dummy
ErrorDocument 404 /index.html
</VirtualHost>
# 正規のバーチャルホスト
<VirtualHost *:80>
ServerName example.jp
DocumentRoot /var/www/html
</VirtualHost>

　しかし、この方法にはまだ抜けがあります。ソフトバンクの非公式JavaScript対応端末では、JavaScriptによりHostヘッダが変更でき、悪用が可能だからです。このため、これらの端末には、別途何らかの対応が必要になります。前述のように、これら端末の利用者に対しては、ソフトバンクがJavaScriptを利用者の責任で停止するように案内していますが、徹底されているとは思えません。

　1つの方法として、「ソフトバンクの公式JavaScript対応前の端末についてはかんたんログインの対応をしない」という対処が考えられます。公式JavaScript対応前の端末は、User-Agentで区別できます。

SoftBank/1.0/821N/NJ001/SNXXXXXXXXXXXXXXX Browser/NetFront/3.4 Profile/MIDP-2.0 Configuration/CLDC-1.1

SoftBank/2.0/944SH/SHJ001/SNXXXXXXXXXXXXXXX Browser/NetFront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1

　ソフトバンク端末のUser-Agentの詳細については、ソフトバンクが発行している「ウェブコンテンツ開発ガイド［ブラウザ機能拡張（500k 対応）編］」（無料会員登録が必要）を参照してください。

安全なログイン実装方法はやはり「Cookie」

　本稿執筆時点で、かんたんログインを安全に実装するための「必要条件」には以下があります。

• 携帯電話事業者のゲートウェイからのアクセスのみを受け付ける（IPアドレスチェック）
• リモートIPアドレスを基にキャリア判定を行う（User-AgentなどHTTPリクエストヘッダで判定してはいけない）
• 契約者固有IDとしてはiモードID、EZ番号、ユーザーID（ソフトバンク）のみを用いる
• HTTPSではかんたんログインを受け付けない
• Hostヘッダのチェックまたは名前ベースのバーチャルホストを設定する
• ソフトバンクの非公式JavaScript対応端末へ何らかの対処を行う

　しかし、これらで「十分条件」になるかは、携帯電話事業者が保証してくれない限り分かりません。いまのところ、そのような安全な方法が提示される見通しはないため、かんたんログインの安全性は非常に危うい状況といえます。

　しかも、今後のスマートフォンの普及を考えたとき、スマートフォンからも利用できる安全なログイン手法の普及が望ましいでしょう。

　それは、特殊なものではありません。PC向けサイトで広く利用されている「ログイン状態を保持」あるいは「自動ログイン」と呼ばれるものです。画面4は、皆さんもおなじみのGoogleの「ログイン状態を保存する」やmixiの「次回から自動的にログイン」チェックボックスです。これらにチェックを入れると、ブラウザを再起動してもログイン状態が維持されます。

画面4　PC向けサービスで広く採用されている「ログイン状態の保持」機能の例

　これらの自動ログイン機能は、Cookieにより実現できます。NTTドコモの携帯電話が2009年夏モデル以降でCookieに対応したのに合わせ、今後は、ぜひCookieを認証やセッション管理に活用することをお勧めします。「グダグダSNS」のような安易な実装例が減ることに期待したいところです。

　Cookieを用いた自動ログイン機能については、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方　脆弱性が生まれる原理と対策の実践」（ソフトバンククリエイティブ、3月1日発売予定）にて詳しく説明しています。この本の中では、携帯電話のセキュリティや自動ログインの話題だけでなく、Webアプリケーションのセキュリティ全般について解説しています。この連載と併せてお読みいただくと安全なケータイWebの構築に役立つと思います。

　次回は携帯電話向けWebサイトのセッション管理について説明します。