玄関の鍵を使い回していませんか？「セッション固定化攻撃」からサービスを守るための処方箋
こんにちは。セキュリティの現場で長年戦っていると、「完璧なシステムなんて存在しない」という事実に直面します。でも、だからといって無防備でいいわけではありませんよね。
今日は、開発現場でつい見落とされがちな「セッション固定化攻撃」という脅威について、身近な例えを交えながら、どうすれば「鉄壁の守り」を作れるのか、一緒に紐解いていきましょう。
—
「セッション固定化」って、何が起きているの？
まずは想像してみてください。あなたがホテルのフロントでチェックインし、ルームキー（セッションID）を受け取ったとします。このキーがあれば、部屋に入ってくつろげますよね。
ところが、もし「誰か別の人が、あらかじめ細工したルームキーをあなたのカバンに忍び込ませていたら」どうなるでしょうか？
あなたがログインして「自分の部屋」に入った瞬間、その泥棒も同じキーを使って、あなたの部屋に堂々と入り込めてしまう。これが「セッション固定化」という攻撃の正体です。
なぜそんなことが起きるのか？
Webの世界では、ログインする前と後で「セッションID（＝ルームキー）」が変わらないと、攻撃者に「このIDを使ってログインしてね」とあらかじめ指定されてしまいます。攻撃者は、あなたがログインした瞬間にそのキーを乗っ取り、あなたになりすまして操作を開始するのです。
—
防御の基本：ログインしたら「鍵を交換する」
この攻撃を防ぐための鉄則は、たった一つ。「認証（ログイン）が成功した瞬間に、古いセッションIDを捨てて、新しいIDを発行する」ことです。
これを専門用語で「セッションIDの再生成」と呼びます。ログイン前後でIDが完全に別物になれば、攻撃者が事前に用意したキーはただのゴミになり、無効化されます。
コードで見てみましょう（PHPの例）
多くの現代的なフレームワークはこれを自動で行ってくれますが、もし自前で管理しているなら、ログイン処理の直後に必ずこう書くべきです。
// ログイン成功直後の処理
// セッションIDを新しく作り直して、古いデータを引き継ぐ
session_regenerate_id(true);
// ※引数の true は「古いセッションファイルを削除する」という重要な設定です。
// これを忘れると、攻撃者に隙を与えることになります。
—
さらに守りを固める「魔法のクッキー設定」
セッションIDを守るためには、IDを運ぶ「クッキー（Cookie）」の設定も非常に重要です。玄関の鍵を、誰にでも見えるように持ち歩いていたら危ないですよね。
以下の設定を、Webサーバーやアプリケーションのセッション設定で行ってください。
- HttpOnly属性: 「JavaScriptからこのクッキーを読み取れないようにする」設定です。万が一、XSS攻撃でサイトに悪意あるスクリプトを仕込まれても、セッションIDを盗まれるリスクを大幅に減らせます。
- Secure属性: 「HTTPS通信（暗号化された通信）でしかクッキーを送らない」設定です。平文のWi-Fiなどで盗み聞きされるのを防ぎます。
- SameSite属性: 「別のサイトからのリクエストでクッキーを送らない」設定です。CSRF（クロスサイトリクエストフォージェリ）対策としても極めて優秀です。
設定のイメージ（PHPのphp.ini設定例）
; クッキーのセキュリティ設定を強制する
session.cookie_httponly = 1 ; JavaScriptからのアクセスを禁止
session.cookie_secure = 1 ; HTTPS通信のみ許可
session.cookie_samesite = “Lax” ; 別のサイトからの攻撃をブロック
—
最後に：セキュリティは「泥臭い積み重ね」です
ここまで読み進めてくれたあなたは、もう「どうすれば攻撃者に侵入されるか」という視点を手に入れました。
セキュリティ対策は、一発で世界を救う魔法の杖があるわけではありません。「ログインしたら鍵を替える」「鍵にはしっかりカバーをかける（HttpOnly/Secure）」といった、地味で泥臭い対応の積み重ねが、結局のところ最強の防壁になるのです。
もし、今動いているサービスで「ログイン前後でIDが変わっているかな？」と不安に思ったら、ブラウザのデベロッパーツールを開いて、ログイン前後の「Cookie」の値を見比べてみてください。値がバシッと変わっていれば、あなたのサービスは一歩強くなっています。
一歩ずつ、着実に。一緒に安心できるWebの世界を作っていきましょう！
コメント