大体・・・復活。あと、CookieのSessionを使った認証について覚え書き。

お腹の調子も、回復傾向。もとより喉には症状が出ない体質である為、端から見れば仮病にしか見えない程度のだるさ加減。
そんでもって、そんなわけなので、なんの因果かこれから某PRJの緊急のお手伝いに出掛けなければなりませぬ。一日だけのお手伝い。むぅぇ〜〜〜。

それはそれで、CookieのSessionを使った認証で、ずっとこう、CSRFやらHeaderInjectionやら\0攻撃やらばっかりうだうだ構ってたおかげで、普通に重要な

• User Agentの一致チェック
• IPAddressの一致チェック

とかを「考慮してなかった」。実装する・しないの俎上にすら載せていなかった。アホかと。馬鹿かと。

重要なのは、cookieを使ってsession(厳密には疑似セッション)を実装するにあたっては、cookieのみを同一セッションか否かの判断材料としてはいけないということ。さもなければsession IDをコピーするだけでセッションそのものをコピーできてしまう。そしてcookieを奪うのがどれほど簡単かというのは、CSRFの事例が後をたたないことからも伺い知ることができる。

Immortal Session の恐怖

結論から言うと、User Agentの一致、IPAddressの一致は「必要」なので将来必ず入れることになるだろう。
ただしそれは、一人のユーザーが一度に一つのHTTP_Clientしか利用できないような制限としては実装しない。
一人のユーザーは複数のHTTP_Clientを用いて同時にログインできる。例えばPCのブラウザA, ブラウザB, 携帯電話のブラウザCというように。User-Agent, IPAddressの一致は、それぞれで発行されたSessionがそれぞれのHTTP_Clientから送信されているかの妥当性チェックの一助になる。
で、UNIXでいうところの「w」「who」コマンドのように、「現在自分がログイン中のセッションはどれか」を確認し、なおかつ見たこともないような、使ったこともないようなUserAgent, IPAddressからログインしているセッションがある場合は、それを強制削除することも可能にする。

まぁ、これくらいあれば大丈夫なんじゃないかなぁ？いろんな人から怒られそうだけど、それでも、極論を推し進めていって仕舞うと例えば平文HTTPを丸ごとごっそり盗聴されていたりとか、クライアントにkeylogger仕込まれてたりすればもう、一般的なCSRF対策や何なりを飛び越えて普通に入れちゃうわけで。
なんだか情けないけれど、入られても検出できるような仕組みが欲しかったりするのよ。
まぁYakiBikiの場合、記事が作成・更新かけられれば普通にリストのトップに上がるし、本体データであればdiffとれるし。ACL弄られたら厭だけれど。

うーん、考えると頭痛がしてきそうなのでこの辺でstop.