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

解答の論理構成

1. 原文では、DoS 脆弱性を解消するためにミドルウェアの「修正プログラムを適用」する必要があるが、サイト担当者は “①修正プログラムの適用にはリスクがある” と発言しています。
2. この文脈で言うリスクとは、修正プログラムを導入した結果、既存システムに想定外の影響が生じ、Web サーバや関連サービスが停止・不安定化する可能性を指します。
3. したがって設問が求める「リスク」は、パッチ適用後にサービスが正しく提供できなくなる事態であり、解答例「サーバが正常に動作しなくなるリスク」となります。

誤りやすいポイント

• 攻撃を受けるリスクとパッチ適用リスクを混同し、DoS 攻撃自体を答えてしまう。
• リスクを「互換性の問題」など抽象的に述べ、サーバ停止の可能性を明示しない。
• 「リスク＝業務停止」と誤解し、“業務が停止する” とだけ書き技術的視点を欠く。

FAQ

解答の論理構成

1. 原因の整理
   • 表3 項番1では「サービスを提供できなくなる可能性がある」DoS脆弱性が指摘されています。
   • さらに、サイト担当者は“①修正プログラムの適用にはリスクがある”と発言しています。
2. リスクの中身
   • 修正プログラム適用時にサービス停止・機能不全が起こると、外部利用者に影響が及びます。
   • したがって、適用後に“止まったかどうか”を即時に気付ける仕組み（検知）と、“元に戻す”ための準備（回復）が必要です。
3. 検知に必要な作業
   • サービス停止などの異常をいち早く把握するには、リソースやプロセス死活・応答時間を監視し、通知できる体制が不可欠です。
   • これにより、適用作業による想定外の停止を即時発見できます。
4. 回復に必要な作業
   • 適用が失敗した場合、迅速にロールバックするにはファイルや設定を事前に退避しておくことが必須です。
   • “ミドルウェアに修正プログラムを適用していなかった”現状から安全に戻すには、バックアップが最も確実な回復策です。
5. よって、
   • 検知：サーバ停止を把握できる監視体制の整備
   • 回復：サーバを元の状態へ戻すためのバックアップ
     が解答となります。

誤りやすいポイント

• “検知”をログ取得と混同し、監視体制ではなく“アクセスログの出力設定”だけを書く。
• “回復”を再起動と短絡的に捉え、バックアップ準備を忘れる。
• パッチ適用の前後手順と、DoS脆弱性そのものの回避策（WAF設定など）を混同して記述する。

FAQ

解答の論理構成

1. 【問題文】では
   “IDを固定して、考えられる全てのパスワードを試行する、aが行われる可能性がある。”
   と記載されています。
2. “IDを固定”し“考えられる全てのパスワードを試行”する行為は、パスワード候補を総当たりで入力して突破を狙う攻撃です。
3. この攻撃は一般に「ブルートフォース攻撃」と呼ばれます。
4. したがって、a に入る語句は
   － ブルートフォース攻撃
   となります。

誤りやすいポイント

• 「辞書攻撃」と混同しやすい
  辞書攻撃は頻出単語リストを使う方法であり、“考えられる全て”という表現には合致しません。
• 「パスワードリスト攻撃」との取り違え
  既に漏えいしたID／パスワードの組合せを試す手法で、本問の説明とは異なります。
• “DoS 脆弱性”や“総当たり DoS”と誤解
  文脈はIDとパスワードの試行であり、サービス妨害ではなく認証突破が主目的です。

FAQ

解答の論理構成

1. 問題文の該当箇所を確認
   – 「SSH利用時には公開鍵認証でログインするので、bがなければ、Webサーバへのaを成功させることは困難である。」
   ここで鍵となるのは “公開鍵認証” というキーワードです。
2. 公開鍵認証の仕組みを整理
   – クライアント側は “秘密鍵” を保持し、サーバ側に “公開鍵” を登録します。
   – 認証時、サーバは公開鍵で署名検証を行うため、攻撃者がログインを試みても秘密鍵がなければ認証に失敗します。
   – よって、公開鍵認証において “攻撃を防ぐ要素” は 秘密鍵 です。
3. 文脈との整合
   – 直前で説明されている攻撃 “a” は「IDを固定して、考えられる全てのパスワードを試行する」すなわち総当たり攻撃（ブルートフォース）。
   – 公開鍵認証ではパスワードを使わないため、攻撃者が“秘密鍵”を持たない限り総当たり攻撃は成立しません。
4. 結論
   – したがって “b” に入る語は「秘密鍵」となります。

誤りやすいポイント

• パスワードを入力しない＝「パスワード」が不要と短絡し、b に「パスワード」と書いてしまうケース。公開鍵認証の本質を取り違えています。
• 公開鍵と秘密鍵を混同し、「公開鍵」と記入してしまうケース。サーバに登録して誰でも取得できる公開鍵では、攻撃防御の役割を果たしません。
• SSH＝暗号化とだけ理解し、鍵ペアの必要性を意識しないまま回答を決めてしまうケース。

FAQ

解答の論理構成

1. 【問題文】では、管理者用ログイン画面を直接インターネット公開するのではなく、 “インターネットから管理者用ログイン画面にアクセスする場合は、SSHを利用することにした”
   とし、さらに
   “②サイト担当者のPCの任意の通信ポートとミドルウェアの管理画面が動作している通信ポートとの間を暗号通信させる”
   と記述しています。
2. SSH には、ローカル側で開けた任意ポートとリモート側ポートを暗号化トンネルで接続し、あたかもローカルにサービスがあるかのように利用できる機能があります。
3. この機能を使えば、管理画面のポートを外部に公開せずに済み、トンネル経由（公開鍵認証）でのみアクセスが可能になるため、【問題文】中の“IDを固定して…全てのパスワードを試行する”ブルートフォース攻撃を防止できます。
4. 以上より、下線②が示す SSH の機能は「ポートフォワーディング」と判断できます。

誤りやすいポイント

• 「公開鍵認証」と勘違いする
  → 下線②は“通信ポート間を暗号通信させる”仕組みであり、認証方式そのものではありません。
• 「トンネリング」「SSHトンネル」など別名で書く
  → 用語として最も一般的で、問題集でも採用されやすい表記は「ポートフォワーディング」です。
• VPN と混同する
  → VPN はネットワーク層全体を延伸するのに対し、ポートフォワーディングは指定ポートの TCP 通信だけを転送します。

FAQ

解答の論理構成

1. 図4のリクエストには、URLパスにセッション ID が埋め込まれている。
     引用：図4 行1「GET /brandbeta/login;jsessionid=65H3809KCGO30CPGCDHJ4PJ369H62OP7 HTTP/1.1」
2. 図5のレスポンスでは、同一値のセッション ID を Set-Cookie ヘッダでブラウザへ返している。
     引用：図5 行4「Set-Cookie: JSESSIONID=65H3809KCGO30CPGCDHJ4PJ369H62OP7; Domain=www.j-sha.jp; Path=/brandbeta/; Secure」
3. 利用者が指定したセッション ID をサーバがそのまま正式な ID として発行する動作は、攻撃者が任意の ID を固定して利用者に使わせる“セッション ID の固定化”を引き起こす。
4. したがって「リクエストのURLに含まれていたセッションIDを、レスポンスでクッキーとして発行していた」という指摘が妥当である。

誤りやすいポイント

• Set-Cookie が返ること自体は正常動作と誤解し、リクエスト由来の ID かどうかを確認し忘れる。
• URL に付与された ;jsessionid= を「トラッキング用」などと勘違いし、脆弱性と結び付けられない。
• “セッション固定化”と“セッションハイジャック”を混同し、原因と結果を逆に説明してしまう。

FAQ

解答の論理構成

1. 図9の入力フォーム部分を確認すると、 行46に
   “”
   とあり、type・name・value がすべて 二重引用符付きで囲まれています。
2. これに対し行74は
   “”
   と、type・name・value の各属性値が引用符で囲まれていません。
3. 属性値が引用符で囲まれていない場合、半角空白で区切って任意の JavaScript イベント属性（例：onmouseover）を追加でき、a＝“クロスサイトスクリプティング”で示される攻撃が成立しやすくなります。
4. したがって、Y氏が XSS の可能性を直感したのは 行番号「74」 であり、理由は 「value値が二重引用符で囲まれていなかったから」 となります。

誤りやすいポイント

• 行50にも空の value="" があり紛らわしいが、引用符は付いているため XSS とは直接関係しない。
• 「空欄だから危険」と誤解し、行50を選んでしまうケースが多い。重要なのは 引用符の有無。
• Cache-Control: private や autocomplete="off" などヘッダ・属性ばかりに目が行き、HTML 属性の書式を見落とすミス。

FAQ

解答の論理構成

1. βサイトで検出された脆弱性の一つは、表4 項番3の“キャッシュへのコンテンツ残留”です。
2. 原因は、図9 行4に示されている現在のヘッダが“Cache-Control: private”となっており、 　“Cache-Controlヘッダでの制限が不適切なことが図9から確認できます”と問題文が指摘している点にあります。
3. “キャッシュに一切残さない”ことを明示する最も厳格な指示は“Cache-Control: no-store”です。HTTP/1.1 仕様において no-store は「レスポンスを含むどの情報も、いかなるキャッシュにも保持・再利用させない」ことをクライアントと中継キャッシュに命令します。
4. 他の選択肢の効果
   　ア “max-age=10800” … 3時間は保持可。残留の根本対策にならない。
   　ウ “no-transform” … 圧縮や画像変換の禁止であり保存可否とは無関係。
   　エ “public” … 共有キャッシュも保存可にする逆効果。
5. よって、ブラウザのキャッシュに一切残させないために出力すべきヘッダは“Cache-Control: no-store”であり、解答群の記号は「イ」となります。

誤りやすいポイント

• no-cache と no-store の混同
  no-cache は再利用前の再検証を要求するだけで保存自体を禁止しません。完全排除は no-store です。
• private を「安全」と誤解
  private は共有キャッシュを禁止するだけでローカルブラウザには保存を許可します。
• 有効期限を短くすれば良いと考える誤認
  max-age で 0 や短時間にしても、その期間中は残留します。共有 PC では閲覧直後に覗かれる危険が消えません。

FAQ

解答の論理構成

1. XSS は「入力値がそのままレスポンスに埋め込まれる」ことが本質です。問題文には
   “表6の項番5の“新規会員本登録（2）”画面の出力で二つのパラメタにスクリプト及びタグが挿入可能”
   とあります。
2. どのパラメタかを探るため、挿入元（リクエスト）と表示先（レスポンス）を確認します。
   • 項番2 の POST データ：
     “action=input&ID=taro&mail=taro@xx.yy”
   • 項番5 の画面出力：
     “ユーザID taro”
     “メールアドレス taro@xx.yy”
3. これらはどちらもユーザ入力値がそのまま表示されています。もし入力を
   “a onmouseover=alert(document.cookie);”
   に変えても画面に反映されうるため、XSS の対象となります。
4. よって、挿入可能だったパラメタは POST データに現れる
   “ID” と “mail” です。

誤りやすいポイント

• “ユーザID” と画面に書かれているのでパラメタ名を “user” と思い込む。実際の POST データでは “ID” が使われています。
• トークン “c_token” や “c_token2” はサーバ側発行値なので XSS とは無関係です。
• “name” や “address” なども入力値ですが、XSS が報告されたのは項番5 の二つだけという記述を読み落とさないようにしましょう。

FAQ

解答の論理構成

1. 図3の仕様には、診断対象パラメタの条件として
   “6. パラメタについての条件　診断対象画面に存在する全てのパラメタのうち、入力した値が次画面で取り扱われるものだけ診断可能”
   と明記されています。
2. γサイトの新規会員登録機能では、表6の項番5 “新規会員本登録 (2)” 画面でスクリプトが混入しましたが、これは「次画面」ではなく“同じ画面”で反映されるケースでした。
3. よって、自動診断ツールは当該パラメタを検査対象にできず、XSSを検出できなかったことになります。
4. 以上から、模範解答のとおり「入力値が次画面で利用される場合に限り診断する」という仕様上の限界が原因だと導けます。

誤りやすいポイント

• 「巡回できる画面だけ診断可能」という条件（図3‐5）を主因と誤解しやすいですが、本件はパラメタ条件が本質です。
• “確認画面”や“同一画面再表示”など、入力値が即座に反映されるパターンをツールが必ず検査すると思い込むと失点します。
• XSS対策＝入力時のサニタイズだけと理解し、表示時のエスケープ漏れにも注意が必要だという指摘を見落としやすいです。

FAQ

解答の論理構成

• 表3の項番1は“サービス妨害の脆弱性”であり、「数か月前に公表された脆弱性であった。J社では脆弱性情報を入手しておらず、ミドルウェアに修正プログラムを適用していなかった」と明記されています。
  ➔ 公開情報を継続的に収集・対応しなかった点が残存要因です。
• さらにJ社は「3年前から…自動診断ツールを用いて…脆弱性の有無を確認」していますが、これは“サイト開設時及び再構築時”に限られ、ツール自体の更新頻度も示されていません。
  ➔ 運用後の定期診断やツールのアップデートが不足していると判断できます。
• 以上より、①脆弱性情報の定期収集とパッチ適用、②診断ツールの最新化と定期診断――の二点が改善策として導かれます。

誤りやすいポイント

• 「チェックシートがあるから十分」と思い込み、外部公開後の運用監視を忘れる。
• 自動診断ツール＝万能と誤解し、シグネチャ更新やバージョンアップを怠る。
• パッチ適用を“開発部門の責任”と決め付け、運用部門での継続的管理を設けない。
• 新規構築時のみ診断を実施し、“運用フェーズの脆弱性”を想定しない。

FAQ

解答の論理構成

1. 原因の特定
   • 【問題文】には、γサイトで“開発業者にチェックシートの利用を要求していたが、ブログラマがそれぞれの解釈でコーデイングしたため、エスケープ処理に一部漏れがあるプログラムが作られてしまった”とあります。
   • つまりチェックシートは配布されていたものの、“それぞれの解釈”という属人的運用が品質低下の主因です。
2. 是正方針の抽出
   • 属人的な解釈を排除し、一律・具体的なルールで実装させる必要があります。
   • そこで“チェックシート”の要求事項を平易かつ具体的にプログラマへ落とし込む手段として“コーディング規約”が最適です。
3. 解答の導出
   • 上記より、製造工程では「チェックシート → コーディング規約 → 実装」へと要求をブレークダウンさせる仕組みが不可欠となります。
   • よって「チェックシートに基づきコーディング規約を整備する。」が適切な改善策となります。

誤りやすいポイント

• 「テスト工程で検出できなかったのが問題」と短絡し、製造工程の課題を見落とす。
• コーディング規約を作るだけでなく“チェックシートとの対応付け”が必要である点を忘れる。
• XSS対策＝入力エスケープと誤解し、出力時エスケープの重要性に触れない。

FAQ