2008-01-13 (Sun) [長年日記]
_ CookieStoreとセキュリティ
Rails 2.0ではCookieStoreという新しいセッションストアが導入されている。 CookieStoreは、セッションデータをサーバ上のファイルやDBに保存する代りに、クッキー自体に保存する。 このため、セッションデータの読み書きのコストが減ったり、古いセッションデータ の掃除の手間がなくなる、という利点がある。
「そんなことをしたらユーザにセッションデータを改竄されるじゃないか」というのが 当然の疑問だが、HMAC(デフォルトではSHA1)によるチェックで改竄を防ぐようになっ ている。
ただし、セッションデータ自体は平文(marshal+base64)なので、中身を見られてしま う。これについては、そもそもユーザに見られては困るようなデータをセッションデ ータに格納すべきではない、という立場を取っているようだ。
ちょっと気になるのが、サーバが一度発行したクッキーは、HMACで使用する鍵を 変えたりしない限り、ずっと有効だということだ。 悪意のある第三者がクッキーを盗聴してリプレイを試みる、というケースに ついては、盗聴できたという時点で他のセッションストアの場合もセッションハイ ジャックが可能になるので、CookieStoreがとりわけ危険だというわけではない。 気になるのは、ユーザがセッションの状態を任意の時点に戻すことができる点だ。 アプリケーションの作りによっては悪さができそうな気もするのだけれど、 実際のところどうなのだろう。 「そんなことができるアプリケーションはそもそも作りが悪いのだ」と言ってすませ ることができるものなのだろうか。
たとえば、セッションデータにはユーザIDだけ格納しておいてその他の状態は全部DBに格納すれば 上記のような心配はしなくていいわけだけど、それだったら最初からActiveRecordStore を使えばいい気もする。
任意の時点にセッションの状態を戻されること自体を防ぐには、セッショ ンデータにnonceを入れておいてチェックすればよい。 ただ、サーバ側でnonce値を保存する必要があるということになるとCookieStoreの利点(高速・セッションデータの掃除が不要)がかなり損なわれる。
というわけで、簡単な解決は思い付かなかった。そもそも問題なのかどうかもよくわかっていないのだが。
最後にもう一点。CookieStoreの場合、session fixation attackの心配がなくなりそうだ。 攻撃者が被害者に特定のセッションIDを利用するように仕向けることができない(と いうかそもそもセッションID自体がない)から(見落としがあればご指摘を)。
「あれ、session fixation attackってRails 1.2.4と1.2.6で対策されたんじゃないの?」 と思われるかもしれないが、Rails 1.2.4/1.2.6ではURLでセッションID を指定できないようにしただけなので、Cookie MonsterやXSSを利用した攻撃を考え るとアプリケーション側で対策が必要だ。 認証の際にreset_sessionでセッションIDを変更すればよいのだが、自分の知るかぎり どの認証プラグインも対策してないので自分で対策する必要がある。
_ RailsによるアジャイルWebアプリーション開発第2版とRails 2.0
Rails 2.0で…という質問が今後増えることが予想されるわけですが、 とりあえず、
> gem install -v 1.2.6 rails
としてRails 1.2.6をインストールして一通りチュートリアルをこなした上で、Rails 2.0に移行されることをおすすめします。
だれか、Rails 2.0でdepotを作る手順とかまとめてくれないかなあ。