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

解答の論理構成

1. 検出パターン1〜3の検査文字列はすべて GET／POST パラメタや URL のパス部に '><hr> や '><script>…</script> を埋め込み、「HTTPレスポンスボディに検査文字列がエスケープ処理などを行われずに出力される場合、脆弱性ありと判定」と定義されています。これは、表1 の実施項目②「Webページに出力する全ての要素に対して、エスケープ処理を施す。」が守られていなければ発生する問題です。
   • したがって、パターン1・2・3はいずれも②の不備を検出します。
2. 検出パターン4は、検査文字列に javascript:alert(document.cookie); を用い、「HTTPレスポンスボディの特定のURI属性（src, action, background, href, content）に検査文字列が出力される場合、脆弱性ありと判定」とされています。URI属性に javascript: スキームがそのまま出力されるのは、表1 の実施項目③「URLを出力するときは、"http://" 又は "https://" で始まるURLだけを許可する。」を満たしていないために起こります。
   • したがって、パターン4は③の不備を検出します。

誤りやすいポイント

• パターン4を「エスケープ漏れ」と誤認して②を選びがちです。URI属性に出力されるか否かに着目し、URLスキーム制限③の観点で判断することが重要です。
• パターン1と2の違い（単なるタグ挿入か script 挿入か）に惑わされて別の実施項目を当てはめてしまうケースがありますが、どちらも同じ「エスケープ処理漏れ」のチェックです。
• 表1 の文章を正しく引用・照合せずに「スクリプト生成＝④」と機械的に結論づけて失点する例が多いです。検査手順と項目の対応関係を必ず確認しましょう。

FAQ

Q: パラメタ値がそのまま などに入る場合はどの実施項目で防ぐのですか？
A: 出力先が URI 属性であれば③でスキームを制限し、同時に②でエスケープ処理も行います。基本は多層防御です。

解答の論理構成

1. 表2の“検出パターン”を確認します。
   – 「4」の説明は
   「HTTPレスポンスボディの特定のURI属性（src, action, background, href, content）に検査文字列が出力される場合、脆弱性ありと判定」
   というものです。
2. 図1のプログラムb行目（21行目）は
   out.print ("<a href=""+ escapeHTML(rqUrl) + "">");
   となっており、クライアントから受け取った rqUrl を タグの href 属性へそのまま出力しています。
3. escapeHTML は「<、>、&、"、'」の5文字しか変換しません。よって javascript:alert(document.cookie); のようなスキーム名やコロンはそのまま残ります。
4. 表2の検出パターン「4」の検査文字列は
   javascript:alert(document.cookie);
   であり、そのまま href に入ればリンククリック時に JavaScript が実行されます。
5. したがって、図1b行目で表2「4」の判定条件
   「HTTPレスポンスボディの特定のURI属性（…href…）に検査文字列が出力される」
   が満たされるため、脆弱性を検出できるのは検出パターン「4」です。

解答の論理構成

1. 【問題文】の“社内検査”では、D君が“検出パターンaの検査で脆弱性ありと判定された”とある。さらに、検出パターンaがどれかは表2を見ると、URI 属性に値を埋め込むケース（検出パターン4）のみが“javascript:alert(document.cookie);”を用いている。
2. 検出パターン4の“脆弱性ありと判定する基準”は「HTTPレスポンスボディの特定のURI属性（src, action, background, href, content）に検査文字列が出力される場合」と書かれている。
3. 図1のプログラムで URI 属性（href）にユーザ入力を直接出力している箇所は
   out.print ("<a href=""+ escapeHTML(rqUrl) + "">");
   しかない。
4. この文は図1の【問題文引用】「out.print ("<a href=\""+ escapeHTML(rqUrl) + "\">");」の行であり、図では行番号bとなっている。実際の図1の行番号は“18”。
5. したがって、脆弱性の原因行 b は “18” である。

誤りやすいポイント

• 「escapeHTML」で <、>、&、"、' を逃がしているので安全だと早合点しやすいが、表1の実施項目③「"http://" 又は "https://" で始まるURLだけを許可する」が未実装のため javascript: スキームを完全に防げない。
• “href” や “src” など URI 属性の検査は、文字列エスケープだけでなくホワイトリスト方式のスキーム制限が必須であることを見落としやすい。
• 行番号を探す際、図1には省略行（(省略) のコメント）があるため、表示されている数字を正確に追わないとずれてしまう。

FAQ

解答の論理構成

• 図1のb行目では、out.print ("<a href=""+ escapeHTML(rqUrl) + "">"); と、利用者入力の rqUrl を href 属性にそのまま出力しています。
• escapeHTML は【問題文】注記のとおり <、>、&、"、' をエスケープするだけなので、javascript: などのスキーム名には一切影響しません。
• Web健康診断の検出パターン4は「javascript:alert(document.cookie); が URI属性（src, action, background, href, content）に出力される場合、脆弱性ありと判定」と定義されており、今回まさに href が問題箇所です。
• 表1の実施項目③は「URLを出力するときは、"http://" 又は "https://" で始まるURLだけを許可する。」と規定しており、これが漏れているため外部スクリプト起動を阻止できていません。
• よって、rqUrl が "http://" または "https://" で始まる場合のみリンクとして採用し、それ以外は拒否・無効化するホワイトリスト方式を取るべきであり、設問の模範解答に帰着します。

誤りやすいポイント

• 「HTMLエスケープさえ行えば XSS は防げる」と思い込み、URIスキームの検査を失念する。
• ブラックリストで javascript: だけを弾こうとし、data:text/html;base64,... など別スキームを見落とす。
• GET／POST パラメータだけをテストし、今回のように隠しフィールドや属性値に渡されるケースを検査対象外にしてしまう。
• 正規表現で URL をチェックする際、大小文字混在や全角半角を考慮せずバイパスを許してしまう。

FAQ

解答の論理構成

1. 図3のコードを確認すると、データベースから取得した値をそのまま HTML に埋め込んでいる行が二つある。
   ・out.println("よく用いられるキーワード：" + rsKey);
   ・out.println("<option value=¥"" + rsLoc + "¥">" + rsLoc + "");
2. これらの行では、表1の実施項目②「Webページに出力する全ての要素に対して、エスケープ処理を施す。」が適用されていない。
3. F社の診断コメント「社内検査の検査対象以外に、対策漏れがある。」は、まさに rsKey・rsLoc の出力部分を指摘している。
4. 図3の行番号と照合すると、上記の2行はc＝17 行目、d＝24 行目である。
5. 社内検査では「検査対象をfに限定」していたため、データベース由来の値は検査範囲外となり D 君は検出できなかった。
6. 以上より、c と d には「17」「24」が入る。

誤りやすいポイント

• 画面入力値だけを疑い、データベースや設定ファイルなど“内部ソース”から流入する値の XSS を見逃しやすい。
• 行番号はコメントや省略行を含めた“試験冊子ベース”で付与される。IDE で表示させた番号と食い違うことに注意。
• value="..." 属性にもエスケープが必要という基本をうっかり忘れるケースが頻発する。

FAQ

解答の論理構成

1. まず設問は、図3のc行目とd行目で欠けている対策が表1のどの項目に該当するかを問うています。
2. 図3の該当行を確認すると
   ・[19] out.println("よく用いられるキーワード：" + rsKey);
   ・[26] out.println("<option value=¥"" + rsLoc + "¥">" + rsLoc + "");
   いずれもデータベースから取得した文字列 rsKey や rsLoc を そのまま HTMLに出力しています。
3. 表1の実施項目を再確認すると
   　「②　Webページに出力する全ての要素に対して、エスケープ処理を施す。」
   　と定義されています。
4. 本来は escapeHTML(rsKey) や escapeHTML(rsLoc) のようにエスケープ処理を行う必要がありますが、実装されていないため、表1の実施項目「②」に違反していると判断できます。
5. したがって e に入るのは 「②」 です。

誤りやすいポイント

• 「③ URL制限」と混同する
  value 属性に URL が入る場面があるため項目③と勘違いしやすいですが、問題となっているのは 属性値の検証 ではなく 文字列のエスケープ漏れ です。
• 「入力フォームだからサーバ側で自動的にサニタイズされているはず」と思い込む
  HTML組み立て時に手動で + 連結している限り、自動サニタイズは行われません。
• エスケープ対象が「<」「>」だけだと思い、" や ' を見落とす
  属性値では " が閉じられてスクリプトが開始される典型的な XSS パターンになります。

FAQ

解答の論理構成

• 【問題文】では、図3のプログラムについて
  “社内検査では、検査対象をfに限定しているのでD君はこの脆弱性を検出できなかった。”
  と記載されています。
• 社内検査の基準は、表2 “Web健康診断に基づいて作成したXSS対策の判定基準” で示されます。
  検出パターン1・2の “検査文字列を入力する場所” は
  “"GET パラメタ及び POST パラメタ"” と明示されています。
• つまり D 君が行った社内検査は、入力位置を “"GET パラメタ及び POST パラメタ"” に限定していたため、 図3の 生成部など “検査対象以外” の出力箇所は未検査となり、脆弱性を見逃しました。
• 以上から、f に入る字句は表2にそのまま載っている
  “"GET パラメタ及び POST パラメタ"” が適切です。

誤りやすいポイント

• “URL中最後の"/"に続く文字列” や “特定のURI属性” と混同し、検査対象を URI 全般と誤解する。
• 表2の列見出しを引用せずに要約表現（例：リクエストパラメータのみ）で書いてしまう。
• “GET” と “POST” の間をコンマやスラッシュでつなぎ、原文を改変してしまう。

FAQ

解答の論理構成

1. 問題文は、賃貸物件検索画面（図3）の修正方針として
   ― “修正：エスケープ処理が必要であり、定義されているメソッドgを適用すべきである。”
   と指示しています。
2. 既に実装済みの賃貸物件選択結果画面（図1）では、URI も文字列も画面出力前に
   ― escapeHTML(...)
   を使ってエスケープしていることが説明されています。
3. したがって、図3でも同じ XSS 対策メソッドを再利用するのが自然であり、g には “escapeHTML” が入ります。
4. 以上より、解答は
   g：escapeHTML
   となります。

誤りやすいポイント

• Java 標準ライブラリの StringEscapeUtils や URLEncoder と混同してしまう。問題文は「定義されているメソッド」と述べているため、自前実装の escapeHTML を指す。
• URI のエスケープと HTML のエスケープを混同する。escapeHTML は “HTMLテキストの入力を許可しない” 方針を補強するもので、URI 正当性確認（表1③）とは別対策である。
• 「図1で使われているから図3でも同じだろう」と暗記的に判断しがちだが、論拠は “XSS対策として統一したエスケープ処理を再利用する” ことにある。

FAQ

解答の論理構成

• 【図4】の 22〜27 行は、フォームの hidden フィールドへ値を設定する JavaScript をサーブレット内で生成しています。
• うち 26 行目には

  out.println(" document.form1.menu1.options[index].label;");
  とあり、options[index].label（利用者に提示する物件名）を そのまま hidden フィールド name にコピーしています。

• 表1「②　Webページに出力する全ての要素に対して、エスケープ処理を施す。」では、画面に再表示されるあらゆる文字列に HTML エスケープをかけることを求めています。
• この hidden フィールドは再び【図1】で

  out.print (" [ " + escapeHTML(rqLoc) + " ] ");
  out.println(escapeHTML(rqName) + "");
  と画面表示に使用されますが、26 行目ではエスケープが行われていないため、"

• したがって、表1実施項目②に対して対策が不十分である行は 26 行目となります。

誤りやすいポイント

• JavaScript 内だから安全と思い込み、サーバ側で作るスクリプト文字列に利用者入力を直接入れてしまう。
• hidden フィールドは「画面に見えない」ため安全と誤解し、値のサニタイジングを忘れる。
• escapeHTML を一度使ったらその後の処理でも安全と決めつけ、データの流れ全体を確認しない。

FAQ

解答の論理構成

1. 問題文は、図4のプログラムにおける h行目 の対策不足を指摘し、表1のいずれの実施項目に該当するかを問うています。
2. 表1でスクリプト要素に関する対策を示しているのは「④　スクリプト要素の内容（“<script>…</script>” の “…” 部分）を動的に生成しない。」です。
3. 図4では の間で Java から out.println により JavaScript コードを逐次生成しており、h行目 はその一部です。すなわちスクリプト要素の“…”をサーバ側で動的生成している典型的な例で、実施項目④が要求する「動的に生成しない」という方針に反します。
4. したがって i に入るべき実施項目は「④」です。

誤りやすいポイント

• エスケープ処理（実施項目②）が入っているため安全と早合点しやすい。実装場所が
• 実施項目③「URL制限」と取り違えるケースが多い。<span class="choice-box">h</span>行目 では URI ではなくスクリプト本体を生成しているため③ではありません。
• 「動的に生成しない」の解釈を“JavaScript を使わない”と誤読しやすい。ポイントは HTML 生成段階でスクリプト断片をサーバ側で組み立てない設計（外部 .js や定数文字列化）にあります。

FAQ

解答の論理構成

• 【問題文】図4の JavaScript では、次のように スクリプト要素の内容を動的に生成しています。
  ・out.println(" document.form1.msg1.value = "" +
  ・out.println(" document.form1.menu1.options[index].text;");
  ここで + escapeHTML(rqLoc) + の部分にリクエストパラメータが挿入されるため、表1の実施項目 ④「スクリプト要素の内容（…）を動的に生成しない。」 に抵触します。
• 表示したい “[ 地区名 ]” は、すでに <input type="hidden" name="loc" …> に escapeHTML(rqLoc) で埋め込まれているので、スクリプトの中で再度リクエストパラメータを連結する必要はありません。
• したがって、JavaScript は フォーム部品から値を取得するだけ に書き換えれば動的生成を回避できます。
• 具体的には、onSet() 内で “[ 地区名 ]” を 'document.form1.loc.value' から取得するようにし、Java 側の出力文を 1 行だけ修正します。

• これにより
  ① リクエストパラメータを直接スクリプトに書き込まない
  ② HTML 側で既にエスケープ済みの値を利用できる
  という 2 点が同時に達成され、表1実施項目 ④ に適合する修正となります。

誤りやすいポイント

• 「エスケープしているから安全」と思い込み、動的 JavaScript 生成そのものの危険性（表1 ④）を見落とす。
• out.println のまま改行付きで出力し、余計な文字や区切り記号を入れてしまう。
• loc フィールドではなく msg1 や url など別の要素名を参照してしまい、スクリプトが正常に動作しなくなる。

FAQ