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

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

[徳丸浩，京セラコミュニケーションシステム株式会社]

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

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

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

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

事業者	IPアドレスを公開しているページ
NTTドコモ	http://www.nttdocomo.co.jp/service/imode/make/content/ip/index.html
KDDI	http://www.au.kddi.com/ezfactory/tec/spec/ezsava_ip.html
ソフトバンク	https://creation.mb.softbank.jp/web/web_ip.html
イー・モバイル	http://developer.emnet.ne.jp/ipaddress.html
表1　携帯電話ゲートウェイの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が実行できるという前提で説明を続けます。

【関連記事】
クロスサイトスクリプティング対策の基本
http://www.atmarkit.co.jp/fsecurity/special/30xss/xss01.html
星野君のWebアプリほのぼの改造計画 連載インデックス
http://www.atmarkit.co.jp/fsecurity/index/index_hoshino.html

　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　XMLHttpRequestとsetRequestHeaderにより、各携帯電話事業者の契約者固有IDを追加したリクエストを送信するスクリプト

　画面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リクエストを取得する