Webサービスのセキュリティ認証を評価する
ログイン関連の脆弱性に対処するための5つの方策
筆者がWebセキュリティ評価で遭遇した深刻なWeb認証の脆弱性と、その対処法を紹介する。
わたしは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専門家向けにセキュリティ関連の知識を提供している。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品レビュー
「電子帳簿保存法対応」実践術：タイムスタンプ付与などの要件の手軽な実現方法 -
事例
「大企業のデジタル化」成功事例集【コクヨ、九州電力、ヨネックスなど21社】 -
製品資料
“顧客管理の課題”を簡単に解決する方法とは？ -
製品資料
契約管理の“あるある課題”をノーコード開発で解決するためのポイント -
製品資料
揺らぐ境界防御 いま企業が特に警戒すべき「3つのセキュリティ課題」とは？
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
2
自宅のWi-Fiが「遅い」「途切れる」本当の原因は？ Dellが推奨する鉄則
-
3
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
4
継続利用は4割どまり M365 Copilotが「効く業務」と期待外れの境界
-
5
画面をティッシュで拭くのはNG Dellが推奨するPCの正しいお手入れ方法
-
6
メインフレームは死なず AI活用で20年来の高収益をたたき出す基幹システムの底力
-
7
「法人PCの導入」に関するアンケート
-
8
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
9
「GitHub Copilot」3000人に配布も基本機能しか使われない 保険大手が得た教訓
-
10
業務引き継ぎで困ったこと 大企業200人調査で判明した課題の第1位は
ホワイトペーパーランキング PR
-
1
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
2
AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
-
3
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
4
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
5
「脱Excel」か「Excel快適化」か？ 現場にやさしい業務改善の進め方
-
6
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
7
「結局、一部の人しか使わない」 AI活用が業務に定着しない根本的な理由
-
8
AIエージェントで成果は出る？ 調査結果に見る費用対効果の実態
-
9
PostgreSQLの「機能」「性能」「運用」「拡張性」に関する悩みの解消法
-
10
ゼロトラストにおける「IDaaSの課題」と補完すべき重要機能とは？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー