情報処理安全確保支援士 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に
   “<td align="center"><input type="text" name="name1" value="鈴木"></td>”
   とあり、type・name・valueがすべて 二重引用符付きで囲まれています。
2. これに対し行74は
   “<td align="center"><input type=text name=mbmail value=taro@mb.xx.yy></td>”
   と、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. 設問は「自動診断ツールの機能の限界」を問うています。まず、診断ツールの仕様とγサイトの画面遷移を対応させて考えます。
2. 図3に「診断対象画面に存在する全てのパラメタのうち、入力した値が次画面で取り扱われるものだけ診断可能」と明記されています。これは自動診断ツールが、ある画面で得られた入力値が「次画面」に反映されると判定できる場合に限ってそのパラメタを操作・検査する、という意味です。また図3は診断可能画面について「a) 巡回できる画面b) 同じ処理が繰返しできる画面」を満たす必要があるとしています。つまり「自動で到達（巡回）でき、かつ再現して試行できる画面」だけが完全に診断対象になります。
3. 表6の画面遷移を確認すると、項番3に「本登録に必要なURL（下記のURL）が記載された電子メールが送られる」、項番4に「電子メール中に記載された本登録に必要なURL（項番3の操作結果中のURL）にアクセスする」とあります。該当のXSSは表6の項番5の「新規会員本登録（2）画面の出力で二つのパラメタにスクリプト及びタグが挿入可能」で見つかっていますが、その画面へは電子メール中の個別URL（キー付き）で遷移する必要があり、自動探査の通常の巡回で発見・再現できない構造になっています。さらにメール中のURLはワンタイム／非公開のトークンを含む可能性が高く「同じ処理が繰返しできる画面」の条件も満たさないことが多いです。
4. 以上から、図3の仕様により自動診断ツールは当該パラメタを「次画面で取り扱われるもの」と認識できず、かつその画面が自動巡回・再現可能でなかったためにXSSを検出できなかったと結論できます。要点を一文で示すと、
   「パラメタについては入力した値が次画面で処理される場合にだけ診断可能である点」

誤りやすいポイント

• 「同じ画面で反映される／次画面で反映される」の区別を曖昧にする。多段フォームでは「確認画面」が別URLか同一URLかで自動診断の可否が変わる点に注意すること。
• 自動診断ツールがメール内のリンクやワンタイムキーを自動取得できると誤解する。メール遷移は自動巡回の対象外になりやすいです。
• 「全画面を診断した」という報告を「全てのフロー（ワークフロー）」を診たと取り違える。ページ単位の走査と、外部トリガを含むフローの診断は別です。
• ツール任せにして手動探査や設計レビューを省くと、今回のような検出漏れが起こりやすいです。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ