セッションcookieとは？ログイン状態を維持する仕組み

セッションcookieとは、リクエストをまたいでログイン済みのユーザーを識別するためにbrowserに保存される小さな値であり、これによりページごとに再認証する必要がなくなります。

セッションcookieは、Webアプリを操作している間あなたのログイン状態を維持するものです。認証後、サーバーはcookieに保存されるセッション識別子を発行し、browserは各リクエストとともにそれを送信するため、サーバーはあなたが誰であるかを把握できます。そのcookieが実質的にあなたのセッションそのものであるため、それを保護することはWebセキュリティの中心であり、チームが使うdashboardについても同様です。

セッションcookieの仕組み

ログイン時、サーバーはセッションを作成し、cookieに識別子を返します。browserはそのcookieをサイトへの以降のすべてのリクエストに付加します。サーバーはセッションを参照し、そのリクエストを認証済みとして扱うため、再ログインは不要です。

cookieの保護

HttpOnly: JavaScriptがcookieを読み取るのをブロックし、XSSによる盗難を制限します。
Secure: cookieをHTTPS経由でのみ送信します。
SameSite: cross-siteでの送信を制限し、CSRFのリスクを低減します。

なぜ盗難が危険なのか

有効なセッションcookieを持つ者は、実質的にそのユーザーとしてログインしていることになります。cross-site scriptingや安全でない接続を通じてそれを盗むと、攻撃者は被害者になりすますことができます。だからこそ、上記の保護フラグが不可欠なのです。

セッションの有効期間とローテーション

セッションは、非アクティブ状態が続いたら失効し、ログアウト時に無効化されるべきです。ログイン後（および権限変更時）にセッション識別子をローテーションすることで、攻撃者が被害者の認証前に既知のsession IDを仕込む固定化攻撃を防ぎます。

セッションcookieとCI/CD

Webアプリを構築するなら、正しいcookieフラグとセッションの取り扱いは安全なコーディングの一部です。CIのセキュリティチェックやレビューは、HttpOnly、Secure、SameSiteが設定されていることを確認すべきです。フラグの欠落は、簡単で一般的な脆弱性だからです。

cookieとtoken

セッションcookieは、人間によるbrowserベースのセッションを扱います。これは、pipelineがマシン間アクセスに使うbearer tokenとは別物です。セッションcookieはbrowser内の人のためのもので、access tokenはAPIを呼び出す自動化のためのものです。

重要なポイント

セッションcookieは、browser内でリクエストをまたいでログイン済みのユーザーを識別します。
HttpOnly、Secure、SameSiteフラグは、盗難やcross-siteの悪用を防ぎます。
セッションは有効期限で失効し、ログイン時にローテーションし、ログアウト時に無効化されるべきです。