情報処理安全確保支援士 2024年 秋期 午後 問04

解答の論理構成

1. セッションフィクセーション対策では、利用者が正しく認証された瞬間に新しいsessionIDを再発行（セッションIDの再生成）しないと、攻撃者があらかじめ設定したsessionIDがそのまま引き継がれてしまいます。
2. 図4「2.2.1　セッションフィクセーション」の(2)には、 　“aの画面遷移の際に実行されるコードにおいて、dすることを推奨する。”
   　とあり、dには“sessionIDを再生成する”旨が入ることが文脈から明らかです。
3. したがってaは「認証が完了する画面遷移」を指す必要があります。
4. 図3で認証が完了するのは、「01　ログイン」画面から「02　求人企業トップ」画面へ遷移するタイミングです。該当する矢印は
   　“ログイン（ボタン下部右）→（イ）→画面02へ”
   　と示されています。
5. 以上よりaに入るべき記号は“(イ)”となります。

誤りやすいポイント

• 「(ア)」は入力欄横の注記であり画面遷移ではない点を見落とす。
• 「(エ)」はログイン後のマイページ遷移で認証完了後なので対策ポイントではない。
• セッションフィクセーション＝ログイン画面と短絡し、「URL直接入力」や「(ア)」を選んでしまう。

FAQ

解答の論理構成

1. 図Aの手順2では「URL “b” にアクセスして、sessionIDを入手する。」と記載されています。
2. 攻撃者が sessionID を取得するために最初にアクセスする画面は、ログイン画面（画面01）であると読み取れます。
3. 表1には「01, 02｜https://test.△△△.jp/」とあり、画面01の URL が明示されています。
4. よって、図A中の b には表1で画面01に対応する URL「https://test.△△△.jp/」が入るのが妥当です。

誤りやすいポイント

• 画面03 以降のマイページ系 URL（/mypage など）を選んでしまう。図Aの手順2はログイン前のアクセスである点を見落とさないようにしましょう。
• 「https://test.△△△.jp/pwreset/…」のような一時 URL と混同する。PW再設定は図Dの後半で使われるもので、図Aの手順とは無関係です。
• 画面02（求人企業トップ）も同じルート URL であるため、「応募者確認」など機能名から URL を類推して誤解するケースがあります。

FAQ

解答の論理構成

1. 図Ａの手順を確認します。
   • 手順3では「手順2で入手したsessionIDを記述したフォーム」を作成し、ブラウザが読み込まれた直後にそのフォームを URL “b” に POST します。
   • 手順5で攻撃者はこの HTML へのリンクをメールで送信し、手順6で「メールがメール受信者に届き、罠サイトにアクセスするのを待つ」と記載されています。
2. 手順7の文脈を読み取ります。
   • 「罠サイトへのアクセスを検知後、cが完了することを期待して数分間待ち」とあるため、手順6の後に被害者が何らかの操作を行い、その完了を攻撃者が想定していることが分かります。
   • セッションフィクセーションでは、攻撃者が固定した sessionID を被害者が使用してログイン処理を実行することで、同じ sessionID を使って攻撃者が後から不正アクセスできます。
3. ログイン操作であることを裏付ける記述を引用します。
   • 2.2.1(1) の説明において「攻撃者が図Ａの手順でこの脆弱性を悪用すると、Mサイトに不正にログインすることができる」とあります。
   • したがって、手順7の前に完了していなければならない操作は「メール受信者（被害者）によるログイン」になります。
4. 以上より、c には「メール受信者によるログイン」と入るのが妥当です。

誤りやすいポイント

• 「フォーム送信＝ログイン完了」と早合点し、別の操作（例：応募ボタンのクリック）を書いてしまう。
• 被害者ではなく攻撃者側の行為を書いてしまい、視点が入れ替わる。
• 「セッションIDの固定」を中心に考えすぎ、ログインという基本操作を見落とす。

FAQ

解答の論理構成

1. セッション固定化の事実
   • 診断報告書には「Mサイトでは form 内の hidden フィールドである sessionID の値だけでセッション管理を実施していた」とあり、さらに表Bの 4 行すべてで が返却されています。
   • これは攻撃者が同じ sessionID を被害者に強制できる典型的なセッションフィクセーション状態です。
2. 攻撃シナリオの成立
   • 図Aの手順2〜7では攻撃者が sessionID を先に取得し、罠サイト経由で被害者にその ID を使わせたあと「URL “b” にアクセス」して不正ログインを達成しています。
   • したがって「ログイン前後で同じ sessionID が継続して使用される」ことが根本原因です。
3. 求められる対策の要件
   • セッションフィクセーションの基本対策は「ログイン完了時に新しいセッションへ乗り換える」ことです。
   • 旧 ID を残したままでは攻撃者が依然として利用できるため、旧 ID は破棄しなければなりません。
4. d が示すべき具体的操作
   • 上記要件を満たす操作は「使用済みの sessionID を無効にし、認証完了後に新しい sessionID を発行してクライアントに渡す」ことです。
   • これにより攻撃者が配布済みの ID を保持していても、それはサーバ側で失効しているため利用できません。
5. したがって、d に入る修正方法は
   「使用済みのsessionIDを無効にした上で、新しいsessionIDを発行」
   となります。

誤りやすいポイント

• 「ログイン前に乱数性の高い sessionID を発行すれば十分」と思い込む
  → 認証後に再生成しなければ固定化は防げません。
• CSRFトークン導入で解決できると誤解する
  → セッションフィクセーションは CSRF とは別問題です。
• 「sessionID をクッキーに入れれば安全」と短絡する
  → 旧 ID をクッキーで保持したままでは同じくフィクセーションが成立します。
• 「タイムアウトを短く設定すれば良い」と考える
  → 攻撃成立までに十分な時間があれば依然として危険です。

FAQ

解答の論理構成

• 【問題文】では、HTTPレスポンスに「Strict-Transport-Security」と「X-Content-Type-Options」が出力されていないことを指摘し、表Dで
  Strict-Transport-Security　　　｜e
  X-Content-Type-Options　　　　｜f
  と効果を尋ねています。
• ① Strict-Transport-Security
  • このヘッダーは HTTP Strict Transport Security（HSTS）を有効化し、ブラウザに対して「今後一定期間は同一ドメインへの通信を HTTPS に限定せよ」と指示します。
  • したがって e には “Mサイトへの接続をHTTPSに強制することができる” が入ります。
• ② X-Content-Type-Options
  • 通常は nosniff を指定し、ブラウザに「サーバが送った Content-Type 以外へ MIME タイプを推測変換（スニッフィング）してはならない」と命令します。
  • これによりスクリプトを意図せず実行されるリスクが低減するため、f には “Mサイトのコンテンツに対して、Content-Typeヘッダーで指定したMIMEタイプを強制的に適用することができる” が入ります。

誤りやすいポイント

• Strict-Transport-Security を「HTTPS へのリダイレクト」と誤認しがちですが、実際はブラウザ側の強制機構で HTTP アクセス自体を拒否します。
• X-Content-Type-Options の効果を「キャッシュ制御」と混同するケースがあります。nosniff は MIME タイプ固定化が目的でありキャッシュとは無関係です。
• 両ヘッダーはサーバ設定レベルで追加できるため、アプリ改修不要と勘違いして設定を怠りやすい点にも注意が必要です。

FAQ

解答の論理構成

1. 図4「図Ｄ」では、(1) で不正ログインした後に「不審なメールが求人企業に届かない」状態を作り出す必要があると書かれています。
2. メールを届かなくする手段として同図2.2.2「メールヘッダーインジェクション」で示された現象を再利用します。同節には
   ・「手順1：画面09の会社名に図Ｃの検査文字列を入力して変更ボタンをクリックする。」
   ・図Ｃ：『●●株式会社%0D%0ATo: abc@example.com%0D%0A%0D%0A』
   と明記されており、この操作でメール(あ)の宛先を任意アドレスへ変更できることが実証されています。したがって (2) は、同じ画面09・会社名欄を用いて攻撃者メールアドレスへ書き換える工程になります。これが解答 g の根拠です。
3. (3) でメールアドレス欄そのものを攻撃者アドレスに変更すると、以後のパスワード再設定メールが攻撃者へ届く仕組みが完成します。
4. (4) と (5) によりパスワードを奪取した攻撃者は、新パスワードでログインできますが、WebAPI の利用には APIkey が欠かせません。図3の求人企業マイページから
   ・「APIkey管理」→画面04
   ・画面05 又は 07 で「PW再確認」を要求
   するフローが定義されています。ここで再設定後のパスワードを入力すれば、既存キーの確認（画面06）あるいは新規発行（画面08）が可能になります。
5. よって (6) は「画面04を起点とした APIkey 確認／発行操作で再設定後 PW を入力する」工程が該当し、これが解答 h の根拠です。

誤りやすいポイント

• g を「メールアドレス欄の書換え」と誤解しやすいですが、メールヘッダーインジェクションは会社名欄を利用する点に注意が必要です。
• h におけるパスワード入力画面は 05 または 07 のどちらでも成立します。片方だけを記載すると減点の恐れがあります。
• APIkey 発行後に有効期間「14日間」があるため、発行直後でなくても悪用できることを見落としがちです。

FAQ

解答の論理構成

1. 図4「5章　参考意見」には、 　『WebAPIに関して、仕様の改善の方針案と改善すべき理由を表Fに示す』とあり、空欄 i と j に WebAPI 側の改善策・理由を入れる必要があります。
2. また同じ図4には、 　『Webアプリケーションプログラムの求人企業向け機能に関して、仕様の改善の方針案と改善すべき理由を表Gに示す』とあり、空欄 k と l に求人企業向け機能の改善策・理由を入れる必要があります。
3. 直前の「4章　総合評価」では、攻撃者が
   　『(6) h』『(7) WebAPIの機能を利用して、多数の求職者属性情報を窃取する』
   　と記されており、最終的な被害は WebAPI の濫用による大量情報窃取です。
4. この被害を根本的に封じるには、APIkey を奪われても「外部からは呼び出せない」状態を作ることが最も効果的です。図2「WebAPIの仕様」には利用企業が限定されたシステムである旨（『求人企業のうち、WebAPIの利用契約を締結済みの企業だけにAPIkeyを発行する』）が明記されており、実運用上も発信元ネットワークは特定しやすいと判断できます。
5. したがって WebAPI 改善策としては
   　i「WebAPI へのアクセス元 IP アドレスを限定する」
   　j「第三者による不正利用を防止できる」
   　が最も直接的かつ高い防御効果をもたらします。
6. 一方、求人企業向け機能では攻撃者がセッションフィクセーション→パスワード再設定という手順でアカウントを乗っ取っています。これを無力化する最強策は「パスワード以外の要素を要求する」ことです。多要素認証を導入すれば、パスワードが変更されても攻撃者は追加要素を満たせずログインできません。
7. 以上から、表G の最適解は
   　k「ログイン認証を多要素認証に変更する」
   　l「アカウント乗っ取りを防止できる」
   　となります。

誤りやすいポイント

• 求職者IDの難読化（模範解答①）は APIkey 奪取後の「日時範囲検索」で回避されるため防止効果は限定的です。
• メールヘッダーインジェクション対策だけを答えると、質問が求める「より多くの求職者属性情報の窃取」を直接防げず減点対象になります。
• 「IP 制限」と「多要素認証」を逆に配置すると設問のスコープ（WebAPI と求人企業向け機能）がずれてしまいます。

FAQ