情報処理安全確保支援士 2017年 春期 午後1 問02

解答の論理構成

1. 問題文には、L氏が「“今朝9時にログインし、サイトαを利用していたら、10時に急にログアウトさせられ”」と連絡してきたとあります。
2. その後の下線①では「Xさんは、L氏に詳細な利用状況を確認し、その確認内容とログイン記録を照合した」と記載されています。
3. 何を照合したのかを考えると、攻撃者が別時間帯に不正ログインしていないかを判断する必要があります。
4. “詳細な利用状況”として最も確実に本人に確認できるのは「本人が自覚している今日のログイン回数」です。
5. 一方、システム側で取得している情報は表1（あ）の「“ログイン記録（利用者IDと時刻）が取得される”」という仕様により「利用者IDごとのログイン回数」を把握できます。
6. よって、 ・L氏から聞き取る値：「L氏が今日ログインしたと言っている回数」
   ・ログイン記録から抽出する値：「L氏の利用者IDを用いた今日のログイン回数」
   の一致を確認できれば、不正ログイン（＝本人が知らない追加ログイン）がなかったと判断できます。

誤りやすいポイント

• 「ログインした時刻そのもの」を照合すると考えがちですが、時刻は複数回のアクセスで増えるため、回数のほうが適切です。
• 「IPアドレス」を比較すると答えたくなりますが、利用者が自宅・職場・モバイルなど複数環境を使う場合があり確証になりません。
• 「ログアウト時刻」を照合するという発想もありますが、システムはログアウト失敗やセッションタイムアウトでも記録が残るため誤判定を招きます。

FAQ

解答の論理構成

1. 【問題文】には脆弱性1を確認した手順として、表2の項番「3」で
   “action_id=submit” だけを送信すると “退会完了” が表示されると示されています。
   これは「taikai_token」を送らなくても処理が実行される実装不備を意味します。
2. さらに K 氏は
   “プロフィール確認画面についても脆弱性1が確認されています”
   と述べ、フォームを自動送信する図2の HTML 例を示しています。
   図2は <form target="ifrm1" …> →
   のように、利用者がリンクを踏むだけで意図しない POST を別ドメインへ送ります。
3. リンクをクリックしただけで「退会処理」が実行される点は、利用者のセッションを悪用して不正なリクエストを発生させる攻撃であり、 “利用者が入力操作をしなくてもブラウザが勝手にログイン済みサイトへリクエストを送る”
   という特徴を持つことから、これは「クロスサイトリクエストフォージェリ」と一致します。
4. 以上より、a に入る脆弱性名は
   クロスサイトリクエストフォージェリ
   となります。

誤りやすいポイント

• 「トークンがある＝対策済み」と早合点し、実装不備による検証漏れを見逃す。
• 図2の HTML を見て「クリックジャッキング」や「クロスサイトスクリプティング」と混同する。
• GET／POST の区別に囚われ、POST なら安全と思い込む。

FAQ

解答の論理構成

1. 表2の各項番と結果を整理します。
   • 項番1：POSTデータに taikai_token=B582DF03524FBB9DBCCE0BA0610F2EA1 を含めた場合 → 「退会完了」。
   • 項番2：POSTデータに taikai_token=0 を含めた場合 → 「エラー画面」。
   • 項番3：POSTデータに taikai_token を送らず action_id=submit のみ → 「退会完了」。
   • 項番4・5：画面遷移（え）を経ずに直接アクセスした場合はいずれも「エラー画面」。
2. 図2のHTMLを確認します。行8～11で
   e">
   とまず 退会理由のみを送信し（＝画面遷移（え）に相当）、 行13～15で
   f">
   と taikai_token を全く付けずに action_id=submit を送信しています。
3. ②で送られるリクエストは、表2の 「POSTデータ：action_id=submit」と同一です。これは表2の項番「3」に該当し、結果は「退会完了」です。
4. したがって、b に入るのは “3” となります。

誤りやすいポイント

• 表2の読取りで「taikai_token=0」を送らないケース（項番3）を見落とす。0 を送るとエラーになるため混同しやすいです。
• 図2のHTMLが二段階で送信している点を理解せず、最初のフォーム（画面遷移（え）相当）だけで判断してしまう。
• 画面遷移（え）を経たあとでなければ脆弱性は起きないと早合点し、項番1を選んでしまう。

FAQ

解答の論理構成

• 表1【パスワード変更画面（い）】には
  “POSTデータ：… old_passwd=aBcD1234” とあり、要件には
  “old_passwdのハッシュ値が、サイトαに登録された現在のセッションをもつ利用者のパスワードのハッシュ値と同じ” と明記されています。
  つまり利用者はまず “現在のパスワード” を入力しなければパスワード変更処理に進めません。したがって c に当たる語は「現在のパスワード」です。
• K氏の説明では
  “c は攻撃者が d 情報であることを前提としてよい” と述べています。攻撃者が把握していない、すなわち “知り得ない” ことが安全性の前提条件になっているため d には「知り得ない」が入ります。

誤りやすいポイント

• “old_passwd” と “new_passwd1” の区別を取り違え、c を「新しいパスワード」と誤解する。
• “攻撃者が知り得ない” という前提を “攻撃者が知っていると想定する” と読み違え、d を「知っている」としてしまう。
• a（CSRF）の文脈を意識せず、cd がCSRF対策の話ではなく「認証情報の前提」に関する記述である点を見落とす。

FAQ

解答の論理構成

1. 退会処理の流れを確認
   【問題文】表1の画面遷移（え）では
   POSTデータ：action_id=confirm
   とあり、退会理由をサーバへ送信して「退会確認画面」を表示します。
   続く画面遷移（お）では
   POSTデータ：action_id=submit
   を送り、退会処理が行われ 退会完了となります。
2. 図2のHTMLが狙う動作
   図2には <form ... action="https://www.e-sha.co.jp/member/taikai"> が2つあり、1つ目は taikai_message を含み、2つ目は含みません。これは
   ・1回目のPOSTで退会理由を送って（え）を実行
   ・1秒後に2回目のPOSTで（お）を実行
   という連続操作を自動化して退会を成立させる意図です。
3. action_id に入る値の決定
   (1) 1回目＝（え）に相当するため e には confirm が入る。
   (2) 2回目＝（お）に相当するため f には submit が入る。
4. よって
   e：confirm
   f：submit

誤りやすいポイント

• 図2の1つ目のフォームに taikai_token が無いことから（お）と勘違いしやすい。POSTデータに taikai_message が含まれている時点で（え）だと判断します。
• 表2の項番「3」で action_id=submit だけで退会できる実装不備が示されているが、図2は確実に退会させるために（え）→（お）の正規手順を踏む体裁にしている点を見落としやすい。
• action_id の値を大文字小文字違いで書くと減点対象になります。表1の表記をそのまま引用する必要があります。

FAQ

解答の論理構成

1. 本文には
   “K氏：プロフィール入力・変更画面は、利用者が入力できるHTMLの要素が制限されています。しかし、例えば“”タグ中に、②特定の属性を指定することによってスクリプトの実行が可能です。”
   とあります。
2. 要素自体はスクリプトを実行する機能を持ちません。スクリプトを実行させるにはイベントハンドラ属性など、JavaScript を埋め込める属性を付与する必要があります。
3. 解答群のうちイベントハンドラとなるのは
   ・カ：onclick（クリック時に発火）
   ・キ：onmouseover（マウスオーバ時に発火）
   です。
4. その他の属性
   ア：accesskey、イ：class、ウ：hidden、エ：id、オ：lang、ク：title
   は、値にスクリプトを書いてもブラウザが JavaScript として解釈しません。
5. 以上より、スクリプト実行を可能にする“②特定の属性”は**「カ、キ」**となります。

誤りやすいポイント

• title や class に javascript: と書けば動くと思い込む。これらは URL を解釈する属性ではないので実行されません。
• タグが許可されていれば安全と考え、属性までチェックしない。イベントハンドラ属性を許容すると XSS が成立します。
• hidden を危険視してしまう。hidden は要素の表示非表示を制御するだけで、スクリプトを直接実行しません。

FAQ

Q: もし タグが許可されていた場合も onclick などは危険ですか？
A: はい。 に onclick や onerror を付与すると、画像読み込み失敗時にスクリプトを実行させるなど、さらに攻撃範囲が広がります。

Q: accesskey もキーボード操作を定義する属性ですが、危険ではないのですか？
A: accesskey 自体はショートカットキーを割り当てるだけで JavaScript を実行しません。値に javascript: を書いても無視されます。

Q: 属性を完全に除外せずに XSS を防ぐ方法はありますか？
A: サーバ側・クライアント側双方でホワイトリスト方式のサニタイズライブラリを用い、許可する属性を限定し、イベントハンドラや javascript: スキームを含む値を遮断する方法が一般的です。

---

関連キーワード: クロスサイトスクリプティング、サニタイズ、イベントハンドラ、JavaScript, HTML属性

解答の論理構成

1. 本文には「脆弱性2は“クロスサイトスクリプティング”であった。」とあり、 さらに K 氏は「スクリプト実行の結果、Cookieの情報が盗まれます。これを用いて、gが行われ、勝手にプロフィールを閲覧されたり、変更されたりするおそれがあります。」と説明しています。
   → ここで盗まれるのは Cookie 内の「JSESSIONID」（セッション ID）です。
2. セッション ID が第三者に渡ると、その第三者は被害者の“現在進行中の認証済みセッション”を乗っ取り、被害者になりすまして操作できます。
   → この一連の攻撃は一般に「セッションハイジャック」と呼ばれます。
3. 「勝手にプロフィールを閲覧されたり、変更されたりする」という被害は、まさにセッション乗っ取り後の不正操作にほかなりません。
4. したがって g に入る攻撃名は
   セッションハイジャック
   となります。

誤りやすいポイント

• 「Cookie が盗まれる＝クッキー窃取」と直接書いてしまう。攻撃名として求められているのは“盗んだ後に何をするか”であり、正式には「セッションハイジャック」です。
• 「セッションフィクセーション」と混同する。フィクセーションは攻撃者が“固定した”セッション ID を被害者に使わせる手法で、今回は被害者の ID を“奪う”シナリオなので別物です。
• “なりすまし”という日常語をそのまま書き、正式名称で回答しない。

FAQ

解答の論理構成

• 【問題文】には「“”タグ中に、②特定の属性を指定することによってスクリプトの実行が可能」とあります。ここで ②特定の属性 が攻撃ベクトルであり、HTML タグ自体ではなく“属性”が悪用されています。
• Xさんは「利用者が入力できるHTMLの要素の制限は変えずに、hという仕様に変更したい」と発言しています。すでに「要素（タグ）の制限」は導入済みなので、追加すべきは“属性の制限”であると分かります。
• K氏が「それで問題ありません」と応じているため、要素制限を維持しつつ属性を制御する方針が適切な対策になります。
• 以上から、hには「タグの中で利用できる属性を制限する」を入れるのが妥当です。これにより、スクリプトを呼び出す on* 系や src、style などの危険な属性を除外でき、クロスサイトスクリプティングを防止できます。