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

解答の論理構成

1. 問題文では、SQLインジェクション脆弱性を除去するために
   “図1のア行目からイ行目までを①適切なコードに置き換える必要がある”
   と明記されています。
2. Statement で文字列連結を用いて SQL を組み立てている箇所を置き換えるのが本質なので、conn を初期化した直後から Statement を生成する直前までの範囲がターゲットになります。行番号は図1で try { の直後に当たる “9” 行目から Statement stmt = ... の “11” 行目までです。
   よって
   ア＝「9」、イ＝「11」。
3. 置き換えるコードは、プリペアドステートメントを使い、プレースホルダへパラメタを安全にバインドする形式でなければなりません。解答群を見ると
   ・カ：String sql = "SELEC * FROM companylist WHERE cname = ?"
   ・ア：PreparedStatement pstmt = conn.prepareStatement(sql);
   ・イ：pstmt.setString(1, cname);
   ・ウ：ResultSet rs = pstmt.executeQuery();
   が順に “SQL 文定義 → プリペアドステートメント生成 → プレースホルダへ値設定 → 実行” という定石的な流れになります。
   以上から、①に入る全コードは「カ、ア、イ、ウ」の順です。

誤りやすいポイント

• 行番号を数える際に “コメント行” や “空白行” を含めてしまい、実際の 9 行目・11 行目とずれてしまうケースが多発します。
• 解答群「エ」は executeQuery(sql) と再び文字列を渡しているため、PreparedStatement の利点が失われることに気づかず選びがちです。
• 「ア→イ→ウ」だけで完結すると誤認し、プレースホルダを含む SQL 文（カ）を忘れるパターンも典型的な失点原因です。

FAQ

解答の論理構成

1. XSS は「利用者の入力値や DB に保存された値を、そのまま HTML に埋め込んでブラウザへ返す」ことで発生します。
2. N氏は「XSS脆弱性を招く可能性の否定できない箇所について、HTML形式での出力時に処理するよう改修」と指摘しています。
3. 図1では out.println で HTML を生成しており、次の行が該当します。
   • 行番号“21” out.println("キーワードアクセス売上げ");
   • 行番号“22” while (rs.next()) { ※以降のセル出力をループさせる入口
   • 行番号“23” out.println("" + rs.getString(1));
4. “21”は静的文字列ですが、XSS の混入箇所（行“23”以降）を囲む tr･td タグを生成しているため、ここからエスケープ処理を挿入しなければ全体の対処が不完全になります。
5. よって、改修すべき行番号は「21、22、23」です。

誤りやすいポイント

• 「DB に保存済みなら安全」と思い込み rs.getString() を無条件で出力してしまう。
• while (rs.next()) の行を対象外と勘違いし、XSS 対策コードをループの内側だけに入れてしまう。
• 固定文字列だけの行は安全と判断し、“21” を除外してしまう。タグ生成行の直後に未エスケープ値が入る場合、同じ行でまとめて修正するのが一般的です。

FAQ

解答の論理構成

1. 【問題文】には
   　・「XSS脆弱性への対処としては、…HTML形式での出力時に処理するよう改修することとする。」
   　と記載されています。
2. XSSはブラウザにスクリプトを注入させる攻撃なので、サーバ側で生成する HTML に危険文字がそのまま混入しないよう「出力時」にエスケープ処理を行うことが王道対策です。
3. 解答群を確認すると、文字実体参照（<、>、&、"、' など）に置き換える対策を示しているのは
   　「ウ：出力時に<、>、&、”、'の各文字をエスケープする。」
   　だけです。
4. 以上より、N氏の指摘と合致するのは「ウ」であると論理的に導けます。

誤りやすいポイント

• 「オ：バインド機能を使う。」は SQL インジェクション対策の手法であり、XSSとは目的が異なります。
• 「ア：CSRF対策トークンを使う。」は利用者の意図しないリクエスト送信を防ぐ技術で、スクリプト埋め込みは防げません。
• HTML 出力時のエスケープは、必ず“サーバ側で生成するすべての箇所”に適用する必要があります。テーブルの だけでなく、
• same-origin policy（解答群エ）や Referer チェック（解答群イ）は補助的な安全策に過ぎず、根本的にタグ混入を防ぐ仕組みではありません。

FAQ

解答の論理構成

1. 問題文の確認
   • 「指摘2：WシステムからのCookie発行の際、TLS通信時だけCookieをブラウザから送信するa属性を設定する必要がある。」
   • 「指摘3：JavaScriptからCookieを操作できないようにするb属性を設定する方がよい。」
2. TLS通信時だけ送信させる属性
   • Cookie に付与することで “HTTPS での通信時のみブラウザが送信する” 挙動を実現するのは Secure 属性です。
   • 解答群で該当するのは「エ：Secure」であり、これが a に入ります。
3. JavaScript からのアクセスを禁止する属性
   • Cookie が XSS などで読み取られるのを防ぎ、クライアント側スクリプトから参照できなくするのは HttpOnly 属性です。
   • 解答群で該当するのは「イ：HttpOnly」であり、これが b に入ります。
4. 以上より
   • a ＝ 「エ」
   • b ＝ 「イ」

誤りやすいポイント

• 「TLS通信時だけ」のキーワードで Secure を想起しにくく、似た表記の「オ：Secured」を選択してしまう。
• HttpOnly は “HTTP だけで有効になる” と誤解し、サーバ接続プロトコル限定の属性だと思い込む。
• Expires や Max-Age は Cookie の有効期限を制御する属性であり、通信経路や JavaScript からの参照可否とは無関係である点を取り違える。

FAQ

解答の論理構成

• 【問題文】には「指摘1：Wシステムの認証後のリダイレクタ機能は、オープンリダイレクタの問題を招く。修正する必要がある。」とあり、任意サイトへ転送されるリスクが指摘されています。
• 同じく【問題文】には「K氏は、指摘1に対しては、②ホワイトリスト方式によるリダイレクタ機能を採用することにした。」とあり、転送先を事前に許可したものに限定する方針が明示されています。
• オープンリダイレクトは、攻撃者が自ドメイン外の URL を設定できることが原因です。したがってホワイトリストには自システムが正規に用いる URL だけを登録するのが筋となります。
• W システムの正規 URL は【問題文】に「WシステムのURLである https://w-system.a-sha.jp/」とはっきり書かれており、この FQDN 以外を転送先として許可する必要はありません。
• 以上より、「認証後のリダイレクト先の URL を、Wシステムの FQDN のものに限定する」という仕様が、ホワイトリスト方式の具体策として適切であると結論付けられます。

誤りやすいポイント

• 複数サブパスを列挙するブラックリスト方式と混同し、危険 URL を除外する方向で考えてしまう。
• http と https の区別を忘れ、同じ FQDN でも暗号化されていない転送を許可してしまう。
• CDNs や外部 API など別ドメイン利用時の転送と混同して、余計な FQDN までホワイトリストに入れてしまう。

FAQ

解答の論理構成

• 【問題文】では、修正版は開発用PCにはあったものの「K氏からファイルを受け取ったF氏が、本番システムに修正版をデプロイし忘れたので、本番システムに脆弱性が残存したままとなっていた」と記載されています。
• つまり従来の検査対象は開発環境に限定されており、本番環境へ反映漏れがあっても気付けませんでした。
• その結果、N氏が「脆弱性検査手順を改善すべきである」と提案しています。
• 改善すべき点は、リリース後の“実際に顧客が利用する環境”を直接確認し、デプロイ漏れや設定ミスを即時検知できるようにすることです。
• よって、検査手順の改善は「セキュリティ検査を本番システムに対し行うこと」となります。

誤りやすいポイント

• 開発環境での検査強化と誤解し、検査ツールの追加導入や手動項目の充実と答えてしまう。
• 「ステージング環境での検査」と答え、実際の本番環境検査を外してしまう。
• 変更管理プロセス改善（別提案）と混同し、レビュー体制や承認フローの記述に寄せてしまう。

FAQ

解答の論理構成

1. 【問題文】では、K氏が「ブラウザを用いた手動のセキュリティ検査」を実施したとあります。
2. その検査で見落とした理由について、N氏は「④一部のブラウザではXSS攻撃の試みを完遂できないことがある」と指摘しています。
3. 近年、多くの主要ブラウザには XSS Filter や XSS Auditor などと呼ばれる機能が実装されており、疑わしいスクリプトを自動的に除去・無効化します。
4. この機能が働くと、攻撃用に入力した
5. したがって、「一部のブラウザでは XSS 攻撃自体をブラウザ側が遮断するため、攻撃を再現できず検証に失敗する」という説明が成り立ちます。

誤りやすいポイント

• 「検査用文字列が不適切だった」と勘違いし、ブラウザ固有機能の存在を見逃す。
• ブラウザの開発者ツールでエラーが見えない＝安全、と早合点する。
• WAF やサーバ側フィルタと混同し、クライアント側の防御機構を忘れる。

FAQ

解答の論理構成

• 問題文では、クラウド型WAFサービスである「Sサービス」について
  「Sサービスでは、Webシステムに脆弱性が発見された際、短時間で適切なシグネチャがWAFに追加される」と記載しています。
• さらに「WAFを利用せずにWシステムを改修するケースと比較して、⑤Webアプリケーションサーバへのリスクの低減を期待できる」と述べています。
• つまり、WAFのシグネチャ追加が素早く行われれば、開発側で脆弱性を修正してデプロイするまでの“空白期間”にも攻撃をブロックできます。
• この空白期間に攻撃が成功すれば「Webアプリケーションサーバへのセキュリティ侵害」が発生し得ます。
• したがって⑤で低減できるリスクは、脆弱性修正前に実被害が生じるリスクであり、模範解答は
  「Wシステムで当該脆弱性に対処する前に始まる攻撃によって、セキュリティ侵害されてしまうリスク」
  となります。

誤りやすいポイント

• 「WAFを導入すれば恒久的にコード修正が不要になる」と誤解しやすいですが、WAFはあくまで暫定的な防護策です。
• ⑤が指すリスクを「SQLインジェクションそのものを防ぐリスク」など個別攻撃名で答えると範囲が限定され減点対象になります。
• Sサービスの効果を「性能劣化の防止」や「通信経費の削減」と勘違いすると設問の趣旨から外れます。

FAQ