Webアプリのセキュリティを検討する「Webアプリケーションセキュリティフォーラム(WASForum)」が5月22日、認証と認可に関するイベントを開催した。その中で携帯電話の「かんたんログイン」のセキュリティに関して講演が行われた。

WASFは、もともとPCの一般的なインターネットのセキュリティを対象にしていたが、昨今のスマートフォンの流行などで携帯電話からも通常のインターネットが頻繁に利用されるようになったことから、今回のような考察が行われたという。

かんたんログインに関して講演をしたのは、HASHコンサルティングの徳丸浩氏と、産業技術総合研究所(産総研)の高木浩光氏。

パンドラの箱を開いたキャリア

携帯電話のWebサイト(携帯Web)で一般的に利用される「かんたんログイン」は、iモード(NTTドコモ)やEZweb(au)、Yahoo!ケータイ(ソフトバンクモバイル)で利用されているログイン手法。各携帯電話に固有の端末固有IDや契約者固有ID(以下、固有ID)を使い、ログイン認証に利用するというものだ。

一般的には、各サイトに用意されたユーザーIDとパスワードを固有IDと関連付け、設定したあとはユーザーIDとパスワードを入力することなく、「かんたんログイン」などのボタンから1クリックでログインできるようになる。多くの携帯サイトが採用する仕組みである。

かんたんログインの例。国内向けのサイトだけでなく、海外の日本語サイトでも利用されている

携帯Webは、携帯網から各キャリアのゲートウェイで言語変換や認証、SSL処理などの処理を行い、インターネット経由で各コンテンツ提供事業者(CP)のサーバに転送されるという仕組みだ。このゲートウェイは、「(動作を見ると)普通に考えればこれはプロキシ」(徳丸氏)だ。

携帯向けのWebアプリは、キャリアのゲートウェイを経由してインターネットにつながっている

かんたんログインの仕組み。ドコモやau、ソフトバンクで、送信される固有IDは異なる

さて、かんたんログインでは、携帯電話から送信されるHTTPのリクエストヘッダにIDが含まれている。インターネットでは本来書き換えられるHTTPヘッダだが、そこにIDを含めてもかんたんログインが成り立つには条件がある、と徳丸氏。

  1. 携帯網がIPアドレス帯域でアクセス制限する閉じたネットワークであること
  2. 携帯電話自体の機能が低く、HTTPヘッダを書き換える機能がないこと

この2点がかんたんログインの成立条件となる。すべてのサイトに送出される固有IDは秘密情報ではないので誰にでも知られてしまい、送信される固有IDが書き換えられるとなりすましができるからだ。

では、実際に携帯電話でのHTTPヘッダ書き換えはできないのだろうか。徳丸氏によれば、JavaScriptのXMLHttpRequestオブジェクトにおけるsetRequestHeaderメソッドを使えばリクエストヘッダの書き換えができる。ドコモは昨年5月に発売した端末から、iモードブラウザを拡張してJavaScriptに対応し、この書き換えが可能になっていた。

しかしドコモは発売後すぐにJavaScriptの利用を停止、10月に機能を再開した。徳丸氏によれば、再開前は利用できたsetRequestHeaderメッソドが無効化されていたそうだ。悪意のある攻撃者による何らかの能動的攻撃ができたため、こうした処置が行われたと徳丸氏はみている。

これによって、ドコモ端末では固有IDの書き換えができなくなったが、まだ安心とはいえない。その方法がDNSリバインディングだ。これは、IPアドレスを短時間で書き換え、アクセスしていたドメインのIPアドレスとは異なるサーバーにアクセスさせる攻撃方法だ。この手法を使うことで、徳丸氏は「かんたんログインが突破できた」という。

徳丸氏は昨年11月22日に調査を行い、実際に攻撃できることを確認し、同24日にはアドバイザリを公開している

この攻撃に対しては、「本来はブラウザやゲートウェイで対策すべきもの」(徳丸氏)だが、携帯電話ブラウザはゲートウェイ(プロキシ)経由のため名前解決をしていないから対策できず、ゲートウェイも結局IPアドレスを切り替えなければならない。そのため根本的な対策はできないとのことで、携帯キャリア側では対策が困難。逆にWebサイト側は、setRequestHeaderが無効化されたことで、Hostフィールドをチェックすれば効果的な対策になるという。

DNSで長時間キャッシュをしていたとしても、それを悪用した攻撃が行えるので、根本的な対策はできない。なお、キャリアのゲートウェイについて「ドコモの場合、最低1分間はIPアドレスを保持している」(徳丸氏)

徳丸氏は、「パンドラの箱を開けてしまった」と話す。携帯Webの高機能化のためにJavaScriptをサポートしたことが、攻撃を可能にするからだ。

ここまではドコモの問題だが、ソフトバンクも一部モデルですでにJavaScriptに対応しており、同様の危険性をはらんでいるという。

2006年の804SS/ 910T/ 910SHでは、ブラウザのNetFront 3.3がJavaScriptに対応し、IFRAME(804SSをのぞく)、DOMに対応して攻撃に使われる可能性が出てきていた。さらに2008年の922SHに搭載されたNetFront 3.4ではAjaxに対応、XMLHttpRequest、setRequestHeaderもサポートたことで、「2006年からパンドラの箱は開いていた」(同)。

ドコモではできなくなったsetRequestHeaderによるヘッダの書き換えについて、ソフトバンク端末ではUser-AgentやX-JPHONE-UIDはできなかったが、Hostヘッダの書き換えを許可していたという。

PC用ブラウザなどと比較して、ソフトバンク端末ではHost書き換えを許可している

これができたのはシャープ製の932SHで、ブラウザ設定にある「Ajax規制」をオンにすると書き換えができたそうだ。この設定はデフォルトではオフだが、設定を変えれば書き換えができてしまい、Hostヘッダをチェックする防御方法が使えなくなってしまう。

これに対して徳丸氏はソフトバンク側と協議。前述のDNSキャッシュの保持時間を延ばすことで攻撃を緩和できるため、ソフトバンクはこの保持時間を5分間に延長したという(ゲートウェイ自体が切り替わると5分経たずに変化するという)。ただし、これでは前述のとおり根本的な対策にならない。

その後、ソフトバンク側から連絡がなくなったため、徳丸氏は「シャープ製端末以外はAjaxが有効ではない」「シャープ製端末もデフォルトはオフ」ということから、今回これを公表することにしたという。

さらに徳丸氏は、ソフトバンク製端末60台を用意して調査した。その結果、NECの820N/ 821N、カシオ製830CA、サムスン製940SCの4機種で、Ajaxがデフォルトでオンだったという。また、Ajaxを利用する際にNECとカシオはRefererが送出されていたが、両社ともその後の端末では同機能を無効化している。シャープ製は、922SHから最新機種までAjax利用可能だが、デフォルトはオフになっていた。

徳丸氏がテストした結果の一例。940PはXMLHttpRequest(画面では「XHR」)が使えないが(左)、940SCではXHRが「Ready」(利用可能)になっていた

このように、ソフトバンク端末はメーカーの独自仕様でAjaxが利用可能になっているようで、徳丸氏は「統制がとれていない印象がある」と指摘。さらにメーカー間で情報が共有されておらず、iモードでの教訓が生かされていないと強調する。NetFrontは国内携帯の8割以上に採用されていることから、開発するACCESS側には「それに見合うだけの責任がある」と批判する。

調査した端末でAjax対応端末かどうかをまとめた表

ソフトバンクのAjax対応端末には「あまり有効な対策はない」と徳丸氏。Ajaxを規制する設定があるなら利用を禁止し、それ以外の機種ではJavaScriptを無効化することが対策となる。

なお、ソフトバンクでは5月27日に対応策を発表した。107機種に対して「JavaScriptを無効にする」ようユーザーに設定変更を促している。ソフトバンクでは「悪意あるサイトを閲覧した場合に、情報の詐取が生じる可能性がある」としているが、「かんたんログインのなりすましができるということを言い換えたのではないか」(徳丸氏)。

また、対応策が発表された中には、徳丸氏が検証して問題がなかった機種も含まれているが、「切り分けが難しいので、まとめて無効化したのではないか」と推測している。ちなみに、ソフトバンクによれば今夏のモデルでは、これらの対策が行われたブラウザが搭載されているそうだ。

モバイルサイト解析ツールの「myRTモバイル」が携帯電話の利用実態について調査した結果から徳丸氏は、これらのAjax対応機種のシェアは大きくないほか、利用者の多いシャープ製端末ではデフォルト無効であることから、影響を受けるユーザーは少ないとみている。自分の携帯電話でこの問題があるかどうかは、徳丸氏が作成したチェックサイト(携帯のみ)にアクセスすれば分かる。

本来、PC用ブラウザではできないHostヘッダの書き換えを許しているソフトバンク端末は、Ajax対応で根本的な危険性をはらんでいる。そのため徳丸氏は、Hostヘッダの書き換えを禁止するか、「いっそのこと、かんたんログインを無効にする」(同)という対策を提唱する。

さて、ドコモでは昨年10月の改修でかんたんログインのなりすましができなくなり、ソフトバンクでは端末の設定次第でなりすましができないという状況だが、問題は残っている。

ドコモとソフトバンクに関しては、2種類の「トリック」(同)で固有IDを改変して送信できるからだ。ひとつめが、End-to-EndのSSLを利用すること。本来、書き換えられた固有IDは、キャリアがサーバーで正常なIDに書き戻すのだが、SSLは端末とCP側のサーバを暗号化して接続するため、当然キャリアのゲートウェイで書き換えはできない。

もう1つは、ヘッダ内のハイフン(-)をアンダースコア(_)に書き換えて送信することだ。リクエストヘッダ内のハイフンは、CGIがアンダースコアに書き換えるため、それを逆手に取った手法だ。これもキャリアのサーバーは書き換えが行われない。

こうした攻撃に対しては、SSLでのかんたんログインを禁止する、キャリア判定をUser-AgentではなくIPアドレスで行う、という対策がある。

徳丸氏は、「JavaScriptによる攻略方法が分かってきた」と指摘する。かんたんログインを実施するに当たっては、さまざまな対策が必須だが、それで完璧なセキュリティを確保できるかは分からない。

「それでもまだ、かんたんログインを続けますか?」と徳丸氏は問いかける。