ログインしても「鍵」はそのまま？セッション固定化攻撃からWebアプリを守る基礎知識
こんにちは。セキュリティの世界で長く戦っていると、「完璧なシステムなんて存在しない」という現実に突き当たります。でもね、だからこそ「ここさえ押さえておけば、泥棒の侵入を劇的に難しくできる」というポイントがいくつか存在するんです。
今日は、Web開発の現場で意外と見落とされがちな「セッション固定化攻撃（Session Fixation）」について、家を例え話にしながらお話しします。新人エンジニアの方も、ぜひ「自分の家の鍵」を想像しながら読んでみてください。
—
1. セッション固定化攻撃って、どういうこと？
まずはイメージしてみましょう。あなたが家に帰ってきて、玄関の鍵を開けるとします。この「玄関の鍵」が、Webでいうところの「セッションID」です。
本来、ログインという行為は「あなたという本人であることを証明して、家の中に入る」ことですよね。ところが、もし泥棒が「あらかじめ用意しておいた合鍵」をあなたに渡して、その鍵を使って中に入らせたらどうなるでしょうか？
1. 罠を仕掛ける: 泥棒が適当なセッションID（合鍵）を生成し、リンクなどを通じてあなたに渡します。
2. ログインする: あなたはそのリンクをクリックし、ログイン画面へ行きます。
3. 鍵を使い回す: あなたがログインしても、サーバーが「さっき渡した鍵で入ってきたから、そのまま同じ鍵でいいや」と処理してしまったら、泥棒はあなたのログイン後の状態（中に入った状態）に、自分が持っている合鍵を使ってそのまま潜り込めてしまうんです。
これが「セッション固定化攻撃」の正体です。ログイン前後で鍵（ID）を取り替えないという、この小さな手抜きが、セキュリティの大きな穴になります。
—
2. どうすれば防げるの？「ログイン直後の再発行」が鉄則
対策は非常にシンプルです。「ログインが成功した瞬間に、古い鍵を捨てて、新しい鍵を渡す」。これだけです。
「ただいま！」と家に入った瞬間に、玄関の鍵穴ごと交換してしまうようなものですね。これなら、泥棒が持っていた古い合鍵はもう役に立ちません。
実装の勘所：フレームワークに頼るのが正解
多くのモダンなフレームワークには、これを自動的、あるいは簡単に実装するための機能が備わっています。自分で泥臭くIDを生成する必要はありません。
例えば、PHPの session_regenerate_id() 関数を使うのが定石です。
session_regenerate_id(true)の意味: このtrueは「古いセッションファイルを削除する」という重要な設定です。ここを忘れると、古い鍵が生き残ってしまうので注意してくださいね。
—
3. さらに守りを固めるために：HTTPヘッダーの活用
鍵を取り替えるだけでなく、鍵の管理自体を厳しくすることも重要です。ブラウザに対して「この鍵（Cookie）はこうやって扱ってね」と指示を出すHTTPヘッダーを適切に設定しましょう。
特に以下の設定は、現場での「必須項目」です。
HttpOnly属性:
JavaScriptからCookie（セッションID）を読み取れないようにします。もしサイトに脆弱性があって、攻撃者がスクリプトを埋め込んでも、鍵を盗み出すのを防ぎます。
Secure属性:
暗号化されたHTTPS通信でのみCookieを送信するようにします。盗聴を防ぐための基本です。
SameSite属性:
他のサイトからのリクエストでCookieが送信されるのを防ぎます（CSRF対策にも効いてきます）。
設定例（PHPの場合）:
// php.ini またはコード内で設定
session_set_cookie_params([
‘lifetime’ => 0,
‘path’ => ‘/’,
‘domain’ => ‘example.com’,
‘secure’ => true, // HTTPS必須
‘httponly’ => true, // JSからのアクセス禁止
‘samesite’ => ‘Lax’ // クロスサイトリクエストの制限
]);
—
最後に：セキュリティは「積み重ね」
「ログイン後にIDを再生成する」。たった一行のコードですが、これがあるかないかで、あなたのアプリの防御力は段違いに変わります。
セキュリティの仕事をしていると、完璧を目指して疲弊してしまう人をたくさん見てきました。でも、まずは「基本的な鍵の掛け方」を徹底すること。これが何よりも重要です。
これから開発を行う際は、「このログイン処理、鍵はちゃんと取り替えているかな？」と、一度立ち止まって確認してみてください。その小さな慎重さが、あなたのサービスとユーザーを守る最強の盾になります。
一歩ずつ、着実に。現場からは以上です！
コメント