午前I問題

Webアプリケーションのセッション管理に関する記述のうち、適切なものはどれか。

ア）セッションIDはURLパラメータに埋め込むことで、Cookieが使えない環境でも安全にセッションを維持できる　イ）ログアウト処理では、サーバ側のセッションを無効化するだけでなく、クライアント側のセッションCookieも削除することが望ましい　ウ）セッションタイムアウトは、ユーザーの利便性を優先し可能な限り長く設定すべきである　エ）セッション固定化攻撃（Session Fixation）は、ログイン後にセッションIDを再発行することで防御が困難になる

午前I の解答・解説を見る

正解： イ

解説：

  • ア）不正解。セッションIDをURLパラメータに含めると、リファラヘッダーやブラウザ履歴、プロキシログなどを通じて漏洩するリスクが高く、Cookie（HttpOnly・Secure属性付き）での管理が推奨されます。
  • イ）正解。安全なログアウト処理では、サーバ側でセッションを破棄（無効化）するだけでなく、クライアント側に残るセッションCookieも削除（有効期限を過去に設定する等）することで、Cookieの再利用によるセッションハイジャックを防ぎます。
  • ウ）不正解。セッションタイムアウトは長すぎると、離席時や端末盗難時にセッションが悪用されるリスクが高まります。利便性とのバランスを取りつつ、機密度に応じた適切な（短めの）タイムアウトを設定すべきです。
  • エ）不正解。セッション固定化攻撃は、攻撃者が事前に取得したセッションIDを被害者に使わせ、ログイン後もそのIDが有効なままであることを悪用する攻撃です。ログイン成功時にセッションIDを再発行（再生成）することは、この攻撃に対する標準的な防御策です。

午前II問題

SAML/OpenID ConnectにおけるSingle Logout（SLO）に関する記述のうち、最も適切なものはどれか。

ア）SLOは、IdP（Identity Provider）とSP（Service Provider）間でセッションを同期させる仕組みであり、いずれか1つのSPでログアウトすれば、IdPおよび他の全SPのセッションも自動的かつ確実に終了することが仕様上保証されている　イ）front-channel logoutは、ブラウザのリダイレクトやiframeを利用して各SPにログアウト要求を伝搬させる方式であり、ブラウザがブロックしたり一部SPへの到達に失敗したりすると、ログアウトが不完全に終わる可能性がある　ウ）back-channel logoutは、IdPとSP間のサーバ間直接通信を必要とせず、ブラウザ経由でのみログアウト通知を行う方式である　エ）SLOを実装していないSPが存在する場合でも、IdP側のセッションを終了すれば、当該SPで発行済みのアクセストークンやセッションは即座に自動的に無効化される

午前II の解答・解説を見る

正解： イ

解説：

  • ア）不正解。SLOは仕様として複数SPへのログアウト伝搬を「試みる」仕組みですが、ネットワーク不安定・ブラウザのポップアップブロック・SP側の未実装などにより、全SPでのログアウトが確実に完了する保証はありません。これがSLO実装の根本的な難しさです。
  • イ）正解。front-channel logoutはブラウザを経由してリダイレクトやiframe読み込みでSPにログアウト要求を伝える方式です。ブラウザのサードパーティCookie制限やポップアップブロッカー、iframe内リクエストの失敗などにより、一部SPへのログアウト通知が届かず、セッションが残存する可能性があります。
  • ウ）不正解。back-channel logoutはIdPとSPのサーバ同士が直接（ブラウザを介さず）通信してログアウトを通知する方式です。ブラウザに依存しないため、front-channelより確実性が高いとされます。設問の記述は逆になっています。
  • エ）不正解。IdP側でセッションを終了しても、SP側でSLOの通知処理が実装されていなければ、SP自身が発行・管理するセッションやアクセストークンは自動的には無効化されません。SP側での明示的なログアウト処理実装が必要です。

午後問題

D社は、社内の複数SaaS（勤怠管理、経費精算、社内Wiki）に対してSAML方式のSSOを導入している。IdPにはOktaを利用し、各SPはOktaとのSAMLフェデレーションを設定済みである。

先日、退職者が私用の共有PC（社内の会議室に設置）でログインしたまま退職したことが判明した。情報システム部門がOkta管理画面から当該ユーザーのセッションを強制終了させたが、後日、経費精算SaaSでは当該ユーザーのセッションが依然として有効であり、閲覧が可能な状態であったことが発覚した。調査の結果、経費精算SaaSはSAML SLOのback-channel logoutに対応しておらず、front-channel logoutのみをサポートしていることが判明した。さらに、共有PCのブラウザではポップアップブロッカーが有効になっており、SLOのリダイレクトが正常に完了していなかったことも分かった。

設問1

本事例において経費精算SaaSのセッションが残存してしまった技術的な原因を、front-channel logoutの仕組みに触れて説明しなさい。（150字程度）

設問1の解答・解説を見る

正解例： front-channel logoutはブラウザのリダイレクトやiframeを介してIdPから各SPへログアウト要求を伝搬する方式であり、ブラウザの状態（ポップアップブロック等）に依存する。本事例では共有PCのポップアップブロッカーによりSLOのリダイレクトが完了せず、経費精算SaaS側にログアウト通知が届かなかったため、SP側のセッションが有効なまま残存した。

解説・採点基準（計15点）：

採点項目キーワード配点
front-channel logoutの仕組みの説明ブラウザリダイレクト/iframe依存6点
本事例での失敗要因の特定ポップアップブロッカーによる通知未達6点
結果の記述SP側セッション残存3点

部分点： 仕組みの説明のみで事例と結びつけていない場合は9点まで。

設問2

同様の事案の再発を防止するために、情報システム部門が講じるべき対策を2つ提案しなさい。（150字程度）

設問2の解答・解説を見る

正解例： 1つ目は、経費精算SaaSベンダーに対しback-channel logout（サーバ間直接通信によるSLO）への対応を要請し、front-channelの信頼性リスクを解消する。2つ目は、SLOに依存せず、共有PCなど共用端末でのセッションタイムアウトを短く設定する、またはIdP側でユーザーの全アクティブセッション一覧を確認・個別強制終了できる運用手順を整備する多層的な対策を講じる。

解説・採点基準（計15点）：

採点項目キーワード配点
back-channel logout対応の要請サーバ間通信・確実性向上6点
SLOに依存しない補完策セッションタイムアウト短縮・共用端末運用ルール・個別セッション確認のいずれか6点
多層防御の視点SLOの限界を前提とした運用対策3点

部分点： 対策を1つのみ提案→8点。

重要キーワード

用語説明
SAML/SSOXMLベースのフェデレーション認証プロトコル。IdPとSP間でアサーションを交換しシングルサインオンを実現する
Single Logout（SLO）1箇所でのログアウト操作を、フェデレーション先の複数SPへ伝搬させる仕組み。SAMLとOIDC双方に規定がある
front-channel logoutブラウザのリダイレクトやiframeを介してログアウト要求をSPへ伝える方式。実装は容易だがブラウザ環境に依存し確実性が低い
back-channel logoutIdPとSPがサーバ間で直接通信してログアウトを通知する方式。ブラウザに依存せず確実性が高いが、SP側の対応実装が必要
セッション固定化攻撃（Session Fixation）攻撃者が事前に取得したセッションIDを被害者に使わせ、ログイン後もそのIDを乗っ取る攻撃。ログイン時のセッションID再発行で防御する
OAuth2 / OIDCOIDCではRP-Initiated LogoutやBack-Channel Logoutといった仕様でSLOに相当する機能が定義されている

まとめ

  • 午前I視点： ログアウト処理はサーバ側セッション破棄とクライアント側Cookie削除の両方が必要という基本原則、セッション固定化攻撃への対策（ID再発行）が頻出。
  • 午前II視点： SLOはfront-channelとback-channelで確実性が大きく異なり、front-channelはブラウザ環境に左右される「保証のない伝搬」である点が試験の急所。
  • 午後視点： SLOが完全に機能しないことを前提に、SPごとのSLO対応状況の把握、共用端末運用ルール、IdP側での能動的なセッション管理といった多層防御を提案できるかが採点ポイント。