検索
連載

Webアプリケーションの脆弱性を総括する：Webアプリケーションに潜むセキュリティホール（14）（5/5 ページ）

[中村隆之，三井物産セキュアディレクション] PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

セッション系の脆弱性

　セッション系の脆弱性には、「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年近くたつが、入力チェックやサニタイジングを全く行っていないサイトがいまだに存在している。小規模サイトだけでなくかなり重要なサイトでも、単純なミスに起因する重大な脆弱性が発見されている。アプリケーション開発者はもっとセキュリティを重視した開発を行うようにしていただきたいと思う。

著者紹介

中村隆之（なかむらたかゆき）

三井物産セキュアディレクション勤務。 セキュリティコンサルタントとして主にWebアプリケーションのセキュリティ検査に従事しており、大手ポータルサイト、オンラインバンキングなどの数多くの 検査実績を持つ。また、セキュアネットワーク及び暗号関連の研究に携わり、大手製造、官公庁、金融機関へのセキュリティシステム導入など数多くの実績を持つ。

三井物産セキュアディレクション

主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サービスも実施中。


「Webアプリケーションに潜むセキュリティホール」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 　　　　　　
ページトップに戻る