Cookiesによるセッションに関して整理する
おっちー(O.S)一般的なCookieによるセッション機能
上記の図は、Cookieによるセッション機能をブラウザとwebサーバーという立場からフローを表した図である。
セッションIDはユーザーのセッションを一意に識別するために使用され、web(もしくはAPP)サーバー側のセッションストアにセッションIDとユーザー情報の対応付けが保存されている。
ここでセッションストアとして使われるのが、RedisやMemcachedだったりする。
ここでいうcookieはセッションCookieのことを指すことが多く、ブラウザを閉じると削除される。
CookieとセッションCookieの違い
- セッションCookieは、ブラウザが閉じられるまで有効な一時的なCookieのこと。
- 一般的なログイン機能で使われる。
- ここでの落とし穴として、ブラウザが閉じられてセッションCookieが消失した後も、ウェブアプリケーションのセッションストアにセッションIDとユーザー情報のマッピング情報が残っている場合、理論的にはそのセッションIDを知っている第三者がなりすましを行う可能性がある。
- Cookieは「永続的なCookie」とも呼ばれ、ブラウザを閉じても保持される。
- 特定の有効期限（
Expires属性）または特定の時間経過後に期限切れになる（Max-Age属性）までブラウザに保存される。 - ユーザーがサイトに再訪した時に自動的にログイン状態を復元したい場合に使う。
- 特定の有効期限（
- ExpiresまたはMax-Age属性を見て、ブラウザはCookieがセッションCookieか永続Cookieかを判断
railsではどうなってる？
railsのデフォルトでは、railsのCookieStoreはクライアント側のcookieにセッションハッシュを保存する。
これによって、セッションIDとセッション情報のマッピングをサーバー側で保持しなくて済むので、アプリケーションのスピードは大幅に向上する。
あんまりないと思うけど、session情報で4KB以上の大きなデータを扱いたい場合はRedisとか使った方が良さそう。
参考
【Cookieについて】
【Redisによるセッションストア】
おっちー(O.S)セッションIDとセッション情報のマッピング
上記の例として、
例えば、railsのデフォルトの仕様だと、
session[:user_id] = params[:user_id]
を実行すると、
{ 'user_id' => params[:user_id] }
のような形式のkey-valueがユーザーのブラウザに保存される
ここからは仮説だが、
{ session_id => { 'user_id' => params[:user_id] } }
のように保存されているんだと思う。
おっちー(O.S)参考
おっちー(O.S)クライアントサイドの言語でset-cookieするとなぜマズイのか？
nerusan-
セキュリティ上の脆弱性： クライアントサイドでCookieを設定すると、ユーザーがそれを悪意のある目的で変更できる可能性があります。例えば、JavaScriptコードがブラウザ上で実行されているため、攻撃者はコードを変更して不正なCookieを設定することができます。これにより、セキュリティ上の問題が発生する可能性があります。
-
信頼性の欠如： クライアントサイドの操作は信頼性が低く、確実に実行されることが保証されません。ブラウザのJavaScriptが無効になっている場合や、ユーザーが不正な手段でスクリプトを変更した場合など、Cookieの設定が期待通りに動作しない可能性があります。
-
セキュリティベストプラクティスの違反： クライアントサイドでCookieを設定する代わりに、サーバーサイドでCookieを設定することが一般的なセキュリティベストプラクティスです。サーバーサイドでCookieを管理することで、セキュリティ上の脆弱性を最小限に抑え、信頼性を確保できます。
おっちー(O.S)実験
- 実際にRedisでsessionストアを構築して、どのように値が保存されてるか観察する。
- どのようにすればCookieを用いたなりすましを防げるのか？
-
認証方法について調べる
- これは別記事として書いてもいいかも。