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

解答の論理構成

• 【問題文】の会話で検査員Nさんは
  “被害者が画面2-2'でメンバIDとパスワードを入力すると、それらはaというホスト名のWebサーバに送信されます。”
  と説明しています。
• 同じ会話内で、偽フォームを生成する外部スクリプトとして
  “”
  と明示されています。
• さらに図6の 4 行目には
  action="https://wana.example.jp/login"
  が提示されており、送信先ホストが一致していることが分かります。
• 以上から、空欄 a には「wana.example.jp」という FQDN を入れるのが妥当です。

誤りやすいポイント

• “example.jp” 部分を企業ドメインなどに書き換えてしまう
  （数字・固有名詞は正確に引用する必要があります）。
• “https://” を含めてしまい、ホスト名だけを答えるという指示を見落とす。
• 図6では「/login」まで書かれているため、パスを含めて記述してしまう。

FAQ

解答の論理構成

1. 問題文では攻撃者が送付するリンクについて
   ― “を組み込んだ**https://kensho.m-sha.co.jp/Gamen2_2**へのリンクを含む電子メールを作成”
   と明示されています。
2. 被害者がリンクをクリックした結果
   ― “被害者がそのリンクをクリックした場合、…改変された**画面2-2'**が表示されます。”
   とあるように、表示コンテンツは書き換えられますがリダイレクトは発生していません。
3. XSS はページ内部の DOM を改変する攻撃であり、URL 自体を変更しない限りブラウザのアドレスバーはリンク先のホスト部を保持します。
4. したがって、画面2-2'表示時のアドレスバーにはリンク先のホスト “kensho.m-sha.co.jp” が残ります。

誤りやすいポイント

• スクリプトを取得している “wana.example.jp” を答えてしまう。外部スクリプトの読み込み先とアドレスバーの表示は無関係です。
• フレームやリダイレクトを用いたフィッシングと混同し、「別サイトに遷移しているはずだ」と思い込む。XSS ではページ遷移せずに内容だけ書き換えられる場合があります。
• FQDN ではなくサブディレクトリを含めた全文字列や、逆に “m-sha.co.jp” と途中で切ってしまう。設問は「ホスト部を、FQDNで」と指定しています。

FAQ

解答の論理構成

1. 問題文には次の記述があります。

   Webブラウザには、bという仕組みが実装されているので、仮に、懸賞システムのコンテンツと、攻撃者が用意したWebサーバ上に置いてある攻撃者のコンテンツの両方を、フレームを使用して、Webブラウザ上で同一画面に表示したとしても、攻撃者のコンテンツ内のスクリプトで、懸賞システムのコンテンツを参照することはできません。

2. ここで述べられている「同一画面に表示しても、スクリプトから他方の内容を参照できない」というブラウザの制限は、ドメイン・プロトコル・ポートが異なる場合に働く同一生成元ポリシーの説明と一致します。
3. 解答群を確認すると、同一生成元ポリシーに該当する選択肢は

   エ：SameOriginPolicy
   だけです。

4. したがって、bに入る適切な字句は 「SameOriginPolicy」、記号は エ となります。

誤りやすいポイント

• 「HTTPStrictTransportSecurity」を選ぶ誤り
  ブラウザが HTTPS への強制リダイレクトを行う仕組みであり、フレーム間アクセス制御とは無関係です。
• 「AsynchronousJavaScript+XML」や「JavaScriptObjectNotation」を選ぶ誤り
  技術名称は似ていても、どちらもデータ通信手法・データ形式であり、アクセス制御機構ではありません。
• 「クロスドメインでデータを取れない＝CORS」と短絡し、選択肢にない用語を思い浮かべてしまうこと。CORS は例外的にアクセスを許可する仕組みであり、基本制限を課すのは SameOriginPolicy です。

FAQ

解答の論理構成

• 図2の報告では「画面2-1から画面2-2への遷移において、クロスサイトスクリプティング（以下、XSSという）脆弱性を発見した」と指摘され、図4のソースコード 6 行目で req.getParameter("keyword") を取得し、10 行目で無加工表示しているため「keyword」パラメタが攻撃面であることが分かります。
• また質疑応答で N さんは「攻撃者は、URLパラメタである keyword に攻撃用の文字列を組み込んだ https://kensho.m-sha.co.jp/Gamen2_2 へのリンクを…」と説明しています。ここから、脆弱な画面は「https://kensho.m-sha.co.jp/Gamen2_2」であり、攻撃対象パラメタは「keyword」だと確定します。
• 図7の行4は c?d=<script …> という形で、脆弱ページに対し XSS ペイロードを埋め込むための URL を組み立てる部分です。従って
  • c には「https://kensho.m-sha.co.jp/Gamen2_2」
  • d には攻撃対象であるパラメタ名「keyword」
  を入れることで、質疑応答と完全に一致する攻撃 URL が完成します。

誤りやすいポイント

• 画面3‐7を表示する URL と混同し、Gamen3_7 を入れてしまう。図7の行3で既に使用済みな点に注意すべきです。
• パラメタ名を「kw」と略記してしまう。図4のソースコードでローカル変数が kw でも、受信パラメタ名は keyword です。
• フルパスではなく相対パス /Gamen2_2 と書くミス。図7 は攻撃者サーバから直接参照されるのでスキーム・ホストを含む完全 URL が必要です。

FAQ

解答の論理構成

1. 攻撃者が窃取したいのは「①画面3-7の表示内容」です。
   【問題文引用】
   Nさん：攻撃者が…そのHTMLソースコードを被害者のWebブラウザに読み込ませることによって、①画面3-7の表示内容が窃取される可能性があります。
2. 図7のタグで読み込まれる URL はhttps://kensho.m-sha.co.jp/Gamen3_7 です。
   【問題文引用】
   注記　https://kensho.m-sha.co.jp/Gamen3_7は、図1の画面3-7を表示する際のURLである。
3. 画面3-7 は会員の「住所」「氏名」などを修正する機能で、ログイン後のマイページ配下(画面3-3～3-9)に属します。
4. これらマイページ配下の URL については、ログインしていないと強制的にトップページへリダイレクトされます。
   【問題文引用】
   注記2：ログインしていない状態で画面3-3～画面3-9のURLを指定した場合は、画面1-1へリダイレクトされる。
5. よって「画面3-7の内容がブラウザに表示されている＝被害者が懸賞メンバとしてセッションを確立している」ことが前提です。
6. 以上から、窃取が成功する条件は「懸賞メンバとしてログインしている状態」となります。

誤りやすいポイント

• 「フレームで読み込むだけだからログイン不要」と誤解しやすいが、実際にはサーバ側で認証チェックが行われるため表示されない。
• 「トップページの情報なら窃取できるのでは」と考えがちだが、攻撃対象はログイン後画面なのでセッション有無が決定的。
• 同一生成画面であっても、URL 直打ちで見られるページとセッション必須ページを区別し忘れると判断を誤る。

FAQ

解答の論理構成

1. 図8は「CSRF対策に関する説明」を示しています。
   (2)の実装ルールに
   ――「前画面で、HTMLフォーム内にeをfフィールドの値として埋め込む。」
   ――「画面遷移時に受信したデータが、埋め込んだeと一致するかを確認する。」
   とあります。
2. CSRF対策では、利用者の意図しないリクエストかどうかを判断するために“予測不能な値”をフォームに埋め込み、次画面で一致確認を行う方法（Synchronizer Token Pattern）が基本です。
3. ここで求められる“予測不能な値”は、セッション毎・リクエスト毎に生成して攻撃者が推測できないようにする必要があります。これを説明する最も一般的な語は「ランダムな値」です。したがってe＝「ランダムな値」となります。
4. トークンをユーザに見せずに送信させるため、フォームではを用います。設問はその属性名を答えさせているので、f＝「hidden」が正解です。

誤りやすいポイント

• 「セッションID」をそのままeに使うと考えると失点します。図8は“前画面で埋め込み、次画面で一致確認”と書かれており、セッションIDは既にCookieで送信されているため趣旨が異なります。
• fを「テキスト」や「submit」と記入する誤答が散見されます。トークンをユーザが目視できないようにする目的を忘れると選択を誤ります。
• 一致確認の手順だけを覚えていて、トークン自体の「予測不能性」を軽視すると、eに「固定値」「ハッシュ値」など不適切な語を入れてしまいます。

FAQ

解答の論理構成

1. CSRF対策が必要な画面遷移
   – 図8では「POSTメソッドによるアクセスだけを用いる」と示されており、さらに CSRF は「利用者の意思に反してサーバ側の状態を変更させる攻撃」なので、 • サーバに“登録”“修正”“応募”などの更新要求を送る遷移は対策対象
   • 検索や一覧表示など“読み取り系”の遷移は対象外
2. 各遷移の性質を確認（図1・表1引用）
   ① （く）応募必要事項送信：表1で「応募必要事項」を渡す ⇒ 応募データを新規登録する更新系
   ② （し）住所等送信、（す）住所等確認：表1で「住所、氏名、…」を渡す ⇒ 会員情報を修正する更新系
   ③ （い）キーワード検索：表1で「キーワード」を渡すのみ ⇒ 読み取り系
   ④ （さ）登録情報修正画面の表示、（せ）修正完了 → トップ画面：いずれも hidden やパラメタ無し（表1「なし」）で状態変更はなし
3. 以上より
   • CSRF対策を行うg＝更新系③を除いた（く）（し）（す）
   • CSRF対策を行わないh＝読み取り系＆表示系（い）（さ）（せ）
4. 解答群と照合
   – 行「ウ」：g 列＝「（く）、（し）、（す）」／h 列＝「（い）、（さ）、（せ）」
   – 他の行は g と h が逆、又は不要な遷移を含む
   よって「ウ」が適切。

誤りやすいポイント

FAQ

解答の論理構成

• 【問題文】では“②画面2-1においてWebブラウザ側のスクリプトで入力値を検査していた”とあります。これは「画面2-1」で クライアント側 の JavaScript が keyword を検証する方式です。
• しかし Nさんは、“攻撃者は、URLパラメタであるkeywordに攻撃用の文字列としてを組み込んだhttps://kensho.m-sha.co.jp/Gamen2_2へのリンクを含む電子メールを作成” と説明しています。
• つまり攻撃者は 「画面2-1」を経由せずに 被害者のブラウザを直接 “https://kensho.m-sha.co.jp/Gamen2_2” に遷移させ、keyword に悪意ある値を渡します。
• ブラウザ側検査は「画面2-1」にしか存在しないので、このバイパスを阻止できません。したがって下線②の検査は XSS 攻撃を防御できず、模範解答のとおりになります。

誤りやすいポイント

• サーバ側で再検証していると勘違いし、「十分な対策」と誤認する。
• 「画面2-1の検査＝全遷移で有効」と思い込み、直接 URL 参照を見落とす。
• 「POST 送信なら安全」と短絡し、GET パラメータ経由の XSS を軽視する。

FAQ

解答の論理構成

• 図9のガイドラインは「利用者が入力する値は、期待する入力値として正当かどうか検査すること」と規定していましたが、検査場所の明示がありませんでした。
• T君は“②「画面2-1においてWebブラウザ側のスクリプトで入力値を検査していた」ので、URLパラメタであるkeywordの値を信頼できるデータと判断”し、そのまま 10 行目で出力に使用したため XSS が発生しました。
• この経緯を踏まえ、N さんは図10で「入力値が正当かどうかを i で稼働するプログラムで確認する必要がある」と指摘しています。
• クライアント（Webブラウザ）側の検査はユーザ任意の JavaScript で迂回できるため、信頼できません。したがって検査は改ざんされにくいサーバで実施する必要があります。
• 以上より i に入る語は「サーバサイド」です。

誤りやすいポイント

• 「ブラウザ側検査で十分」と思い込み「クライアントサイド」と答えてしまう。
• JavaScript という実装言語名を書いてしまう。求められているのは検査を行う“場所”です。
• 「バックエンド」など曖昧な語を使い、原文のニュアンスとずれる。

FAQ

解答の論理構成

• 図10の引用
  「例えば、j を出力する箇所では、XSS脆弱性を防ぐために “javascript:” などの文字列を排除する必要がある。」
  ⇒ “javascript:” は や といったリンク先やリソース先を示す属性値で利用され、ここに悪意コードを混入させると XSS が成立します。
• href や src が表す値は URL であり、HTML 仕様上「javascript:」「data:」などのスキームも許容されます。したがって、XSS 対策としてスキーム単位のホワイトリスト検査が必要であるという文脈になります。
• よって j には「URL」を入れると文章が自然に成立し、XSS の注意点も正しく説明できます。