はじめに
Webアプリケーションで、利用者が「パスワード変更」を行ったら、そのユーザのHTTPセッションをすべて破棄する。
という実装を一般的なWebアプリケーション・フレームワークではどのように実装するのかという点について考察した。
なぜこれが必要なのか
ユーザのHTTPセッションが、不正行為者にハイジャック(乗っ取り)されている場合、利用者はパスワード変更で不正行為者が乗っ取っているHTTPセッションを破棄することができる。
しかしながら、パスワードが漏洩している場合は、不正行為者が先にパスワード変更されると「おしまい(パスワード変更での2要素認証は必須)」だが、不正行為者よりも先にパスワード変更ができれば、不正行為をその時点までに止めることもできる。
(セッションハイジャックされた原因がそのままだと、再度ハイジャックされるかもしれないが・・・)
一般的なWebアプリケーションのHTTPセッション管理の仕組み
一般的には「セッションID方式」だと思う。
このセッションID方式によるHTTPセッション管理は、「セッションID」と呼ばれる一意で推測困難な値を、Webブラウザの(多くは)クッキーに埋め込み、その値を元にHTTPリクエストをどのHTTPセッションか認識する、というものである。
さらに、セッションIDごとにWebアプリケーション・サーバ側にメモリ(セッション変数/セッションオブジェクトと呼ばれる)が確保されて、データを保持することができる。
この方式の特徴としては、HTTPセッション間は独立であるので、「パスワード変更したユーザかどうか」を見極める仕組みがひつようとなる。
解決策
ログイン時にセッション変数/セッションオブジェクトに何かを記憶させておき、このセッションの年齢というか生存期間が判断できるようにする。
全てのHTTPアクセスのサーバ側の処理の一番最初で、この値をデータベース側の値と比較し、古ければ強制的にログアウトさせる。
(ログイン画面へリダイレクトさせる)
具体的解決策1
セッション変数に、パスワードの更新日時を保持し、その値とデータベース側の最新のパスワード更新時間を比較し、
過去のものであれば、セッションを破棄(ログアウト)し、ログイン画面へリダイレクトさせる。
具体的解決策2
セッション変数に、ログイン日時を保持し、その値とデータベース側の最新のパスワード更新時間を比較し、
過去のりものであれば、セッションを破棄(ログアウト)し、ログイン画面へリダイレクトさせる。
その他
他のやり方もあると思う。
そういうのはコメントに書いてほしい。