ECサイト運営者向けの、知っておきたいWEBアプリの脆弱性とその対策 ■第5回（最終回）■

■ 設計と実装は大丈夫か？（続）と現状把握、及び対応策の重要性

特集特集

2005年3月1日（火） 20時30分

■ 設計と実装は大丈夫か？（続）と現状把握、及び対応策の重要性

　あっと言う間に最終回を迎えてしまった。やっておくべきリストの最後の2つについて簡単に解説し、その後、現状把握の重要性、及び把握した結果をどのように活かしていくかがWebアプリケーションの強化における重要なポイントであるということを解説したい。

■重要と思われる情報（クレジットカード番号や個人情報等）の閲覧や変更に再認証を設けているか？

　電子商取引サイトや登録制のWebサイトにはほとんどと言って良い確率で、「登録情報の変更」という機能が提供されている。提供側、ユーザ側、双方にとって煩雑な申請を必要とせずに情報を最新に保つことが出来るため、重宝されている機能と言えるだろう。
　ただし、自分の住所やメールアドレスの変更のみならず、クレジットカード番号の変更機能を提供している場合は一層の注意が必要だ。

　セッション管理の脆弱性を悪用された場合、他人へ成りすまして様々な情報を奪うことが出来てしまう。可能性として：

１．XSS（クロスサイトスクリプティング）によって認証用のcookieが漏洩してしまい、それを悪用して他人に成りすます。重要情報にアクセスする際の認証が存在しないが為にクレジットカード番号まで盗まれてしまうという最悪の状況が考えられる。オートログイン機能を提供している場合、再認証は必ず設置すべきだ。

２．画面遷移の整合性（ロジック部分）を悪用し、他の画面から登録情報変更ページへとアクセスする。予め登録情報変更ページへの遷移の仕方を分析し、不正な文字列を挿入（または付加）したURLを作成し、そのページへ直接アクセスを試みる場合がある。

　登録情報変更ページへアクセスする直前にユーザIDとパスワードを再度確認することにより、たとえcookieが盗まれたり、画面遷移に問題があったとしても最悪のケースは免れることが出来るだろう。同様に、パスワードの変更等の機能の前に最認証を設けることも有効な対策となる。
　その際、認証が通った後に、もう一つこのページ用に特別なセッションIDを別に用意するのも一つの方法だ。ただ、アプリケーションやアプリケーションサーバによっては2つのセッションIDを同時に使用する出来ないものもあるので、注意が必要だ。

■ユーザのブラウザにセキュリティ関連の設定変更を強要していないか？

　各方面の啓蒙活動でも話題になっていたが、基本的にはユーザがブラウザの設定を変更しなければならないサイト作りをしないことを推奨する。サイト上でユーザへ「このサイトの使用について」等の解説ページを設けても、PCの扱いに慣れたユーザでない限り、サポートへ電話をするだろうし、電話が頻発するようであればサポートチームの強化を余儀なくされる。高効率を目指して開発、提供しているはずのWebサイトで、コストのかかる人的サポートを強化したり余分な設備投資を強いられる程愚かなことはなく、実に本末転倒だ。効率的に処理を行わせるためにも、ユーザにブラウザの設定、例えばインターネットエクスプローラーであれば「ツール」→「インターネットオプション」を操作させるようなサイト作りをするべきではない。

【執筆】三井物産セキュアディレクション株式会社　目崎匠
　　　 http://www.mbsd.jp/

この記事には続きがあります。
全文はScan Security Management本誌をご覧ください。
http://www.ns-research.jp/cgi-bin/ct/p.cgi?ssm01_ssmd

《ScanNetSecurity》