2010-09-16(木) [長年日記]
■ セッションの「適切な制限時間」というものはあるのだろうか?
先月公示になった新しいWebアクセシビリティに関するJIS X8341-3には「調整可能な制限時間」という達成基準があって(JISは非公開なので互換性のあるWGAC2.0 Understandingの邦訳を貼っておく)、非常におおざっぱにまとめると:
制限時間のあるコンテンツでは、
- 利用者が制限を解除できるか
- もしくは10倍に延長できるか
- さもなくば最初から20時間以上に設定
せよ。
というものだ*1。
制限時間つき入力フォームを持つようなWebサイトが、これを受けてJIS適合を目指そうと思ったら、制限解除ないし延長の仕組みを作らなければならない。20時間なんて長すぎてセキュリティ的に論外だ。なんだか不条理な基準だよなぁ。
……と思っていたのだが、よくよく考えると、そもそもいま設けている制限時間には、はたして明確な理由があるのだろうか。いろいろ調べてみても、セッション・ハイジャックを防止するためにセッションの持続時間は適切な長さにしましょうという記述は見かけても、「適切」について述べられた資料は見つけられなかった。セッションID生成にまともなハッシュ関数を使っていればブルートフォースアタックの危険は考えなくていいし(少なくとも20時間あれば十分だ)、その他のアタックに対しては時間よりも別の要因の方が大きいだろう。
Twitterでこの疑問を漏らしてみたけど、反応はいっさいなかったので(followerにはWeb業界人が多いはずなのだが)、おそらくみんな「適切」じゃなくて「適当」に決めてるんじゃないかなーと思う。だったら、JIS適合しようとするならプログラムや設定ファイルに書かれている「1」(時間)を単純に「20」に書き換えるだけで対応完了じゃん。それで何か問題ある?*2
上記はフォームへの入力のような場面を想定したものだけど、他にもWeb上における制限時間的なものといえばログイン・セッションもやはり不可解なものが多い。一定時間ログインしないと切れるというのがメジャーな方式だが、他にもセッション数を制限したり(ニコ動は1セッション*3、Wassrは3セッション?)色々あるが、その制限にちゃんとした根拠があるのかなぁ、といつも不思議に思う。
一方でAmazonやTwitterのようにひとたびログインすればずっとセッションが維持されるサービスもあって、こういうところは大事なとき(商品の購入や個人情報の参照・変更)だけ再度パスワードの入力を求められる。個人的にはこの方式の方が他に比べてユーザビリティも高く、おまけにフィッシングの危険性も低下するのでセキュリティ的にもいいと思うんだけど。なんでいつまでも安直な制限時間方式が蔓延してるんだろうね。
> 複数アカウントを取れば回避できるのであんまり意味がない
無料アカウントならそのとおりなのですが、プレミアムアカウントを複数人で流用されたりすると困るので、単純に、1セッションのみにしているのだと推測しています。
ログインセッションならアカウント数で上限が決まりますが、トランジェントなセッション (e.g. ログイン無しでステートフルな遷移を持たせる) の場合上限が青天井なので、メモリ消費量との兼ね合いでタイムアウトを決めることはあります。
まあ、一見ユーザが多いところでトランジェントなセッションをばかすか作るっていうのは悪いエンジニアリングではあるんですが、継続ベースのwebアプリだと素直に書いてるとトランジェントなセッション相当のものがどんどん出来てしまうんですね…
> yasuyuki
セッション制限ってプレミアム導入してからだっけ? いずれにしてもその懸念は他の有料サービスにも言えるものだからなぁ。
> shiro
そ、それは特定プログラミング言語ゆえの……(笑)。でもまぁ、(設計の良し悪しは別にして)リソースの上限という問題はたしかにありますね、失念してました。ただ、それでも24Hくらいはキープするものだとは思いますが。
一般的なWebサイトではなくイントラの業務システムでの経験なので,ちょっとずれてコメントかもしれませんが,セッションタイムアウトの時間をどうするかというのは,そのシステムでユーザーがどこまで許容するか,という部分で決まっていました.
結局,適切な時間はユーザーの要件にあわせて「適当」に決められるので,適切な時間がどのくらいなのかは,明確にはなっていないんでしょうかね.
特に要件がなければ,採用するミドルウェアのデフォルト値が基準になっていたように思いますし…
ミドルウェアのデフォルト値! それは実にありそうですw
ちなみにアクセシビリティにイントラかどうかは(本質的には)無関係です。