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

「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サイトのセッション管理について説明します。