情報処理安全確保支援士 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

解答の論理構成

1. 表2の“検出パターン”を確認します。
   – 「4」の説明は
   「HTTPレスポンスボディの特定のURI属性（src, action, background, href, content）に検査文字列が出力される場合、脆弱性ありと判定」
   というものです。
2. 図1のプログラムb行目（21行目）は
   out.print ("<a href=""+ escapeHTML(rqUrl) + "">");
   となっており、クライアントから受け取ったrqUrlを <a> タグの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」です。

誤りやすいポイント

• escapeHTMLを使っているから安全だと思い込み、javascript: スキームを許容している点を見落としやすいです。
• 表2「1」「2」は“ボディにそのまま表示されるか”をチェックするもので、URI属性への挿入とは判定基準が異なることを混同しがちです。
• “入力内容確認画面”と“エラー画面”という対象画面の違いだけで選択してしまい、本質である“URI属性への出力可否”を読み飛ばすケースが多発します。

FAQ

解答の論理構成

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 + "</option>");
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 + "</option>");
   いずれもデータベースから取得した文字列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の <option> 生成部など “検査対象以外” の出力箇所は未検査となり、脆弱性を見逃しました。
• 以上から、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

解答の導き方

誤りやすいポイント

• escapeHTMLをしていれば安全と考える誤り：escapeHTMLは <、>、&、"、' をエスケープするが、URIスキーム（javascript: 等）を無効化しないため、リンク先のスキーム検査は別途必要です。
• サーバ側のエスケープだけで十分と考える誤り：ブラウザは属性値のエンティティを復号してDOMプロパティとして返すため、クライアントでの操作（options[index].value取得→hiddenへ代入）により元の（危険な）文字列が流れる場合があります。
• 「optionの表示テキストだけが問題」と見落とす誤り：value属性に悪意あるURLを入れられると、ユーザ操作経路を通じて実際にhrefに使われてしまいます。
• 修正箇所を「出力側だけ」または「受信側だけ」に限定してしまう誤り：安全対策は出力時の検証（サーバ側）と、必要なら受信後の再検証の両方で行うべきです。

FAQ

解答の論理構成

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

誤りやすいポイント

• エスケープ処理（実施項目②）が入っているため安全と早合点しやすい。実装場所が <script> 内か否かを必ず確認する必要があります。
• 実施項目③「URL制限」と取り違えるケースが多い。h行目 では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