こんにちは。木村です。
今回はRuby On Rails Security Guideの訳 : 2.Sessions 2.1 – 2.3の続きです。
今回は2 Sessionsの2.5 Session Storageまでです。
原文の単語と全く違う言葉に置きかえている場合も多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。
では、以下訳です。
2.4 セッション・ガイドライン
- セッションに関する一般的なガイドラインは以下の通りです。
- セッションに大きなオブジェクトを保存しない。かわりに、データベースにオブジェクトを保存して、そのIDをセッションに保存するべきです。こうすることで、オブジェクトの同期をとらなければならない頭痛の種が解消され、セッションのストレージスペースがいっぱいになることもないでしょう(セッションのストレージに何を選んでいるかによります、下記参照)。もし、あなたがあるオブジェクトの構造を変更して、ユーザのクッキーにその前のバージョンのオブジェクトがまだ残っているような場合に、この方法が良い解決方法になります。サーバ側のセッションは消すことができますが、クライアント側のセッションを消すことは難しいです。
- 重要なデータをセッションに保存しない。もしユーザがクッキーを削除するかブラウザを閉じてしまえば、それらは失われます。そして、ユーザはクライアント側に保存されたセッションで、そのデータを見ることができます。
2.5 セッションストレージ
- Railsにはセッションハッシュを保存する方法がいくつかあります。最も重要なのはAcriveRecordStoreとCookieStoreです。RailsにはセッションハッシュとセッションIDを保存するセッションの保存方法がいくつかあります。今、稼動しているアプリケーションのほとんどは、ファイルに保存する方法よりも、性能やメンテナンス性が良い理由で、AcriveRecordStore(またはその派生物のどれか)を使用しています。ActiveRecordStoreはセッションIDとハッシュをデータベースで保持し、リクエストごとにハッシュを保存したり、取り出したりします。
Rails 2では新しいデフォルトのセッションストレージであるCookieStoreが導入されました。CookieStoreはセッションハッシュをクライアントサイド側のクッキーに直接保存します。サーバはそのクッキーからセッションハッシュを取り出し、セッションIDを必要としなくなります。これはアプリケーションのスピードを非常に速くしますが、賛否両論があるストレージオプションであり、これによって引き起こされるセキュリティへの影響について考える必要があります。
- クッキーは厳密に4KBのサイズ制限があります。これは、前述の通り、どのみち大容量のデータをセッションに保存するべきではないので、問題になりません。セッションには現在のユーザのデータベースIDを保存しておけば、たいていOKです。
- クライアントはセッションに保存したものを全て見ることができます。セッションが平文で保存されているためです(実際にはBase64エンコーディングなので、暗号化されていません)。ですから、当然ここにどんな秘密も保存してはいけません。セッションハッシュの改ざんを防ぐために、サーバ側の秘密の文字列とセッションから計算されたダイジェストをクッキーの終わりに挿入します。
これは、CookieStoreのセキュリティがこの秘密の文字列に依存することを意味します。(更に、ダイジェストアルゴリズムにも依存します。デフォルトではSHA512です。SHA512はまだ解析されていません。) ですから、平凡な秘密の文字列を使ってはいけません。すなわち、辞書から引いた単語や、30文字以下のものです。秘密の文字列はenvironment.rbに次のように書いてください。
config.action_controller.session = {
:key => ‘_app_session’,
:secret => ‘0×0dkfj3927dkc7djdh36rkckdfzsg…’
}
また一方、CookieStoreの派生として、セッションハッシュを暗号化するものもあります。その場合は、クライアントはセッションを見ることができません。
