セッションIDをURLへ含めていない状態とは？URLに入るリスク・Cookie専用化の設定・診断基準

セッションIDをURLへ含めていない状態とは

セッションIDをURLへ含めていないとは、ログイン状態を識別するセッションIDを、?PHPSESSID=… や ;jsessionid=… のようにURLの中に入れず、Cookieだけでやり取りしている状態のことです。

セッションIDは「ログイン済みの本人である」ことを示す合い鍵です。URLに入っていると、ブラウザ履歴、ブックマーク、アクセスログ、プロキシのログ、外部サイトへの Referer、SNSやメールでのURL共有などを通じて第三者に渡り、なりすましに使われます。IPAとOWASPはいずれも、セッションIDはCookieでやり取りし、URLに入れないことを求めています。

セキュリティAIチェッカーのこの項目は、診断対象のURL、リダイレクトの途中経路、巡回したページのURL、ページ内のリンクやフォーム送信先から抽出した同一オリジンのURLに、セッションIDと判断できる値が含まれていないかを確認します。

URLにセッションIDが入る典型パターン

PHPのマニュアルは、session.use_only_cookies の既定値が1（Cookieのみ）であり、URLにセッションIDを渡す攻撃を防ぐと説明しています。また session.use_trans_sid は既定で無効で、PHP 8.4ではこれを有効にすることが非推奨になりました。Microsoftの文書も、cookielessセッションのURLが検索エンジンやメールで共有されると、複数のブラウザで同じセッションが使われうると注意しています。

なぜセッションIDはURLではなくCookieで扱うべきなのか

Cookieは属性で守れ、履歴やログに残らない

Cookieは、次の属性で保護できます。

また、URLのように履歴・ログ・Refererへ自動的に残ることもありません。OWASP Session Management Cheat Sheetは、セッションIDの受け渡しをCookieに限定し、URLパラメータなど別経路で送られてきたIDを受け付けないことを、セッション固定攻撃への防御としても推奨しています。

標準・ガイドラインの要求

セッションIDとURLについてよくある誤解

• 「HTTPSならURLも暗号化されるから安全」：通信経路上では暗号化されますが、サーバーのアクセスログ、ブラウザ履歴、Referer、利用者による貼り付け共有では平文のまま残ります。
• 「ログイン前だけだから問題ない」：ログイン前に発行されたIDがログイン後もそのまま使われる実装では、URLで知られたIDを使ったセッション固定攻撃が成立します。ログイン成功時のID再発行（IPA 4-(iv)-a）とあわせて確認が必要です。
• 「sidという名前は全部セッションID」：sid はサイトID、セクションIDなど別の意味で使われることも多い名前です。本診断は値の形も見て判断します。

セッションIDをURLへ含めていないの診断基準（セキュリティAIチェッカー）

取得方法

次のURLを候補として集めます（3・4は同一オリジンのURLに限定し、外部サイトへのリンクは対象外。1のリダイレクト経路はオリジンを問わず含みます）。

1. 入力されたURLと最終到達URL、リダイレクトの途中URL。
2. 追加取得した下層ページ（最大2件）の最終URL。
3. トップページと下層ページのHTMLに含まれる <a>・<link>・<script>・<img>・<iframe> の href/src、<form action>、JavaScript内の location =・fetch()・axios.get/post() のURL。
4. V2診断の巡回ページ候補とAPI候補。

セッションIDを含むURLの判定条件

各URLについて次のいずれかに該当すれば「セッションIDを含むURL」と数えます。値そのものは画面・ログへ表示しません。

判定条件

• 汎用名に16文字以上の条件を付けているのは、?sid=12 のようなサイト・カテゴリ番号を誤ってセッションIDと判定しないためです。数字を含まない値（例：?sid=shisetsu-yoyaku-annai のような英字だけの識別名）も該当しません。PHPのセッションIDは22〜256文字（既定32文字）、ASP.NETのcookieless IDは24文字であり、実際のセッションIDはこの条件を満たします。
• 本診断は未ログイン状態での巡回です。ログイン後の画面だけでURLにIDを付ける実装は検出できないため、ログイン機能を持つシステムは手動確認が必要です。
• 機密パラメータ全般（パスワード、アクセストークン、APIキー等）のURL露出は、別項目「機密情報をURL・GETフォームへ含めない」で判定します。
• 証拠欄には、該当したURLの件数（値は非表示）または確認した候補URLの件数を表示します。

自治体サイトでの判定例

セッションIDがURLに含まれているとどんなリスクがあるか

• Refererによる外部流出：URLにIDを含むページから外部サイトへのリンクをクリックすると、Referer ヘッダーにID付きURLが入り、外部サイトのログに残る可能性があります（Referrer-Policy の既定値 strict-origin-when-cross-origin ではパスとクエリは送られませんが、古い設定やポリシー変更で送られる場合があります）。IPAもRefererによる送信を理由に挙げています。
• 共有・掲載による乗っ取り：利用者が「このページを見てください」とURLをメールやSNSに貼ると、受け取った人がそのままログイン状態になる場合があります。
• セッション固定攻撃：攻撃者が自分で取得したセッションID付きURLを被害者に踏ませ、被害者がログインした後に同じIDで操作する攻撃です。URLでIDを受け付ける実装で成立しやすくなります。
• ログからの漏えい：アクセスログ、プロキシ、アクセス解析ツール、検索エンジンのクロールにID付きURLが残り、運用者や委託先を含む広い範囲から参照可能になります。

セッションIDをURLから外す設定方法（PHP・Java・ASP.NET・Apache）

PHP（php.ini / .user.ini）

session.use_only_cookies = 1
session.use_trans_sid    = 0
session.use_strict_mode  = 1     ; 未知のIDを受け付けない
session.cookie_secure    = 1
session.cookie_httponly  = 1
session.cookie_samesite  = "Lax"

ログイン成功時には session_regenerate_id(true); を呼び、IDを再発行します。共有ホスティングでは .htaccess の php_value ではなく .user.ini に書いてください（mod_php以外では php_value が500エラーの原因になります）。

Java（Servlet 3.0以降の web.xml）

<session-config>
  <cookie-config>
    <http-only>true</http-only>
    <secure>true</secure>
  </cookie-config>
  <tracking-mode>COOKIE</tracking-mode>
</session-config>

tracking-mode を COOKIE のみにすると、;jsessionid= のURLリライトが行われなくなります。

ASP.NET（web.config）

<system.web>
  <sessionState cookieless="UseCookies" regenerateExpiredSessionId="true" />
  <authentication mode="Forms">
    <forms cookieless="UseCookies" requireSSL="true" />
  </authentication>
  <httpCookies httpOnlyCookies="true" requireSSL="true" />
</system.web>

Webサーバーでの暫定対処（Apache）

アプリを直ちに修正できない場合、ID付きURLへのGETアクセスを、PHPSESSID だけを除いた（他のパラメータは残した）URLへリダイレクトする方法があります。ただしCookieを受け付けない端末ではログインできなくなるため、影響範囲を確認してから適用してください。

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_METHOD} =GET
  RewriteCond %{QUERY_STRING} ^(.*&)?PHPSESSID=[^&]*&?(.*)$ [NC]
  RewriteRule ^ %{REQUEST_URI}?%1%2 [R=302,L,NE]
</IfModule>

段階的な手順

設定後の確認方法

# トップページ内のリンクにセッションIDらしきパラメータがないか
curl -s https://www.example.lg.jp/ | grep -ioE '(phpsessid|jsessionid|aspsessionid|session_?id)=[^"&<]*' | head

# リダイレクト経路のLocationを確認
curl -s -o /dev/null -D - https://www.example.lg.jp/shinsei/ | grep -i '^location'

# Cookieでセッションが発行されているか
curl -s -o /dev/null -D - https://www.example.lg.jp/yoyaku/ | grep -i '^set-cookie'

サイトを壊さないための注意点

• Cookie専用化により、Cookieを無効にした端末や一部の古い携帯端末ではログインできなくなります。利用者向けの案内（Cookieを有効にする手順）を用意してください。
• session.use_strict_mode の有効化は、セッション固定攻撃対策として推奨されますが、独自のセッションハンドラを使う実装では動作確認が必要です。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V14 Data Protection（14.2.1）
• IPA 安全なウェブサイトの作り方 1.4 セッション管理の不備
• OWASP Session Management Cheat Sheet
• OWASP WSTG Exposed Session Variables（WSTG-SESS-04）
• PHP Manual Session Runtime Configuration
• Microsoft Learn ASP.NET Session State Overview（Cookieless SessionIDs）

「セッションIDをURLへ含めていない」と関連する診断項目

• CookieのSecure属性high
• CookieのHttpOnly属性high
• CookieのSameSite属性medium
• 機密情報をURL・GETフォームへ含めないcritical
• SameSite=NoneとSecureの組み合わせhigh
• パスワードをPOSTで送信critical
• 機密ページのキャッシュ制御high
• Cookieの有効期間が過度に長くないmedium