Webサービスのセキュリティ認証を評価する

ログイン関連の脆弱性に対処するための5つの方策

筆者がWebセキュリティ評価で遭遇した深刻なWeb認証の脆弱性と、その対処法を紹介する。

公開 2009年07月22日 07時45分

更新 2012年09月04日 17時56分

著者

Kevin Beaver

[TechTarget]

印刷する

　わたしはWebセキュリティを評価するという仕事を通じて、数多くの興味深い問題に遭遇する。その大半は小さなことだが、深刻な問題も少なくない。本稿では、わたしが目にした幾つかの深刻なWeb認証の脆弱性（ログイン関連の脆弱性など）を紹介するとともに、開発者や品質担当者、セキュリティ担当者がこれらの問題に対処する方法を示したい。

1. IEのヘルパーオブジェクト

　わたしが遭遇したWebベースの認証に関する脆弱性の中で特に深刻な問題の1つが、重要なバックエンドシステムへのアクセスを可能にするWebブラウザ「Internet Explorer」（以下、IE）のヘルパーオブジェクトに関連したものだ。

　このシステムのログインメカニズムは基本的に、ユーザーのWindowsログインステータスとIDを評価し、ユーザーが有効なアカウントでマシンにログインしていれば、それ以上の認証は行わずにアプリケーションへのアクセスを許可するというものだった。

　しかし驚くことに、Webプロキシを利用すれば、この“認証”プロセスを操作し、バックエンド環境に不正にアクセスできることが分かった。その方法は簡単で、HTTPリクエストを通じて送信されるWindowsユーザーIDフィールドを編集し、既存の有効なユーザーID（例えば「jsmith」）を挿入するだけだ。それ以降はWebプロキシを介在させることなく、ブラウザを閉じるまでシステムに自由にアクセスすることが可能になる。これには参った。

教訓：ユーザーが操作できるこのような認証ロジックは避けるべきだ。また、ユーザーが有効なアカウントを使ってローカルOSにログインしたからといって、彼らがWebアプリケーションにアクセスする権限があると判断してはならない。

2. 多要素認証システムの制御変数

　次の例は、わたしが多要素認証システムの評価を行ったときのことだ。これは、機密情報へのアクセスが可能なアプリケーションで使われていたシステムだ。ところが、この侵入防止用ロックアウトメカニズムで利用されていた制御変数は、ユーザーがWebプロキシやスクリプトによってリセットすることができたのだ。これでは多要素認証システムのメリット（特にロックアウト機能）は台無しだ。

教訓：ユーザーが修正できるようなログイン制御変数を使用しないこと。

3. 単純なユーザー名とパスワード

　わたしが遭遇したもう1つの興味深いWeb認証の脆弱性は、2～10までの数字だけで構成されるユーザー名、そしてすべて同じ数字で構成されるパスワード（55555など）を許容するというものだ。このため、自動スキャンツールを使えば、ユーザーアカウントの取得とパスワードのクラッキングを極めて短時間で行うことが可能だった。侵入防止メカニズムを使用していなかったことも災いした。

教訓：単に数を増やすだけでは推測できないような複雑なパスワードとユーザー名を強制すること。認証に10～15回失敗すればログインできないようなロックアウトメカニズムを採用するのも有効だ。

　パスワードの重要性は何年も前から強調されているにもかかわらず、複雑なパスワードを要求しないWebアプリケーションを今でも見掛ける。わたしは最近、1つの数字あるいは文字をパスワードとして使用するのを許可するアプリケーションを目にした。考えてみてほしい。複雑なパスワードを強制しなければ、ユーザーはどんなパスワードを選ぶだろうか。

4. デモ用アカウントのパスワード

　これと似たような問題としてしばしば遭遇するのは、デモ用アカウントやゲストアカウントに弱いパスワードが設定されている（あるいはパスワードがまったく設定されていない）という状況だ。こういったアカウントは、販売担当者、アカウント管理者、マーケティングスタッフなどが、アプリケーションのデモを行う際の使い勝手を良くするためにセットアップされることが多い。その場合のセキュリティは特に重視されていないが、こういった簡単なアクセスを可能にすれば、アクセス権限を手に入れたライバル企業や悪意を持った人間があなたの会社のネットワークに侵入し、望ましくないことをするという結果につながることは想像に難くない。

教訓：あらゆるユーザーに複雑なパスワードを要求する（アカウントの役割や目的にかかわらず、すべてのアカウントがパスフレーズを使用することが望ましい）。さらに、上述のような侵入防止用ロックアウト機能を有効にすること。この機能を導入すれば、ヘルプデスクの仕事が増えるかもしれないが、あらゆる人にWebシステムへの侵入を試みる自由を与えるよりはましだ。

5. Webシステムの脆弱性

　Webシステムの脆弱性が見過ごされていたり、軽視されていたりするケースも見受けられる。例えば、わたしがある会社の電子メールアカウントのセキュリティを評価していたとき、Outlook Web Accessのユーザーアカウントに弱いパスワードが設定されているのに気付いた。このため日程を2日延長して、詳しい検査を実施することにした。その結果、重要な社内文書（その多くは皮肉にも「社外秘」と記されていた）が保存されていたMicrosoft Exchange Serverのパブリックフォルダを詳細に調べてユーザーの電子メールアドレスを取り出し、1ダースほどのアカウントに設定されていた比較的弱いパスワードを割り出すことができた。

教訓：Webセキュリティの検査では、自社で開発したサイトやアプリケーションだけに目を向けがちだが、あらゆるWebベースのシステムのセキュリティを考慮に入れなければならない。

本稿筆者のケビン・ビーバー氏は、米アトランタにあるPrinciple Logicを経営する独立系情報セキュリティコンサルタント。講演や監査も手掛ける。この業界で20年以上の経験があり、コンプライアンスと情報リスク管理を中心とした情報セキュリティ評価を専門とする。「Hacking For Dummies」「Hacking Wireless Networks For Dummies」（いずれもWiley刊）など、情報セキュリティに関する7冊の著書および共著書がある。情報セキュリティについてのオーディオブック「Security on Wheels」の制作も手掛け、ブログではIT専門家向けにセキュリティ関連の知識を提供している。

印刷する