今週のSecurity Check(第197回)

 以前の「今週のSecurity Check」の記事で,見落としがちなWebアプリケーションのぜい弱性の例として,ログイン画面におけるエラー・メッセージから認証の安全性が低下する例を示した。今回は,ログイン画面そのものがぜい弱な例を取り上げてみたい。

 まず,写真1のログイン画面にどのようなぜい弱性が内在しているかお考えいただきたい。Webサイトの会員の立場から,ご自身の認証コードが破られる可能性は高いと思われるだろうか。

写真1 Webアプリケーションのログイン画面の例
写真1 Webアプリケーションのログイン画面の例

 では,これに以下の条件が加わった場合はどうだろう。
・会員番号は10桁の数字
・認証コードは9桁の数字

 この条件が加わると,ある特定の会員にとってログイン画面の認証の安全性は大幅に低下する。攻撃者の視点で考えてみよう。

 攻撃者は,誰かの有効な会員番号と認証コードのセットを「できるだけ沢山、できるだけ容易に入手すること」を第一に考える。そこで,こうしたログイン画面に狙いを付け,会員番号を探り当てようとする。ログインできる会員番号を調べるために,認証コードを利用され易いものに固定したうえで,会員番号を順次変更してログインを試みる。不正ログインの手段ですぐに思いつくのは総当りや辞書攻撃による「特定の会員番号の認証コードの割り出し」だが,攻撃者は「安易な認証コードを設定している会員番号の割り出し」に発想を転換する。

 さしあたり,認証コードは「123456789」や「111111111」などでよいだろう。後は会員番号を次々に変えて実際にログインを試行する。安直な認証コードであることは確かだが,実際にこうした認証コードを設定しているケースはそれほど珍しくない。攻撃者はおそらく短時間のうちにログインできる有効な会員番号を複数入手できるだろう。会員番号の割り当て規則や認証コードの条件などは入会手続きの際や会員になることで知ることができる。つまり,攻撃者の視点に気付けば比較的容易に問題点が見えてくる。

 この問題への対策の一つは,会員に安直な認証コード利用の危険性を周知すること。同時に、認証コードに一定の複雑さを要求する方法が挙げられる。例えば設定できる認証コードに,一定の桁数と英数字記号の利用の両方を要求するなどシステム的な制限を設ける方法である。

 次に,ログインした会員の識別にセッション管理メカニズムを利用するWebアプリケーションのぜい弱性を考えよう。最近でこそ、アプリケーション・サーバーが備えるメカニズムを使うサイトが増え,容易に推測できるセッションIDを使うケースはあまり見られなくなったが、図1(セッションID:user_ctl)のように容易に推測できるセッションIDを使っていると,セッションを容易にハイジャックされる危険性がある。

図1 推測されやすいセッションIDの例
図1 推測されやすいセッションIDの例

では、このセッションIDと画面の遷移制御を組み合わせて利用する場合のセッション・ハイジャックの容易さはどうだろうか。セッションIDと表示中の画面を関連付けて管理すれば,表示している画面からは直接遷移できない画面へのリクエストが発生した場合,Webアプリケーションが異常なリクエストと判断してエラー処理を実行。会員をログアウトさせるとともに当該のセッションIDを無効化することができる。このWebサイトでセッション・ハイジャックを成功させるには,セッションIDとその会員が表示している画面を割り出さなければならない。

 それでもこの場合でも,前の例と同様に攻撃者の視点で考えると,セッション・ハイジャックを容易に成功させることはできる。例えば特定の画面(会員情報参照画面など一度表示できれば必要なものが入手できる画面)に的を絞り,あらかじめ推測してプールしたセッションIDを使って攻撃を繰り返す(図2)。

図2 攻撃者は特定の画面に狙いを絞り,セッション・ハイジャックを狙う
図2 攻撃者は特定の画面に狙いを絞り,セッション・ハイジャックを狙う
[画像のクリックで拡大表示]

 攻撃者は当該画面を表示するユーザーが現れるのを待てばいい。その日のセッションIDの値が取りうる範囲は攻撃者自身が会員としてログインすることでかなり絞り込むことができる。絞り込んだ値の範囲で繰り返し試行することで,総当たりするよりもはるかに容易に他人のセッションをハイジャックされてしまう恐れがある。

 セッション・ハイジャックへの対策の一つは,推測が困難でユニークなセッションIDを毎回生成して利用すること,Webサイトの特質に応じた適切な期間で当該セッションIDをWebアプリケーション側で無効化することなどが挙げられる。そのためには,セッション管理メカニズムを利用する場合には自前で実装するのではなく,アプリケーション・サーバーなどが持つ仕組みを使う方がいいだろう。

 前回の記事でも説明したが,見落としがちなぜい弱性をきちんと見付けるためには,攻撃者の視点でWebサイトをチェックすることが重要なポイントになる。



中山 明
日本アイ・ビー・エム
ISS事業部ISSプロフェッショナル サービス
シニア セキュリティ コンサルタント

 「今週のSecurity Check」は,セキュリティに関する技術コラムです。セキュリティ・ベンダーである「日本アイ・ビーエム ISS事業部」(IBM ISS:旧インターネット セキュリティ システムズ)のスタッフの方々を執筆陣に迎え,同社のセキュリティ・オペレーション・センター(SOC)で観測した攻撃の傾向や,セキュリティ・コンサルタントが現場で得たエッセンスなどを織り交ぜながら,セキュリティに関する技術や最新動向などを分かりやすく解説していただきます。
(編集部より)
■IBM ISSが提供するネットワーク・セキュリティの最新情報はこちら