セッション管理とは？ハイジャックを防ぐCookie設定と実装の要点

セッション管理は、ログインした利用者をリクエストごとに識別する仕組みです。セッションIDを盗まれたり推測されたりすると、攻撃者はパスワードを知らなくても本人になりすませます。対策の要点は、推測できないIDを使い、Cookieの属性を正しく設定し、ログイン時にIDを作り直し、不要になったセッションをサーバー側で確実に無効化することです。

セッション管理とは

HTTPはリクエストごとに独立しているため、ログイン状態を続けるには利用者を識別する値が必要です。多くのWebアプリは、ログイン後にセッションIDを発行してCookieに保存し、以後のリクエストでその値を受け取ります。

OWASPは、認証済みのセッションIDは一時的に、そのアプリで使った最も強い認証方法と同等の値になると説明しています。多要素認証で守ったログインも、後からセッションIDを盗まれれば、その後の操作を乗っ取られるおそれがあります。ログイン自体の守り方は多要素認証の解説にまとめています。

主な攻撃：推測・盗用・固定化

IPAの「安全なウェブサイトの作り方」は、セッション・ハイジャックに至る手口を3つに分けています。

固定化は仕組みが少しわかりにくいので、流れで示します。

MITREのCWE-384も、既存のセッションIDを無効にしないまま利用者を認証することを、認証済みセッションを盗まれる機会を与える弱点として挙げています。

被害は、なりすましでできることすべてに及びます。IPAは、不正送金、意図しない購入や退会、パスワードなどの設定変更、非公開情報の閲覧を例に挙げています。

セッションIDの作り方

自分で作るより、フレームワークのセッション機能を使うのが基本です。IPAも、セッション管理機能を備えた製品を使えば、自前でIDを生成する必要はないと説明しています。使う製品の設定を確かめるときや、やむを得ず自前で作るときは、OWASPの次の基準を目安にします。

• 暗号論的に安全な疑似乱数生成器（CSPRNG）で作る
• IDに利用者名や権限など、意味のある情報を入れない
• PHPSESSID のように技術を推測させるCookie名は、一般的な名前に変える

なお、この64ビットは文字数ではなくランダムさの量です。一部が固定の値なら、その分だけ実際のエントロピーは減ります。

Cookieの属性を設定する

セッションIDはCookieで受け渡します。IPAは、URLパラメータに入れるとRefererから外部に漏れるおそれがあると説明しています。OWASPも、履歴やログへの漏えいに加えて固定化を容易にする点を挙げ、Cookie以外の方法で受け付けないよう勧めています。

Express（express-session）での設定例です。

import session from "express-session";

app.use(
  session({
    name: "__Host-id",
    secret: process.env.SESSION_SECRET,
    resave: false,
    saveUninitialized: false,
    cookie: {
      httpOnly: true,
      secure: true,
      sameSite: "strict",
      path: "/",
    },
  }),
);

ロードバランサーなどのプロキシでHTTPSを終端している場合は、Expressの trust proxy も設定します。設定がないと、secure: true のCookieが発行されません。

SameSite=Strict では、外部サイトのリンクから来たときにCookieが送られず、ログインしていない画面に見えることがあります。アプリの使い方に合わせて Lax と使い分けてください。SameSite はCSRF対策の補助で、トークンなどの代わりにはなりません。詳しくはCSRFの解説にまとめています。

localStorageにセッションIDを置かない

OWASPは、認証トークン、セッションID、JWT、リフレッシュトークンを localStorage や sessionStorage に保存しないよう求めています。同じオリジンで動くJavaScriptならどれでも読めるため、XSSが1件あるだけですべて漏えいするからです。代わりに、HttpOnly・Secure・SameSite=Strict のCookieか、BFF（Backend for Frontend）の構成を勧めています。

ログイン時にIDを作り直す

固定化を防ぐ基本は、ログインに成功した時点で新しいIDを発行し、古いIDを無効にすることです。IPAの根本的解決、OWASP Top 10:2025のA07も同じ対応を求めています。

app.post("/login", async (req, res, next) => {
  const user = await authenticate(req.body);
  if (!user) {
    return res.status(401).send("ログインできませんでした");
  }

  req.session.regenerate((regenerateError) => {
    if (regenerateError) return next(regenerateError);

    req.session.userId = user.id;
    req.session.save((saveError) => {
      if (saveError) return next(saveError);
      res.redirect("/");
    });
  });
});

OWASPは、ログインのほかにも、パスワードの変更、権限の変更、管理者への切り替えなど、権限が変わる場面でIDを作り直すよう求めています。アプリが発行していないIDを受け取ったときは、そのまま受け入れないようにします。

有効期限とログアウトをサーバー側で処理する

OWASPは、期限切れの判定をサーバー側で行うよう求めています。クライアント側だけで管理すると、値を書き換えられて期限を延ばされるおそれがあるからです。

この数字は目安です。OWASPも、アプリとデータの重要度に応じて決めるものとしています。

ログアウトでは、次の順に処理します。

1. サーバー側のセッションを破棄する

   ブラウザのCookieを消すだけでは足りません。盗まれた値が使えないよう、サーバー側で無効にします。

2. Cookieを削除する

   発行時と同じ属性を指定して消します。

3. 機密ページをキャッシュさせない

   機密情報を含むページには Cache-Control: no-store を付けます。OWASPは、ログアウト時に Clear-Site-Data で閲覧データを消す方法も挙げています。

app.post("/logout", (req, res, next) => {
  req.session.destroy((destroyError) => {
    if (destroyError) return next(destroyError);

    res.clearCookie("__Host-id", {
      httpOnly: true,
      secure: true,
      sameSite: "strict",
      path: "/",
    });
    res.redirect("/login");
  });
});

SSOを使っている場合、OWASP Top 10:2025のA07は、関連するアプリも含めて終了させるシングルログアウトの重要性を挙げています。

ログと監視

セッションの作成、更新、破棄、ログイン、ログアウト、権限の変更、タイムアウトを記録します。OWASPは、セッションIDそのものをログに残さず、相関を取りたいならソルト付きハッシュを使うよう勧めています。ログが漏れると、そのままなりすましに使われるおそれがあるからです。

よくある質問