【連載】
セキュアなWebサイトを運営するための
Webアプリケーションに潜むセキュリティホール

第14回 Webアプリケーションの脆弱性を総括する

中村隆之
三井物産セキュアディレクション
2005/3/4

※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください。

---

セッション系の脆弱性

　セッション系の脆弱性には、「Session Hijack」「Session Replay」「Session Fixation」がある。これらの脆弱性は基本的にセッション管理の不備が原因で発生する。セッション管理の不備とは、以下のような項目に問題があるということである。

• セッションを維持する方法
• セッションIDの生成アルゴリズム
• セッションIDの発行タイミング
• セッションIDの有効期間

　セッション管理は基本的に「認証状態を維持する方法」であるため、この部分に脆弱性があると個人情報が漏えいする場合が多い。

●脆弱性が存在する可能性がある個所

　基本的にセッション管理の仕組み自体が対象となる。

Session Hijack

　セッションIDの生成方法に問題がある場合に、推測や総当たりによって有効なセッションIDを見つけられてしまう。

Session Replay

　セッションIDの有効期間が長過ぎたり有効期間が設定されてなかったりすると、盗聴やクロスサイトスクリプティングによってセッションIDが漏えいした場合に、そのセッションIDを再利用されてしまう。

Session Fixation

　ログイン前にセッションIDが発行され、ログイン後もそのセッションIDが変化しないサイトでは、この攻撃を受ける可能性がある。

●対策

• 安全なセッション管理方法を選択する
• セッションIDは推測不可能で十分長い文字列にする
• セッションIDには有効期間を付ける
• クリティカルな処理では、別途ID／パスワードによる再認証を行う
• サイト全体をSSLでのアクセスとし、セッションIDを入れるCookieにSecure属性を付ける

　最初の3つに関しては、ミドルウェア（PHP、Java、ASPなど）が提供しているセッション管理システムを使っている限り、ほぼ問題ないだろう。4つ目に関しては、セッションリプレイの対策になる。

　5つ目は、バンキングシステムのような重要なサイトでよく見られる対策である。セッションIDをCookieに入れる方法は、基本的にCookieを奪われると簡単にセッションリプレイ攻撃を受けてしまうため、全てをSSLでのアクセスにしてしまうのである。ただ、この方法だけでは完璧ではないため、4つ目の方法との併用が必要である。

　なお、Session Fixationの対策であるが、基本的にはミドルウェアが提供しているセッション管理システムを使っていれば問題ない。ただし、JSP／Servletのセッション管理において、URL中のセッションIDをCookieとして受け入れてしまう場合があるようである。

　例を示そう。あるサイトのログインページにアクセスすると、

http://www.example.com/login.jsp;jsessionid=xxxxxxx

というようなURLが発行される。このURLを他人に渡すとそのセッションIDでログインすることができる。このようなセッションID発行方法は危険であるため、注意してほしい。

Error Codes（エラーコード）

　不正な入力を行うことによりアプリケーションを誤動作させエラーメッセージを表示させる攻撃である。エラーメッセージにはさまざまな種類があるが、一番多いのはデータベース（もしくはデータベースドライバ）が返すSQL関係のエラーメッセージである。

　この脆弱性単体によって被害が発生することは少ない。通常はエラーメッセージの内容を参考にパターンを変えながら攻撃を続けることになる。SQL関係のエラーでは、生成されたSQL文のどの部分が不正なのか具体的なエラーを出力してくれる場合があるため攻撃が成功する可能性が高くなる。

●脆弱性が存在する可能性がある個所

　エラーが発生する個所は、基本的にはユーザー入力を使って内部処理を行う個所である。入力画面、確認画面、登録完了と遷移するアプリケーションがあったとする。確認画面で行われるのは入力チェック程度であろうから、エラーが発生する可能性は低い。それよりも登録完了のところでは何らかの内部処理を行っていることが多いので、こちらの方が発生する可能性がある。

●対策

• 入力チェック
• サニタイジング
• エラーハンドリング

　入力チェックとサニタイジングは必須である。これらの処理を行っていればエラーが発生することはほぼなくなるだろう。ただし、これだけでは完ぺきではない。エラーが発生するのは不正入力だけとは限らないからである。エラーが発生する可能性があるすべての関数の呼び出しでは必ずエラーハンドリングを行い、エラーが発生した場合は作り込みのエラーページを表示させる必要がある。デフォルトのエラーページを表示させてはならない。

---

　以上、10種類の脆弱性について説明した。本連載を開始してから2年近くたつが、入力チェックやサニタイジングを全く行っていないサイトがいまだに存在している。小規模サイトだけでなくかなり重要なサイトでも、単純なミスに起因する重大な脆弱性が発見されている。アプリケーション開発者はもっとセキュリティを重視した開発を行うようにしていただきたいと思う。

5/5

Index
Webアプリケーションの脆弱性を総括する
	Page1 クロスサイトスクリプティング パラメータ改ざん
	Page2 SQLインジェクション OSコマンドインジェクション
	Page3 Path Traversal  バックドアとデバックオプション
	Page4 Client Side Comment Forceful Browsing
	Page5 セッション系の脆弱性 Error Codes

Profile

中村隆之（なかむらたかゆき） 三井物産セキュアディレクション株式会社勤務。 セキュリティコンサルタントとして主にWebアプリケーションのセキュリティ検査に従事しており、大手ポータルサイト、オンラインバンキングなどの数多くの検査実績を持つ。また、セキュアネットワーク及び暗号関連の研究に携わり、大手製造、官公庁、金融機関へのセキュリティシステム導入など数多くの実績を持つ。 三井物産セキュアディレクション株式会社 主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サー ビスも実施中。

関連記事 特集：クロスサイトスクリプティング対策の基本 連載：不正侵入の手口と対策 連載：インシデントレスポンスはじめの一歩〜rootkitを検出するために

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）