セッションID

セッションID（英:Session ID、別名:セッション識別子、セッションID）とは、計算機科学において、関連する情報交換の連続であるセッションを識別するために、ネットワーク通信（多くの場合HTTPS経由）で使用される識別子である。

主にHTTPプロトコルにおけるステートレスな通信を補うために用いられる。

概要例えば、販売者のウェブサイトを訪れた購入者が、仮想ショッピングカートに複数の商品を集め、サイトのチェックアウトページに進んで買い物を完了させたい場合がある。これには通常、クライアントから複数のウェブページが要求され、サーバーからクライアントに送り返される継続的な通信が含まれる。このような状況では、買い物客のカートの現在の状態を追跡することが不可欠であり、セッションIDはその目的を達成するための1つの方法である。

セッションIDは通常、訪問者が初めてサイトを訪れた際に付与され、Cookieなどを介してクライアントとサーバー間で受け渡しが行われる。ユーザーIDとは異なり、セッションは通常短命であり（数分から数時間など、あらかじめ設定された非アクティブな時間の後に期限切れになる）、特定の目標が達成された後には無効になる用に設計されることが推奨されている（例えば、購入者が注文を完了した後は、同じセッションIDを使用してさらに商品を追加することはできない）。

セッションIDは、ウェブサイトにログインしたユーザーを識別するために頻繁に使用されるため、攻撃者がセッションをハイジャックし、潜在的な権限を取得するために悪用される可能性がある。セッションIDは通常、総当たり攻撃によって有効なものを取得される確率を下げるために、ランダムに生成された文字列である。攻撃者がセッションIDを取得した場合に備えて、多くのサーバーはクライアントの追加検証を実行する。セッションIDをクライアントのIPアドレスに固定することは、攻撃者が同じアドレスからサーバーに接続できない限り、単純かつ効果的な対策である。しかし逆に、クライアントがサーバーへの複数のルート（冗長化されたインターネット接続など）を持ち、クライアントのIPアドレスがネットワークアドレス変換を受ける場合、クライアントにとって問題を引き起こす可能性がある。

一部のプログラミング言語がCookieを命名する際に使用する名前の例として、JSESSIONID（Java EE）、PHPSESSID（PHP）、およびASPSESSIONID（Microsoft ASP）などが挙げられる。

Cookieを利用したセッションIDの管理 HTTPプロトコル自体は過去のやり取りを記憶しないステートレスな仕様であるため、Cookieを介してセッションIDの受け渡しを行う。

セッションの開始: ユーザーがログインしたり、カートに商品を入れたりしたタイミングで、サーバーはランダムで一意なセッションIDを生成する。 Cookieの発行: サーバーはHTTPレスポンスヘッダのSet-Cookieを使用して、生成したセッションIDをブラウザに送信する。 Cookieの保存と自動送信: ブラウザはその情報をCookieとして保存し、それ以降同じドメインへリクエストを送るたびに、HTTPリクエストヘッダのCookieにセッションIDを含めて自動的に送信する。サーバー側での状態の紐付け: サーバーは送られてきたセッションIDを受け取り、サーバー内部に保存されているセッションデータと照合し、ユーザーを特定する。

セキュリティ対策セッションIDをCookieに保存する場合、セッションハイジャックを防ぐために、Cookieの発行時に以下の属性を付与することが現代の必須要件となっている。

HttpOnly属性 - クロスサイトスクリプティング攻撃への対策である。この属性をつけると、JavaScriptからそのCookieを読み取ることができなくなる。これにより、悪意のあるスクリプトがサイトに注入されても、セッションIDを盗み出されるリスクを大幅に減らすことができる。

Secure属性 - ネットワーク上での盗聴や中間者攻撃への対策である。この属性をつけると、HTTPS通信の時にのみCookieが送信されるようになる。平文のHTTP通信では送信されないため、ネットワーク経路でセッションIDが漏洩するのを防ぐ。

SameSite属性 - クロスサイトリクエストフォージェリ攻撃への対策である。サードパーティからのリクエストに対して、ブラウザがCookieを送信するかどうかを制御する。属性をStrictやLaxに設定することで、意図しない別サイトからのリクエストによるセッションの悪用を防ぐ。

また、かつては、ブラウザがCookieを無効にしている場合に備え、URLリライティングというURLの末尾にセッションIDを付与する手法が使われていた。しかし、URLを共有しただけでセッションが他人に渡ってしまう危険があるため、現在では深刻なセキュリティリスクと見なされている。

代替手段 CookieとセッションIDを用いた認証では、サーバーをスケールアウトした場合、ユーザーAのセッション情報をどのサーバーでも参照できる仕組みを別途構築する必要があり、インフラ構成が複雑になる。また、Cookieは原則として「発行元と同じドメイン」にしか送信されないため、異なるドメイン間で運用するCORS（クロスオリジンリソース共有）の壁が生じる。

これらを解決するために、シングルページアプリケーションやモバイルアプリのAPI通信では、CookieとセッションIDの代わりに、JSON Web Token（JWT）などのトークンベース認証が使われる。この場合、サーバーは状態を保持せず、暗号署名されたトークン自体にユーザー情報を含ませてやり取りする。トークンベース認証では、ステートレスではなく、有効期限が切れるまでクライアント側で独立して有効であるため、即時の権限変更や無効化が難しいというデメリットもある。

セッションID

Źródło i licencja