人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

WebアプリのSession管理について
セッションIDだけでなくセッションデータ自体も暗号化してCookieに入れて管理したいと考えています。

まず思いつく疑問としてどのくらい容量が使えるのかというのがあります。
たとえばテキストエリアフォームの2000文字のテキストを10個くらい入れても問題ないのでしょうか。
またセキュリティ上注意する点などありましたら教えてください。

Cookieにセッションデータを入れるのがなんとなく好まれてない雰囲気があると思うのでいろいろ問題がありそうな気もするのですが

●質問者: timestep
●カテゴリ:インターネット ウェブ制作
○ 状態 :終了
└ 回答数 : 3/3件

▽最新の回答へ

1 ● techmedia-think
●5ポイント

Cookieの最大サイズは確か4KBまでだったと思うので、それを超えるデータは保存できないかと思います。


2 ● a-kuma3
●85ポイント ベストアンサー

http://www.ietf.org/rfc/rfc2965.txt

HTTP State Management Mechanism
...
5. IMPLEMENTATION CONSIDERATIONS
...
5.3 Implementation Limits
...
* at least 4096 bytes per cookie (as measured by the characters
that comprise the cookie non-terminal in the syntax description
of the Set-Cookie2 header, and as received in the Set-Cookie2
header)

* at least 20 cookies per unique host or domain name

RFC 2965 では、最低でも 4096byte のデータを扱えるようにしましょう、となってます。
あと、ひとつのドメインあたり、20個までは扱えるように、と。
# RFC で決められているのは、最大サイズではなく、最小サイズです

じゃあ、実際にどこまで使えるんでしょう。
ちょっと古いですが、調べた人がいます。
http://www.upken.jp/kb/yONABCJYezwRUFvgceUEifjBphmQ.html
http://www.teria.com/~koseki/memo/cookie/cookie_4k.html

多少、ブレはあっても、4Kbyte を遥かに超えたサイズは、扱えないと思っておいたほうが良さそうです。

たとえばテキストエリアフォームの2000文字のテキストを10個くらい入れても問題ないのでしょうか。

なので、2000文字(4000byte)のテキストを一つのクッキーとして扱えば、一応、10個くらいまでは扱えそうです。
でも、暗号化するんですよね。
よく使われる暗号化アルゴリズムをバイナリになっちゃうので、テキスト形式にエンコード(Base64 とか)する必要がありますよね。
そうすると、元のデータよりも少しサイズが増えるので、1500byte くらいしか扱えないですね。

クライアントを選びますが、限られた範囲であれば、HTML5 の Web Storage を使う手もありますね。
ブラウザによりますが、数メガバイトまでは扱えます。

またセキュリティ上注意する点などありましたら教えてください。

鍵は絶対に、Cookie に持たないこと。
解読されちゃう危険があります。
ということは、javascript では、Cookie の値を使えない(復号できないから)、ということになります。

鍵がなくても、暗号強度が弱いアルゴリズムを使ってると、解読されちゃうリスクが大きくなります。


セッションデータをクライアントに持ちたい、という要求の背景が分からないまま書いてますが、サーバサイドで管理するよりは、確実にセキュリティ上のリスクが増えることを認識しておいた方が良いと思います。


timestepさんのコメント
大変勉強になりました。 クライアントで持ってもらった方がサーバーの負荷や管理の点からずっと楽になると思い、逆にサーバー側で持たなくてはいけない理由は何だろうと思って質問しました。 WebフレームワークでもCookieでの管理がデフォルト設定になっているものもありましたので。 Javascriptで使えないというところまで考えが及んでいなかったのでこの点が痛いですが、(思っていたよりは)Cookieでも使えそうな気がしました

a-kuma3さんのコメント
Cookie って、URL が該当すれば、サーバサイドの処理で使わなくても、リクエストに乗っかって飛んでいくので、負荷の軽減にはならないです(負荷と言っても、微々たるものですが)。 毎回、サーバとクライアントの間を行き来するなら、短いセッションキーをやり取りした方が、ネットワークの負荷は軽くて済みます(特に、回線が細かった昔では)。 ただ、全部サーバサイドに持っておく必要はないよね、って発想は誰でも持っていたはず(特に、セッションをまたいで永続化したいデータ)で、だからこそ、HTML5 で Web Storage が定められたんだと思います。

timestepさんのコメント
WebStorageはネットワーク負荷も軽いみたいですね。こちらも検討したいと思います。ありがとうございました。

3 ● taroe
●10ポイント

Internet Explorer で cookie の数とサイズの制限
Microsoft Internet Explorer には、最低限の制限を推奨以下の RFC 2109 に準拠しています。
少なくとも 300 のクッキー
(端末以外の Set-cookie ヘッダーの構文の説明での cookie を構成する文字のサイズを測定すると)、cookie ごとに 4,096 バイト以上
少なくとも 20 の cookie ごと一意のホストまたはドメイン名
注これらの推奨最小制限セクション 6.3 では、「実装制限」、RFC 2109 でが表示されます。詳細については、「関連情報」セクションを参照してください。

http://support.microsoft.com/kb/306070/ja



Cookieでセッションデータの中身自体を持つのは
そのデータサイズによりますが、
クッキーの場合、確かに仕様では4KB程度はいけますが
今はどうかは知りませんが、大きなサイズので安定性が良くないと思います。

何か問題が起こった場合は、環境依存、端末依存になり原因追及が困難です。
あまり多くの人がやらないことをするのは、リスクが高すぎると思います。

>WebフレームワークでもCookieでの管理がデフォルト設定

セッションIDをクッキーで保存するという意味だと思いますし
現状、多くのWEBシステムはこれが標準です。


timestepさんのコメント
>セッションIDをクッキーで保存するという意味だと思いますし いいえ。SessionデータをCookieに格納するような設計になっているWebフレームワークがあります。例えばPHPならCodeIgniter, Pythonならflaskなどがそうです
関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ