連載
» 2011年03月01日 00時00分 UPDATE

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

[徳丸浩,京セラコミュニケーションシステム株式会社]
前のページへ 1|2|3       

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

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

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

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

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

【1】罠サイトを閲覧すると、JavaScriptがダウンロードされる

【2】罠を閲覧したタイミングで、ローカルに保存されたDNSの内容を書き換え、trap.example.comを検索すると、192.0.2.251ではなく、example.jpのIPアドレス(192.0.2.2)を指すようにする

【3】利用者ブラウザ上の罠が実行され、trap.example.comを閲覧する。実際にはIPアドレスが書き換えられた後なので、example.jp(192.0.2.2)を閲覧し、かんたんログインにより認証される

【4】ブラウザ上の罠が個人情報を取得して、罠サーバ(192.0.2.251)に送信する

 この問題は、筆者が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>
リスト4 バーチャルホストの設定による対策

 しかし、この方法にはまだ抜けがあります。ソフトバンクの非公式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
JavaScript公式対応前端末のUser-Aegnetの例
SoftBank/2.0/944SH/SHJ001/SNXXXXXXXXXXXXXXX Browser/NetFront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1
JavaScript公式対応端末のUser-Agentの例

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

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

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

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

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

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

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

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

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

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

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

筆者紹介

京セラコミュニケーションシステム株式会社
プラットフォーム事業本部 技術顧問

HASHコンサルティング株式会社
代表取締役

徳丸 浩(とくまる ひろし)

 1985年京セラ株式会社入社、1995年京セラコミュニケーションシステム株式会社(KCCS)転籍、2008年HASHコンサルティング株式会社設立。現在、京セラコミュニケーションシステム株式会社 プラットフォーム事業本部 技術顧問を兼務。システム開発の経験を経て、2004年からWebセキュリティのサービスを開始。特にケータイWebサイトのセキュリティについては早くから着眼し、多くの講演、寄稿を手がける。

HASHコンサルティングを立ち上げてからは、企業のWebサイト開発のコンサルティングなどにも幅広く携わる。

最近、特に注目されているWAFについては、多くの実証実験を手がけ、自身のブログでもWAFについての見解を述べている。

▼徳丸浩の日記
http://www.tokumaru.org/d/

▼KCCSセキュリティサイト
http://www.kccs.co.jp/security/index.html



前のページへ 1|2|3       

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。