QA@IT
«質問へ戻る

再回答に対するお礼

70
本文
 > もしも64KB以上のデータをセッションに入れたい場合は、セッション情報をDBに入れてCookieにはセッションIDだけを保存することも可能です。
 
 こちらは上述の通り、権限やロールぐらいの情報だとどうするのかなーという点が気になりました。
+
+---
+
+## moro さんの再回答に関して
+
+再度の丁寧な回答、ありがとうございました。
+
+なるほど、であれば普通に考えると
+
+* Cookie にはセッション ID を保存
+* サーバではセッションのハッシュを保持し、Cookie のセッション ID から現在のセッションを特定
+* セッションにはユーザー ID を保持しておき、これを利用して DB からユーザー情報を取得
+
+という感じになりますね。
+
+1. の件は勘違いしていました。http と https が混在する状態で、http 側で Cookie が盗まれた場合の心配をしていたのですね。
+4. に関しても理解しました。
+
+
+丁寧に教えて頂き大変助かりました。ありがとうございます。

Web アプリケーションの認証とセキュリティに関して教えて下さい

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
Rails で (Rack の) セッション情報を Cookie に保存する仕組み

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

  • セッション ID
  • CSRF トークン
  • 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

質問

ここで幾つか教えて頂きたいことがあります。

  1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

  2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

  3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

  4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?

何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。


moro さんの回答 に対する再質問

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

はじめに

こちらは誤解で、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だけを保存することも可能です。

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


moro さんの再回答に関して

再度の丁寧な回答、ありがとうございました。

なるほど、であれば普通に考えると

  • Cookie にはセッション ID を保存
  • サーバではセッションのハッシュを保持し、Cookie のセッション ID から現在のセッションを特定
  • セッションにはユーザー ID を保持しておき、これを利用して DB からユーザー情報を取得

という感じになりますね。

  1. の件は勘違いしていました。http と https が混在する状態で、http 側で Cookie が盗まれた場合の心配をしていたのですね。
  2. に関しても理解しました。

丁寧に教えて頂き大変助かりました。ありがとうございます。

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

## Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
[Rails で (Rack の) セッション情報を Cookie に保存する仕組み](http://qiita.com/items/32efc5b7c73aba3500ff)

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

* セッション ID
* CSRF トークン
* 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

## 質問

ここで幾つか教えて頂きたいことがあります。

1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?


何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

---

## [moro さんの回答](http://qa.atmarkit.co.jp/q/2792#answer_15410) に対する再質問

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


## はじめに

> こちらは誤解で、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だけを保存することも可能です。

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

---

## moro さんの再回答に関して

再度の丁寧な回答、ありがとうございました。

なるほど、であれば普通に考えると

* Cookie にはセッション ID を保存
* サーバではセッションのハッシュを保持し、Cookie のセッション ID から現在のセッションを特定
* セッションにはユーザー ID を保持しておき、これを利用して DB からユーザー情報を取得

という感じになりますね。

1. の件は勘違いしていました。http と https が混在する状態で、http 側で Cookie が盗まれた場合の心配をしていたのですね。
4. に関しても理解しました。


丁寧に教えて頂き大変助かりました。ありがとうございます。

追加質問

70
本文
 
 
 何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。
+
+---
+
+## [moro さんの回答](http://qa.atmarkit.co.jp/q/2792#answer_15410) に対する再質問
+
+丁寧な回答ありがとうございます。
+幾つか追加で教えて頂いて宜しいでしょうか。
+
+
+## はじめに
+
+> こちらは誤解で、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だけを保存することも可能です。
+
+こちらは上述の通り、権限やロールぐらいの情報だとどうするのかなーという点が気になりました。

Web アプリケーションの認証とセキュリティに関して教えて下さい

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
Rails で (Rack の) セッション情報を Cookie に保存する仕組み

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

  • セッション ID
  • CSRF トークン
  • 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

質問

ここで幾つか教えて頂きたいことがあります。

  1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

  2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

  3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

  4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?

何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。


moro さんの回答 に対する再質問

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

はじめに

こちらは誤解で、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だけを保存することも可能です。

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

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

## Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
[Rails で (Rack の) セッション情報を Cookie に保存する仕組み](http://qiita.com/items/32efc5b7c73aba3500ff)

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

* セッション ID
* CSRF トークン
* 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

## 質問

ここで幾つか教えて頂きたいことがあります。

1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?


何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

---

## [moro さんの回答](http://qa.atmarkit.co.jp/q/2792#answer_15410) に対する再質問

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


## はじめに

> こちらは誤解で、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だけを保存することも可能です。

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

merged patch request

70
タグ

Web アプリケーションの認証とセキュリティに関して教えて下さい

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
Rails で (Rack の) セッション情報を Cookie に保存する仕組み

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

  • セッション ID
  • CSRF トークン
  • 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

質問

ここで幾つか教えて頂きたいことがあります。

  1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

  2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

  3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

  4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?

何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

## Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
[Rails で (Rack の) セッション情報を Cookie に保存する仕組み](http://qiita.com/items/32efc5b7c73aba3500ff)

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

* セッション ID
* CSRF トークン
* 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

## 質問

ここで幾つか教えて頂きたいことがあります。

1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?


何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

merged patch request

70
タグ

Web アプリケーションの認証とセキュリティに関して教えて下さい

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
Rails で (Rack の) セッション情報を Cookie に保存する仕組み

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

  • セッション ID
  • CSRF トークン
  • 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

質問

ここで幾つか教えて頂きたいことがあります。

  1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

  2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

  3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

  4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?

何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

## Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
[Rails で (Rack の) セッション情報を Cookie に保存する仕組み](http://qiita.com/items/32efc5b7c73aba3500ff)

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

* セッション ID
* CSRF トークン
* 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

## 質問

ここで幾つか教えて頂きたいことがあります。

1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?


何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

タグにtypo

1138
タグ

Web アプリケーションの認証とセキュリティに関して教えて下さい

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
Rails で (Rack の) セッション情報を Cookie に保存する仕組み

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

  • セッション ID
  • CSRF トークン
  • 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

質問

ここで幾つか教えて頂きたいことがあります。

  1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

  2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

  3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

  4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?

何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

## Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
[Rails で (Rack の) セッション情報を Cookie に保存する仕組み](http://qiita.com/items/32efc5b7c73aba3500ff)

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

* セッション ID
* CSRF トークン
* 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

## 質問

ここで幾つか教えて頂きたいことがあります。

1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?


何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

質問を投稿

Web アプリケーションの認証とセキュリティに関して教えて下さい

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
Rails で (Rack の) セッション情報を Cookie に保存する仕組み

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

  • セッション ID
  • CSRF トークン
  • 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

質問

ここで幾つか教えて頂きたいことがあります。

  1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

  2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

  3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

  4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?

何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。

こんばんは。Web アプリケーションの認証とセキュリティに関して教えて下さい。

## Rails のセッション管理

Rails は RESTful な Web アプリケーションの構築を可能にするとは言っていますが、実態としてはサーバーサイドに保持し、セッション ID は Cookie に保存しているものだと思っています(Rails の経験が殆ど無いので間違っていたらすみません)。

で、最近こちらの記事を読みました。
[Rails で (Rack の) セッション情報を Cookie に保存する仕組み](http://qiita.com/items/32efc5b7c73aba3500ff)

この記事によると、セッション情報は確かに Cookie に保存されています。保存されているのは

* セッション ID
* CSRF トークン
* 秘密鍵を用いて上記を暗号化したハッシュ値

で、最後のハッシュ値によりセッション ID の漏出を防いでいると理解しました。同時に、トークンを保持することで CSRF 対策も行われています。

## 質問

ここで幾つか教えて頂きたいことがあります。

1. 確かに上記の対策によりセッション ID が推測されたり乗っ取られたりすることは無さそうですが、そうは言っても Cookie の値は HTTP リクエストに乗って送信されます。仮にこのリクエストを覗き見されてしまうとそのままセッションの乗っ取りが可能ですよね?これは一般的にどのように対策するのでしょうか?例えば「はてな」ではログイン画面は https で通信していますが、それ以外の画面は普通の http です。とはいえ「どのユーザーでログインしているか」という情報はやはり Cookie に保持しているのではないかと思い、そうすると Cookie が覗き見されてしまうのでは?と思っていますのですが・・・。

2. 上記の「はてな」の例で言うと、ログイン画面が https 通信なのは、パスワードを平文で送信するのを防ぐためという理解で良いでしょうか?

3. インターネット上に公開している Web アプリケーションの場合、「はてな」のようにログイン画面だけ https にするのが普通だと思うのですが、例えば業務アプリケーションのようにプライベートネットワーク内でしか動かない Web アプリケーションの場合、上記のようなセキュリティに関してはどこまで考えるべきなのでしょうか?そもそもログイン画面を https にしたりする必要は無いのでしょうか?それとも、業務アプリケーションだけに万全を期して全ページ https にするなどが普通なのでしょうか?もちろん、クライアントのセキュリティ要件にもよると思うのですが、一般的にはどのようなケースが多いのでしょうか?

4. Rails は Cookie およびサーバーサイドにセッション情報を保存していますが、REST 本来の意味ではこれは NG だと思っています。とはいえ実態としてはこれ以外にあまり良い方法も思いつきません。サーバーサイドはセッション情報を DB や KVS に保存するなどの方法があるかと思いますが、少なくとも Cookie は使うことになるのかなと思っています。Cookie を使わない方法もあるのでしょうか?Web アプリで BASIC 認証や Digest 認証は使えませんよね?


何だか長くなってしまい恐縮ですが、分かる範囲で教えて頂けると幸いです。宜しくお願い致します。