アヤオのレベリングキロク

日々のインプットをここでアウトプットします

【Rails】sessionの仕組みや使い方の疑問を調べる

きっかけ

sessionって根幹の機能だからほぼ完成されてて、あんまり触ることも、作ることもなかった。

仕組みは知ってるつもりだけど、いざ作れって言われたら、少々時間かかりそう。。

しかもフレームワークがよしなにやってくれちゃって、ブラックボックス化している感もあるやつ。

というわけで、なんとなくうろ覚えな部分を調べた。

そもそもsession情報ってどこに保存されるんだっけ?

  • 基本的にcookieというか、クライアント側が持っているんだよな〜っていうのはわかるけど、 最近はセキュリティ的にナマで置いているわけないし、どうしてるんだったかな〜

  • サーバ側にも保存することあるけど、どういう使い分けすべきだったかな〜

この辺を明確にしていきたい

参考リンク

手っ取り早く、基本に戻るならRailsガイド。

railsguides.jp

railsguides.jp

わかったこと

  • 基本的にこの2種類ね

ActionDispatch::Session::CookieStore: すべてのセッションをクライアント側のブラウザのcookieに保存する ActionDispatch::Session::CacheStore: データをRailsのキャッシュに保存する

  • 固有のIDをcookieに保存する

あらゆるセッションは、セッション固有のIDをcookieに保存します

  • cookieのセキュリティ対策もしてくれるらしい

    cookieデータは改竄防止のために暗号署名が与えられています。さらにcookie自身も暗号化されているので、内容を他人に読まれないようになっています。(改ざんされたcookieRailsが拒否します)

  • 容量制限あるのね!他のデータも保存してたような..

    cookieの上限は4KBです。セッションに関連するデータを保存する目的でのみcookieをお使いください。

  • 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がデフォルトでやってくれてることがめっちゃある! →なんとなく使ってたものも多いけど、少し知れた
  • 過去の実装の仕方が良くなかった箇所を知ることができた!

また時間あるときにセキュリティガイドを読み進めたい。