セッションのクッキーを設定する場合のベストプラクティス

(更新日: 2015/04/21)

HTTPセッションは通常クッキーを利用して行います。クッキーを利用したセッションの場合、お薦めする設定は以下の通りです。

  1. ドメイン名は指定しない
  2. パスはルート(/)を指定する
  3. セッション管理用のクッキーはセッションクッキー(有効期間0)にする
  4. httponly属性を付ける
  5. 可能な場合は必ずsecure属性をつける
  6. 複数アプリケーションを利用する場合はsession.nameまたはsession_name()でセッションクッキー名で指定する (アプリケーションの固有名デフォルトで設定し、設定項目として変更できるようにする)

3まではPHPデフォルト設定です。4から6までは自分で設定しなければなりません。PHPの場合、すべてphp.iniで指定できます。session_set_cookie_params()でセッション開始前に指定すればスクリプト中から変更できます。

1のドメイン名はわざわざ指定する意味はありません。デフォルト通り指定しない方が良いです。完全ではありませんが、ドメインを指定しない方が問題が少ないので指定しないようにします。

2のパスですが、アプリの中にはURIパスを検出してパスを設定してクッキーを送るようにしている物もあります。ルート(/)とサブディレクトリ(/app1/など)にクッキーが設定されている場合、ルートの方が優先されるので安全面を考えるとルートの方が良いです。

3は常識として知っておくべき知識です。クッキーの有効期限が0の場合、普通のブラウザはクッキーをメモリにみ保存します。つまりブラウザを終了させるとクッキーが消えます。セッション管理には必ず有効期限0を指定すべきです。

4のhttponlyはデフォルト有効でも良いような気がしますが、フレームワークでCSRF対策に使っている場合もあるかも知れません。しかし、 PHPアプリでJavascriptとセッションIDを使ったCSRF対策を行っているものは少数派だと思います。4は基本有効にする、という考え方で良 いと思います。

5はSSLをサポートしたサイトのみですが、最近のgoogleのように全てSSLにする場合は必須です。SSLしか使わないのであれば必ず有効にします。

6の代わりにクッキーにパスを設定するアプリもありますが、パスを設定するのではなく、セッション名を設定した方が良いです。

次はやってはならないことです。

  1. 有効期限の長いセッションを再ログイン用に使う
  2. Trans SIDを不要なのに有効にする

1はありがちな事です。有効期限の長いセッションによい事はありません。例えば、公共のPCや友人のPCを使った時にブラウザを閉じてもまだログインした状態が続くのは良くありません。自動ログインを有効にする場合は別の使い捨ての認証用クッキー(再認証用のトークン)を用い、ログインする場合に自動ログインするか、しないか選択できるようにしてユーザが制御できるようにします。ユーザが明示的にログオフした場合は再認証トークンも必ず無効にします。

2のTrans SID(URLの書き換えによるセッション)を絶対に利用してはならない、とは言いませんが特別な理由がない限り有効にしてはなりません。ページやURLをメールなどで送信するとセッションIDが漏洩します。

最後にセッションIDは少なくとも定期的にsession_regenerate_id()で更新すべきです。ログインした時の更新は必須です。

  1. ログインした時
  2. ログアウトした時 (これは必須ではないが念の為)
  3. 一定時間経過した時 (数分から数時間の間隔で更新)

Piece Framework にはリクエストのたびにセッションIDを更新する、という素晴らしい機能も付いています。万が一セッションIDが何らかの理由で漏洩しても、ユーザがアクセスさえしていればセッションIDが更新されているのでセッションを盗まれる事はありません。Trans SIDを利用していても比較的安全に利用できます。

PHPの設定を例に紹介しましたが、他のプラットフォームでも基本的には同じです。

Comments

comments

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です