徳丸浩の日記

_携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性

このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。

5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以来2ヶ月以上が経つものの、未だにJavaScript機能は利用できない状態のままだ。

実は、NTTドコモ社が慌てふためいてJavaScript機能を急遽停止した頃から、私の頭の中には一つの仮説があったのだが、JavaScript機能が再開されてから確認しようと思ってそのままにしていた。しかし、中々JavaScript機能が再開されないことと、早期にサイト開発者に注意を呼びかけて予防的な対応をしてもらった方がよいと考えたことから、ここにその仮説を公開する。

その仮説とは、タイトルに記した通り、携帯電話のJavaScriptを悪用して「かんたんログイン」に対してなりすましが可能かどうかというものだが、攻撃が成立するための条件をまとめると以下のようになる。

1. 携帯電話のJavaScriptでXMLHttpRequestオブジェクトが利用できる
2. XMLHttpRequestにてsetRequestHeaderメソッドが利用できる
3. setRequestHeaderメソッドにてUserAgentなどのリクエストヘッダが書き換えできる

iモード2.0の仕様書によると、上記の(1)と(2)を満足している。(3)については何も書いていないが、特にできないとも書いていないので、iモード2.0で上記が可能かもしれない。JavaScript機能が停止されていることから、現時点では確認する手段がない。

以下、具体的に説明する。

iモードの場合

iモードの「かんたんログイン」の場合、iモードIDか、FOMA端末製造番号あるいはFOMAカード製造番号(UIM)を使う。iモードIDは、拡張リクエストヘッダ「X-DCMGUID」に、FOMA端末製造番号およびFOMAカード製造番号はUserAgentに付与される。

したがって、UserAgentあるいはX-DCMGUIDをsetRequestHeaderメソッドにて書き換えれば、任意ユーザになりすましが可能になる。これが可能になる条件としては、攻撃対象となるWebサイトにクロスサイトスクリプティング(XSS)脆弱性がある必要がある。他のサイトからでは、XMLHttpRequestのSame Origin Policyの制限のため送信できない*1。

すなわち、iモードの「かんたんログイン」を突破するのに必要な条件は以下のようになる。

• setRequestHeaderにてUserAgentあるいはX-DCMGUIDを書き換え可能
• 攻撃対象サイトにXSS脆弱性がある

前者に関しては、現在iモード2.0のJavaScript機能が停止されているので確認できない。X-DCMGUIDに関しては、おそらくドコモのゲートウェイで付与していると思われるので、ゲートウェイ側で削除するかもしれない。SSL通信の場合は、HTTPリクエストの内容をゲートウェイにて追加・変更・削除ができないが、元々X-DCMGUIDはSSLで受け取れないので、アプリケーションがSSLでもX-DCMGUIDを受け付けるか否かは、サイト側の実装に依存する。setRequestHeaderによるUserAgentの書き換えは、Firefoxでは可能なので、iモード2.0でも可能かもしれない。この場合は、後述のように、他事業者（au、ソフトバンク等）のユーザへのなりすましも可能になる場合がある。

後者に関しては、京セラコミュニケーションシステムが発行している「2009年版 Webアプリケーション脆弱性傾向」によると、携帯電話向け44サイトを含む177サイトを検査した結果、67%のサイトにXSS脆弱性がある。残念ながら携帯向けサイトだけの比率は公表されていないが、おそらく携帯電話向けサイトでも多くの割合でXSS脆弱性が検出されていると思われる。

au(KDDI)ユーザへのなりすまし

iモード2.0の端末を使って、auのユーザになりすましができる可能性がある。その条件は以下のようなものだ。

• 携帯事業者(auであること)の判定をリクエストヘッダ(UserAgentまたはX-UP-SUBNO)のみで行っている
• setRequestHeaderにてリクエストヘッダX-UP-SUBNOが追加できる
• 事業者判定をUserAgentで行っているサイトの場合は、setRequestHeaderにてUserAgentが書き換え可能
• 攻撃対象サイトにXSS脆弱性がある

ここで、一番目の条件について説明する。携帯事業者の判定方法には、一般に、

1. IPアドレスを使用する方法
2. UserAgentを使う方法
3. 両者を併用する方法

の三種がある。かんたんログインの実現には、PCからのなりすまし防止のため、IPアドレスの帯域チェックは不可欠だが、IPアドレスのチェックを事業者の判定まではせず、単に「携帯電話からのリクエスト」であることのみを確認する場合があるのだ。

IPアドレス制限を実装する方法としては、

1. ファイアウォールで制限する
2. Webサーバの機能で制限する（Apacheの場合はhttpd.confや.htaccessに記述）
3. アプリケーションで判定して制限する

の三通りがある。この中で、PC（携帯電話でない端末）からの攻撃を確実に防ぐという点では(i)がもっとも優れており、以下(ii)、(iii)の順になる。(iii)の場合だと、Webサーバ（Apache等）やアプリケーションサーバ（Tomcat、PHP等）に対する攻撃は止められないからだ。一方、(iii)を使用している場合は、IPアドレス帯域から事業者を判定することは容易だ。

以前紹介した書籍「PHP×携帯サイト 実践アプリケーション集」の場合は、まずUserAgentから事業者を判定しておいて、IPアドレスチェックの際に、当該の事業者のIP帯域に含まれているかを確認しているので、上記分類でいえば(c)および(iii)の組み合わせに相当する。一方、最近公開された実際に動いてすぐ使える「PHPによるかんたんログインサンプル」を作ってみました*2では、IPアドレスの制限は.htaccessで行うように指示しており、IPアドレスによる事業者のチェックはしていないので、同じく(b)および(ii)の組み合わせに相当する。

話を戻すと、方法(b)を用いた場合、携帯電話によるなりすまし行為が可能になった場合、若干脆弱になる。つまり、携帯電話JavaScriptのsetRequestHeaderメソッドにより、他事業者へのなりすましの可能性がある。すなわち、ドコモの携帯電話からの攻撃なので、IPアドレス帯域は携帯事業者のものである。UserAgentの書き換えが行われているので、アプリケーションはau携帯からのリクエストと誤認する。そこで、JavaScriptによるリクエストヘッダX-UP-SUBNO（EZ番号）追加により、別ユーザになりすましができるというシナリオである。

ソフトバンクの携帯電話ユーザへのなりすまし

ソフトバンク・ユーザに対するなりすましも、auの場合とおおむね同じだ。ソフトバンクの場合、個体識別番号が二種類ある。端末シリアル番号（UserAgentに付与）とユーザID（リクエストヘッダX-JPHONE-UID）である。そこで、なりすまし可能となる条件は以下の通りだ。

• 携帯事業者(ソフトバンクであること)の判定をリクエストヘッダ(UserAgentなど)のみで行っている
• setRequestHeaderにてUserAgentが書き換え可能
• setRequestHeaderにてX-JPHONE-UIDが書き換え可能（ユーザIDで認証している場合）
• 攻撃対象サイトにXSS脆弱性がある

NTTドコモへの要望

携帯JavaScriptによる、かんたんログインへのなりすまし攻撃の可能性について検討した。前述のように、現在iモード2.0端末のJavaScript機能は停止されており、上記条件を確認することはできない。おそらく、NTTドコモ社および端末メーカー、ブラウザメーカーは上記のような懸念も含めて対策をしておられる最中なのだろうと想像する。

本稿の検討により、携帯電話のJavaScriptでは、setRequestHeaderメソッドに一定の制限を設ける必要があることがわかる。

• UserAgentを書き換えできないようにする
• X-DCMGUID、X-UP-SUBNO、X-JPHONE-UIDなど、他事業者のものを含め、個体識別番号の指定に用いられるリクエストヘッダの指定もできないようにする

とくに、UserAgentの書き換え防止は重要である。さらに安全を期するためには、setRequestHeaderには大幅な制限を設けるのがよく、安全な仕様の例としては、追加・書き換え可能なリクエストヘッダをホワイトリストとして指定することなどが考えられる。

Webアプリ開発者側の対策

ここまで説明したように、かんたんログインに対するJavaScriptによるなりすましでは、いずれのパターンでもXSS脆弱性を悪用している。従って、XSS対策を行うことが根本的な対策になる。携帯電話向けだからと言って手を抜かないことが重要だ

また、保険的対策として、以下を推奨する。

• かんたんログイン以外の認証手段を用意しておく
• 重要な処理の前でパスワードなどによる再認証を求める
• 携帯電話事業者の判定にIPアドレスを利用する

さらにいえば、究極の根本対策として「かんたんログインを使用しない」ことも検討いただきたい。

まとめ

携帯電話のJavaScriptとXSS脆弱性の組み合わせにより、かんたんログインに対するなりすましの可能性について報告した。

通常のXSS脆弱性に対する攻撃が、正規ユーザを媒介とした受動的攻撃であるのに対して、かんたんログインのなりすましは能動的な攻撃となる*3。それだけ、被害の規模も大きくなることが想定される。

かんたんログインに対する脅威はJavaScriptばかりではない。hideden氏の8月1日付けの日記「SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ」で示されたような、携帯電話をモデムとして使用して事業者のゲートウェイ経由でのアクセスが可能となる場合にも、同様のなりすましの懸念がある。参照先ではソフトバンクモバイル内でのなりすましのみ指摘されているが、本稿で示したUserAgentの書き換えを併用することにより、他事業者（ドコモ、auなど）ユーザへのなりすましも懸念される。こちらの方法は、攻撃自体はPCからできるので、いっそう深刻な問題と言えるかもしれない。

そして、おそらくこの種の脅威は今後も形を変えて現れるだろう。その理由は、かんたんログインという手法が、もともと暗号学等の理論的な根拠に裏付けられておらず、携帯電話網という閉じた世界でのみ通用する手法であるからだ。今後、携帯電話そのものの高機能化や、携帯電話網への多様な端末の投入により、その前提が覆る可能性は十分あるし、その兆候は既に現れてる。

とすれば、少なくとも「いつでもかんたんログインを捨てられる」状態にしておくことが、ユーザも、Webサイト運営者自身をも守る最低限の取り組みであると、私は考える。

最後に

若干の宣伝をさせてください。筆者の経営するHASHコンサルティング株式会社では、Webアプリケーションの安全性に関するコンサルティングや脆弱性検査サービスなどを提供しています。携帯電話向けサイトの脆弱性対策については10年ほどの経験があります(前職での経験を含みます)。ご相談はこちらからお気軽に。

HASHコンサルティングは非常に小さな会社ですので、与信などの点で心配される向きもあろうかと思います。その場合は、私が技術顧問をしている 京セラコミュニケーションシステム株式会社にご相談いただければと思います。問い合わせフォームから「技術顧問の徳丸に相談したい」と書き添えていただければ確実かと思います。

様々な形で、貴社のWebサイトの安全にお役に立つことができれば幸いです。

2009/10/26追記

ようやく10月末からiモードブラウザ2.0のJavaScript機能が再公開されると発表がありました。これに合わせて、KCCSにて11月12日（木曜）、11月19日（木曜）、12月10日（木曜）の3回にわたり、ケータイWebセキュリティのセミナーを実施することになりましたので、興味のある方は、こちらのリンクから内容確認の上お申し込みください。