ログイン機能の落とし穴：セッション管理

レン

ログイン機能って、パスワードが合ってたら通せばいいんだよね？

プロクラ

そこは入口だけの話だよ。難しいのはその後、「この人はさっきログインした人だ」とページを移動しても分かり続ける仕組みのほうなんだ。これをセッション管理と言う。

仕組み

プロクラ

ログインに成功したら、サーバーが推測できない長いランダムな文字列を発行して、利用者のブラウザに預ける。以降はそれを見せてもらうことで本人だと判断するんだ。いわば入場券だね。

ウィルスン

つまり、その入場券さえ手に入れば、ワタシはパスワードを知らずともキミになりすませる。だから狙うのはパスワードではなく、この券のほうだ。

やりがちな失敗

• 推測できる値を使う（連番、ユーザーIDそのもの、時刻など）
• HTTPSにしていない（通信を覗かれれば券が丸見えになる）
• CookieにHttpOnly属性を付けない（XSSでプログラムから読み取られてしまう）
• Secure属性を付けない（暗号化されていない通信でも送られてしまう）
• ログアウトしてもサーバー側で無効化しない（券が生き続ける）
• 有効期限が無い、または長すぎる

Cookieに付ける属性の意味

プロクラ

属性は暗号のように見えるけれど、やっていることは単純だよ。それぞれ、券が漏れる経路を1つずつ塞いでいるんだ。

• HttpOnly: ページ上のプログラムから読めなくする。XSSで盗まれる経路を塞ぐ
• Secure: 暗号化された通信でしか送らない。盗聴される経路を塞ぐ
• SameSite: 他所のサイトからの要求では送らない。勝手に操作される経路を塞ぐ
• 有効期限: 券の寿命を決める。漏れたときの被害の長さが変わる

ログアウトで何をするか

プロクラ

ブラウザ側のCookieを消すだけでは足りないんだ。券そのものはサーバー側でも無効にしないと、コピーを持っている相手はまだ入れてしまう。

• サーバー側でその券を無効にする
• パスワードを変更したときは、他の端末の券もすべて無効にする
• ログイン直後に券を新しいものに切り替える（事前に仕込まれた券を無効化するため）
• 権限が変わったときも、券を作り直す

ウィルスン

…パスワードを変えられても、ワタシが先に手に入れた券が生きているなら、居座り続けられるということだ。そこまで気が回る者は、正直あまり多くない。

自作しないのが最善

レン

けっこう項目が多い…全部自分で作るの大変そう。

プロクラ

だから認証は自作しないのが基本だよ。フレームワーク標準の仕組みか、実績ある認証ライブラリ・サービスを使おう。ここは「車輪の再発明」が最も損をする領域なんだ。落とし穴が多すぎて、自作で全部埋めるのは現実的じゃない。

• 標準の仕組みは、ここに挙げた落とし穴を最初から塞いである
• 弱点が見つかったときも、更新を当てれば直る
• 外部の認証サービスを使えば、パスワードを自分で持たなくて済む
• 持たない情報は漏れない。これが一番強い

プロクラ

それでもパスワードを自分で保存するなら、必ずこの用途に作られた方式でハッシュ化してね。そのまま保存するのは論外だし、単純なハッシュも不十分。ここも自作せず、用意されている仕組みを使うのが正解だよ。

レン

狙われるのはパスワードじゃなくて入場券のほう。ログアウトはサーバー側で無効化。自作しない。