2013/02/18(月)月曜日ー。（Ｏ垣さんを一本釣りするネタかと思った、、ｗ）

[セキュリティ] ログアウト時にセッションIDのCookieを破棄する必要はあるか？について徳丸さんのブログ（『* ログアウト機能の目的と実現方法

ログアウト機能の目的と実現方法

このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。議論の前提このエントリでは、認証方式として、いわゆるフォーム認証を前提として

http://blog.tokumaru.org

』）に、気になる箇所があったので。。まず、徳丸さんのブログの記事で挙げられている、Cookieを用いた認証状態保持の場合は、ログイン状態を「そのまま」Cookieに保持するのではなく、セッション変数を使うべきという点、ログアウト時にはセッションIDのCookieを消すだけでなく、サーバ側のセッション破棄をおこなうことが重要であるという点には完全に同意します。その上で、気になったのは以下の箇所です。

textile**セッションIDのCookieを破棄する必要はあるか**…しかし、私は、セッションIDのクッキー（PHPのデフォルトはPHPSESSID）は削除する必要はないと考えます。その理由は、セッションが破棄された状態では、セッションIDは単なる乱数であり、攻撃の余地はないからです。

徳丸さんは、「セッションIDのクッキーは削除する必要はない」と言い切っておられますが、私は、削除したほうが良いのでは？と思います。例示されているPHPの場合は特に。・・・と言いますのも、ログアウトした後に必ずブラウザを閉じるわけではないと思うからです。ログアウト後に、ブラウザを閉じずに、またその同じサイトを散策することもままありますよね。そして、そのうちにセッションを使う箇所に再び差し掛かったときに、セッションIDのCookieを破棄していないままですと、【PHPにはセッションアダプションの問題がありますので、】前と同じセッションIDを使いまわしてしまいます。徳丸さんが例示したホテルのカードキーで考えますと、一度無効になったチェックアウト済みのカードキーが、次のチェックインでまた使えるようになってしまうイメージでしょうか。ログアウト済みのセッションIDを取得される機会なんてあるか？など考え始めると、問題が発生するのはレアケースになるわけですが、ただ、ログアウトという行為に期待する、セッションの完全な破棄という意味では、Cookieが破棄されないと片手落ちに近い状況と言えるのではないでしょうか。（レアケースを強いて挙げれば、『仮に通信路上でセッションIDが盗聴された場合でも、ログアウトしてしまえば、それ以降の悪用を避けることができます。』という期待がある中で、一過性の盗聴で、再ログイン後は盗聴していなかったケースなどでも、この機能を果たせなくなることなどが考えられます。）もちろん、セッションフィクセイション対策で、ログインなどでセッションIDの更新をしていれば問題はさらに低減できるでしょうが、例えば、ショッピングカート周りの動作など、ログイン前の部分への影響が無いとは言い切れませんので。次に気になったのは、BASIC認証にログアウト機能が無いことを受けて、“我々は「ログアウト機能のない世界」を知っており、一応それを受け入れていることになります。”としている点です。奇しくも徳丸さんが次の段落で検討されているように、BASIC認証については、「ブラウザを閉じる」ことで利用者側が明示的に認証状態を破棄する手段（≒ログアウト）があります。それに比べて、フォーム認証でサーバ側のセッション破棄がおこなわれない状況では（有効期限が切れるのを待つ以外の）対処のしようが無いわけですので、これらを同じ土俵に並べるのは少し違うのでは？と思ってしまいます。[雑談] いろいろ。