TOP設計・移行・活用> セッションストレージの選択
SledgeによるWebアプリケーションフレームワーク入門
SledgeによるWebアプリケーションフレームワーク入門

第2回:セッション管理
著者:ライブドア  谷口 公一   2005/6/15
前のページ  1  2  3  4
セッションストレージの選択

   Sledgeでは「MySQLのDB上に保存するようなしくみを標準的に備えている」と説明しましたが、Sledge::Session::*以下に、好みのストレージ用の操作クラスを書くことによって、MySQLに限らず、単純なファイルであったりmemcached(注1)であったりと、保存先を自由に選択することができます。

   注意点としては、アプリケーションサーバが複数台におよぶ場合にすべてから参照できるストレージを選ぶ必要があります。

   sourceforge.jp内のSledgeプロジェクト(注2)のCVSリポジトリに存在するSledge-Session-AnyDBMというのは、筆者がライブドア入社直後に、セッションデータをDBMに保存するためのクラスとして作ってみたものです。好みのストレージ向けに独自のクラスを書きたい場合のサンプルとしてはいい参考になるのではないでしょうか。

セッションが可能にしたWebアプリケーションの多様性

   このように、セッションを用いることによってユーザは別のページでの入力情報を保持したまま、ユーザ側に意図的に「かつての入力情報」を引き回させることなく容易にページをまたぐことが可能になります。

   かつてセッションという概念が浸透する以前のWebアプリケーションでは、すべてのデータを「<input type="hidden">」で引き回したり、すべてのデータをCookieに保存するような実装方法を頻繁に目にしました。これらは、下記のような問題点を抱えています。

  1. 引き回されたデータをユーザが改竄する可能性がある
  2. Webアプリケーション開発者側が考えた経路を辿らなくてはいけない

   そのため、常にすべてのページで汚染チェックを行なう必要がありました。また、汚染チェック漏れによってセキュリティホールが晒される危険性も孕んでいました。

   その点、現在のWebアプリケーションではごく一般的となっているセッションという概念により、Webアプリケーションとして今まで存在し得なかった、前のページに戻ったり、ページをスキップしたり、かつて入力した情報を復元したりという「クライアントサイドアプリケーション」のような動作を実現することができるようになりました。また、設計さえ適切に正しく行なっていれば、アプリケーションの堅牢性ははるかに高くなっています。

   次回では「認証管理」について触れる予定ですが、「ユーザがログインしている」という状態情報に関しても、常に「ユーザ名/パスワード」のペアを生データのままCookieやhiddenで引き回すことなく遷移できるというのは、セッションという概念によって容易に実装できるようになったからであるのは言うまでもありません。

セッションが生み出したセキュリティホール"CSRF"

   セッションは便利な反面、Webアプリケーションを実装する側の不注意によってセキュリティ上の問題を引き起こす可能性があります。先日あるソーシャルネットワーキングサービスにおいて、CSRF(Cross Site Request Forgeries)と呼ばれる脆弱性が発覚し、話題になったことがありました。

   外部サイトの該当サービスのアプリケーションに対して第三者の仕込んだ文字列がPOSTされるトラップが仕掛けられ、そのトラップの置かれたページにアクセスさせることによって、トラップを踏んだ人は意図せず、勝手にその情報を送信させられてしまうというものです。

   当然ながら認証機能が利用されているサイトですが、認証用のセッション情報を伴なってデータを送信することによって、送信元や、含まれるデータの正当性如何に関わらず、勝手にコントロールされてしまう脆弱性でした。

   Session IDを傍受してSession Hijackされるといった類のものではなかったため、大した被害こそありませんでしたが、正常に認証されているユーザに対してしか許可されるべきではない操作を、悪意ある第三者の意図によって外部経由で送信される危険性を持っているという事を改めて認識させられるような事件でした。

   全員が共通のパラメータによって送信されるような実装ではなく、こういった危険性を孕んでいる箇所では、むしろ積極的にhiddenを利用し、一意的なパラメータを埋め込み、そのパラメータの検証をするような設計、あるいは、直接的に送信されるパラメータは絶対的には信用せずに、検証して一旦セッションに保持し、セッションに保持された情報のみを信用する等の設計を行なう必要があります。

前のページ  1  2  3  4


株式会社ライブドア 谷口 公一
著者プロフィール
株式会社ライブドア  谷口 公一
テクニカルディレクター。専門知識が全く無い中、オープンソースソフトウェアやコミュニティからシステム開発の知識やノウハウを習得し、オープンソースコミュニティにおいて活発に活動を行っている同社に憧れて入社。現在はポータルサイト「livedoor」におけるサービス開発を行う一方、本業の傍ら、お世話になっているオープンソースコミュニティへのコントリビューションも行なっている。


INDEX
第2回:セッション管理
  セッションとは
  セッションの実装
  セッション情報の管理手法
セッションストレージの選択