きっかけ
sessionって根幹の機能だからほぼ完成されてて、あんまり触ることも、作ることもなかった。
仕組みは知ってるつもりだけど、いざ作れって言われたら、少々時間かかりそう。。
しかもフレームワークがよしなにやってくれちゃって、ブラックボックス化している感もあるやつ。
というわけで、なんとなくうろ覚えな部分を調べた。
そもそもsession情報ってどこに保存されるんだっけ?
基本的にcookieというか、クライアント側が持っているんだよな〜っていうのはわかるけど、 最近はセキュリティ的にナマで置いているわけないし、どうしてるんだったかな〜
サーバ側にも保存することあるけど、どういう使い分けすべきだったかな〜
この辺を明確にしていきたい
参考リンク
手っ取り早く、基本に戻るならRailsガイド。
わかったこと
- 基本的にこの2種類ね
ActionDispatch::Session::CookieStore: すべてのセッションをクライアント側のブラウザのcookieに保存する ActionDispatch::Session::CacheStore: データをRailsのキャッシュに保存する
- 固有のIDをcookieに保存する
あらゆるセッションは、セッション固有のIDをcookieに保存します
cookieのセキュリティ対策もしてくれるらしい
cookieデータは改竄防止のために暗号署名が与えられています。さらにcookie自身も暗号化されているので、内容を他人に読まれないようになっています。(改ざんされたcookieはRailsが拒否します)
容量制限あるのね!他のデータも保存してたような..
cookieとcacheの使い分け
ユーザーセッションに重要なデータが含まれていない場合、またはユーザーセッションを長期間保存する必要がない場合 (flashメッセージで使いたいだけの場合など) は、ActionDispatch::Session::CacheStoreを検討してください。
SSLを必ず有効にするセキュリティ設定あったんだ。設定されてたのかな?
Webアプリケーションの開発者にとっては、これはSSLによる安全な接続の提供が必要であるということです。Rails 3.1以降では、アプリケーションの設定ファイルでSSL接続を強制することによって達成できます。
config.force_ssl = true
XSS対策はしっかりってよく言われて、Railsに則ってやってたけど、細かい目的は気にしてなかったw
クロスサイトスクリプティング (XSS) 攻撃は、多くの場合、ユーザーのcookieを手に入れるのが目的です。
せやせや、デフォルトで暗号化してくれるんだった
CookieStoreはセッションデータの保管場所をencrypted cookie jarで安全に暗号化します。これにより、cookieベースのセッションの内容の一貫性と機密性を同時に保ちます。暗号化鍵は、signed cookieに用いられる検証鍵と同様に、secret_key_base設定値から導出されます。
まとめ
- sessionデータの保存され方が整理できた!
- sessionはセキュリティ対策がめっちゃ重要で、Railsがデフォルトでやってくれてることがめっちゃある! →なんとなく使ってたものも多いけど、少し知れた
- 過去の実装の仕方が良くなかった箇所を知ることができた!
また時間あるときにセキュリティガイドを読み進めたい。