QA@IT
«回答へ戻る

質問分に移動

70
-丁寧な回答ありがとうございます。
-幾つか追加で教えて頂いて宜しいでしょうか。
-
-
-## はじめに
-
-> こちらは誤解で、Railsは(デフォルトでは)セッション情報を すべて Cookieに入れます。ですからたとえばRailsのセッション情報はシリアライズした上で64KBまでしか入れられませんが、それはそういうものだから設計を見なおすべき、というのがRails wayであるとされています。
-
-おや、そうなんですね?
-
-良く Rails で ```session[:user_id]``` みたいなコードを見るのでサーバーサイドにセッションを保持しているのかと思っていました。このセッションストアが KVS だったり ActiveRecord だったりするのかなと思っていたのですが・・・。DB にセッション情報を永続化して都度取得するようにすると重くなってしまうので、インメモリもしくは KVS あたりにセッション情報を保存するのかなと思っていました。
-
-全て Cookie に保存する場合、ショッピングカートなどを実現しようと思ったらきっとサーバー側の永続化層にセッション情報を持たざるを得ない気がしますが(間違っていたらご指摘ください)、例えば良くあるユーザーのロール/権限などの情報はどうするのでしょうか?これも Cookie に保存するのが一般的なのでしょうか?また、サーバー側で「現在アクセス中のユーザー」を取得せざるを得ないケースが多いかと思うのですが、session id と user の紐づけはどのように行うのでしょうか?user id を Cookie に保存するのはマズいですよね・・・?
-
-
-## 1
-
-うーんなるほど。やっぱり Cookie が盗聴されてしまった場合はどうしようもないのですね。http であろうと https であろうと、そのまま Cookie を利用されたらなりすまし可能であると。素の http 通信を覗かれるとどうしようもないですね。公共無線 LAN が危険というのはこういうところなんですねぇ。
-
-Rails Casts のページ、教えて頂いてありがとうございます。ただ、これって https の場合になりすましを防ぐ方法になっていますが、そもそも https でなりすまし(というか Cookie の盗聴)されるケースってあるのでしょうか……?この対応はやや過剰に思えますが、念のためということなのでしょうか。どれほど一般的なのかなと疑問に思いました。
-
-## 2, 3
-
-納得しました。業務アプリではやはり https が基本ですよね。ありがとうございます。
-上の Rails Casts の対応もそうですが、実際プライベートネットワークで動くアプリケーションでどこまでセキュリティ対策を施すべきなのかがいまひとつ分からないのですが、上記のセッションハイジャック等も意識した対策を行うのが普通なのでしょうか?
-
-## 4
-
-> サーバサイドに保存しているリソースであるところのユーザのIDが入っていて、ユーザの実体はサーバサイドにあるじゃないかといわれるとそうなんですが、それがREST的にNGだとは思いませんがいかがでしょうか。
-
-そうですね。私はサーバーのメモリ上にセッション情報を持っているものだと考えてこのような発言をしたのですが、Cookie もしくは永続化層にあるのであれば REST 的なのかなとは思いました。個人的には、KVS や RDB などの永続化層にステートを持つのは良いと思うのですが、アプリサーバのメモリにステートを持ってしまうのは REST 的に NG だと思っています。
-
-> BASIC認証やDigest認証も使えます。けっこう簡単です。あのあまり見栄えの良くないブラウザダイアログを許容するのであれば、ごく少数のユーザ向け認証はhttps+BASIC認証でやったりもします。session[:user_id]的な識別子が欲しい場合request.env['Authorization']を適宜パースすればよさそうです。
-
-なるほど。まぁ Web アプリとして提供する場合はやはりあのダイアログは駄目ってことになりそうですが使いどころはあるんですね。
-
-> もしも64KB以上のデータをセッションに入れたい場合は、セッション情報をDBに入れてCookieにはセッションIDだけを保存することも可能です。
-
-こちらは上述の通り、権限やロールぐらいの情報だとどうするのかなーという点が気になりました。
+----------------

----------------

回答を投稿

丁寧な回答ありがとうございます。
幾つか追加で教えて頂いて宜しいでしょうか。

はじめに

こちらは誤解で、Railsは(デフォルトでは)セッション情報を すべて Cookieに入れます。ですからたとえばRailsのセッション情報はシリアライズした上で64KBまでしか入れられませんが、それはそういうものだから設計を見なおすべき、というのがRails wayであるとされています。

おや、そうなんですね?

良く Rails で session[:user_id] みたいなコードを見るのでサーバーサイドにセッションを保持しているのかと思っていました。このセッションストアが KVS だったり ActiveRecord だったりするのかなと思っていたのですが・・・。DB にセッション情報を永続化して都度取得するようにすると重くなってしまうので、インメモリもしくは KVS あたりにセッション情報を保存するのかなと思っていました。

全て Cookie に保存する場合、ショッピングカートなどを実現しようと思ったらきっとサーバー側の永続化層にセッション情報を持たざるを得ない気がしますが(間違っていたらご指摘ください)、例えば良くあるユーザーのロール/権限などの情報はどうするのでしょうか?これも Cookie に保存するのが一般的なのでしょうか?また、サーバー側で「現在アクセス中のユーザー」を取得せざるを得ないケースが多いかと思うのですが、session id と user の紐づけはどのように行うのでしょうか?user id を Cookie に保存するのはマズいですよね・・・?

1

うーんなるほど。やっぱり Cookie が盗聴されてしまった場合はどうしようもないのですね。http であろうと https であろうと、そのまま Cookie を利用されたらなりすまし可能であると。素の http 通信を覗かれるとどうしようもないですね。公共無線 LAN が危険というのはこういうところなんですねぇ。

Rails Casts のページ、教えて頂いてありがとうございます。ただ、これって https の場合になりすましを防ぐ方法になっていますが、そもそも https でなりすまし(というか Cookie の盗聴)されるケースってあるのでしょうか……?この対応はやや過剰に思えますが、念のためということなのでしょうか。どれほど一般的なのかなと疑問に思いました。

2, 3

納得しました。業務アプリではやはり https が基本ですよね。ありがとうございます。
上の Rails Casts の対応もそうですが、実際プライベートネットワークで動くアプリケーションでどこまでセキュリティ対策を施すべきなのかがいまひとつ分からないのですが、上記のセッションハイジャック等も意識した対策を行うのが普通なのでしょうか?

4

サーバサイドに保存しているリソースであるところのユーザのIDが入っていて、ユーザの実体はサーバサイドにあるじゃないかといわれるとそうなんですが、それがREST的にNGだとは思いませんがいかがでしょうか。

そうですね。私はサーバーのメモリ上にセッション情報を持っているものだと考えてこのような発言をしたのですが、Cookie もしくは永続化層にあるのであれば REST 的なのかなとは思いました。個人的には、KVS や RDB などの永続化層にステートを持つのは良いと思うのですが、アプリサーバのメモリにステートを持ってしまうのは REST 的に NG だと思っています。

BASIC認証やDigest認証も使えます。けっこう簡単です。あのあまり見栄えの良くないブラウザダイアログを許容するのであれば、ごく少数のユーザ向け認証はhttps+BASIC認証でやったりもします。session[:user_id]的な識別子が欲しい場合request.env['Authorization']を適宜パースすればよさそうです。

なるほど。まぁ Web アプリとして提供する場合はやはりあのダイアログは駄目ってことになりそうですが使いどころはあるんですね。

もしも64KB以上のデータをセッションに入れたい場合は、セッション情報をDBに入れてCookieにはセッションIDだけを保存することも可能です。

こちらは上述の通り、権限やロールぐらいの情報だとどうするのかなーという点が気になりました。

丁寧な回答ありがとうございます。
幾つか追加で教えて頂いて宜しいでしょうか。


## はじめに

> こちらは誤解で、Railsは(デフォルトでは)セッション情報を すべて Cookieに入れます。ですからたとえばRailsのセッション情報はシリアライズした上で64KBまでしか入れられませんが、それはそういうものだから設計を見なおすべき、というのがRails wayであるとされています。

おや、そうなんですね?

良く Rails で ```session[:user_id]``` みたいなコードを見るのでサーバーサイドにセッションを保持しているのかと思っていました。このセッションストアが KVS だったり ActiveRecord だったりするのかなと思っていたのですが・・・。DB にセッション情報を永続化して都度取得するようにすると重くなってしまうので、インメモリもしくは KVS あたりにセッション情報を保存するのかなと思っていました。

全て Cookie に保存する場合、ショッピングカートなどを実現しようと思ったらきっとサーバー側の永続化層にセッション情報を持たざるを得ない気がしますが(間違っていたらご指摘ください)、例えば良くあるユーザーのロール/権限などの情報はどうするのでしょうか?これも Cookie に保存するのが一般的なのでしょうか?また、サーバー側で「現在アクセス中のユーザー」を取得せざるを得ないケースが多いかと思うのですが、session id と user の紐づけはどのように行うのでしょうか?user id を Cookie に保存するのはマズいですよね・・・?


## 1

うーんなるほど。やっぱり Cookie が盗聴されてしまった場合はどうしようもないのですね。http であろうと https であろうと、そのまま Cookie を利用されたらなりすまし可能であると。素の http 通信を覗かれるとどうしようもないですね。公共無線 LAN が危険というのはこういうところなんですねぇ。

Rails Casts のページ、教えて頂いてありがとうございます。ただ、これって https の場合になりすましを防ぐ方法になっていますが、そもそも https でなりすまし(というか Cookie の盗聴)されるケースってあるのでしょうか……?この対応はやや過剰に思えますが、念のためということなのでしょうか。どれほど一般的なのかなと疑問に思いました。

## 2, 3

納得しました。業務アプリではやはり https が基本ですよね。ありがとうございます。
上の Rails Casts の対応もそうですが、実際プライベートネットワークで動くアプリケーションでどこまでセキュリティ対策を施すべきなのかがいまひとつ分からないのですが、上記のセッションハイジャック等も意識した対策を行うのが普通なのでしょうか?

## 4

> サーバサイドに保存しているリソースであるところのユーザのIDが入っていて、ユーザの実体はサーバサイドにあるじゃないかといわれるとそうなんですが、それがREST的にNGだとは思いませんがいかがでしょうか。

そうですね。私はサーバーのメモリ上にセッション情報を持っているものだと考えてこのような発言をしたのですが、Cookie もしくは永続化層にあるのであれば REST 的なのかなとは思いました。個人的には、KVS や RDB などの永続化層にステートを持つのは良いと思うのですが、アプリサーバのメモリにステートを持ってしまうのは REST 的に NG だと思っています。

> BASIC認証やDigest認証も使えます。けっこう簡単です。あのあまり見栄えの良くないブラウザダイアログを許容するのであれば、ごく少数のユーザ向け認証はhttps+BASIC認証でやったりもします。session[:user_id]的な識別子が欲しい場合request.env['Authorization']を適宜パースすればよさそうです。

なるほど。まぁ Web アプリとして提供する場合はやはりあのダイアログは駄目ってことになりそうですが使いどころはあるんですね。

> もしも64KB以上のデータをセッションに入れたい場合は、セッション情報をDBに入れてCookieにはセッションIDだけを保存することも可能です。

こちらは上述の通り、権限やロールぐらいの情報だとどうするのかなーという点が気になりました。