【令和5年春期 午後Ⅱ】情報処理安全確保支援士 問題別・学ぶべき知識（Web診断設計・クラウド移行・OAuth連携）

令和5年春期 午後Ⅱで問われたWeb診断設計・クラウド移行・OAuth連携の知識を、攻撃・影響・対策の流れと、全設問で必要になる補足知識に分けて整理します。

午後Ⅱ 問１　Webセキュリティ

• 攻撃・原因 → 影響（成立の流れ）

  起点：自動診断が通常遷移だけを巡回

  攻撃の進行：直接URL、1会員1回の申込み、5回失敗でロックされる画面を未検査

  結果・補足：設計書から状態遷移と制約を洗い出し、専用アカウントと手動リクエストで補う

• 対策・確認

  CookieのHttpOnly/Secure/SameSite、偽入力フォームを作るXSS、group_code欠落時の認可を個別に確認する。

  各社のWeb資産と問合せ窓口を共通台帳へ集約し、診断漏れを防ぐ

  設問別の補足知識（全6設問）

  設問1：

  手作業で画面をたどるだけではURLを網羅できない。設計書には画面と遷移先が整理されているので，診断対象のWebサイトの設計書を確認する方法が該当する。

  設問2：

  (1) SQL文で常に真になる条件と偽になる条件を比較するため，aはイ，bはウとなる。

  (2)(3) XSSは入力値が二つ先の確認画面に出力されるため，(2-3)の拡張機能でアンケート確認のURLまでを判定対象に含める。

  (4) 0件では脆弱性を含む応答を比較できないので，検索結果が1件以上になる初期値が必要である。

  設問3：

  (1) JavaScriptで遷移先が生成される検索結果と，登録済みメールアドレスでは遷移できない新規会員情報入力が自動登録から漏れる。

  (2) (A)は連続失敗でアカウントがロックされ，(C)は1会員につき1回しか申し込めないため，同じ値の反復で遷移できなくなる。

  設問4：

  HttpOnlyはHTML内のスクリプトからcookieを読む操作を禁止する。一方，XSSでページ内容は操作できるため，偽の入力フォームを表示し，入力情報を攻撃者サイトへ送る攻撃は防げない。

  設問5：

  図5の正常な要求にはgroup_codeがあるが，図6では削除されて全グループのキャンペーンが返る。サーバはJSESSIONIDで会員を特定し，その所属グループとgroup_codeを照合する必要がある。

  設問6：

  (1) A社と同様にグループ各社も資産管理システムでWebサイト情報を管理すれば，診断準備の確認を短縮できる。

  (2) 問合せ窓口をA社の診断部門に集約し，回答をグループ内で共有すれば，同じ問合せの重複とチケット費用を抑えられる。

午後Ⅱ 問２　Webサイトのクラウドサービスへの移行と機能拡張

• 攻撃・原因 → 影響（成立の流れ）

  起点：攻撃者がOAuth認可コードを横取り

  攻撃の進行：自分の端末からアクセストークンへ交換

  結果・補足：クラウド資産を操作する。クライアントが生成したverifierとSHA-256のchallengeを結び付けるPKCEで交換を拒否する

• 対策・確認

  監査ログではsystem・account・service・eventを指定してオブジェクト削除を即時検知する。

  削除ファイルはOSS履歴から復元し、アップロード承認は開発リーダーだけ、CI用トークンはダウンロード権限だけに絞る

  設問別の補足知識（全5設問）

  設問1：

  IaaSではW社がOS・ミドルウェア，アプリ，アプリに登録されたデータを管理するので，a，d，gは○となる。

  PaaSではOS・ミドルウェアは事業者側だが，W社がアプリとそのデータを管理するので，bは×，e，hは○となる。

  SaaSではOS・ミドルウェアとアプリは事業者側であり，W社はアプリに登録されたデータを管理するので，c，fは×，iは○となる。

  設問2：

  (1) 表1の委託範囲から，仮想マシンは一覧確認だけなのでjはウ，DBサービスはD社が操作しないのでkはエ，性能監視には指標一覧と値の閲覧が必要なのでlはイとなる。編集権限は不要である。

  (2) 表5からログ保管ストレージのsystemは4000，表4からserviceとeventはオブジェクトストレージサービス／オブジェクトの削除となる。D社の利用者ID 1110〜1199は11[1-9][0-9]で表せる。

  設問3：

  (1) OAuth 2.0における各エンティティの役割を判別します。 ・m: 会員が直接アクセスし、サービス連携を行うクライアントである「新日記サービス」です。

  ・n: 会員の認可を受けて認可コードおよびアクセストークンを発行する認可サーバ「サービスT」です。 ・o: 会員の日記記事が投稿される対象のリソースサーバ「サービスT」です。

  (2) 表8のHTTPリクエスト内容から、図3のシーケンス番号を特定します。

  ・p: `GET /authorize?response_type=code...` はブラウザから認可エンドポイントへの認可要求であり、シーケンスの「(3)」に対応します。

  ・q: `POST /oauth/token`（Basic認証ヘッダーとgrant_type=authorization_code付き）はクライアントからトークンエンドポイントへのアクセストークン要求であり、シーケンスの「(7)」に対応します。

  (3) CRYPTRECの電子政府推奨暗号リストにおける推奨外暗号技術の選定です。 ・ウの `3DES_EDE_CBC`（トリプルDES）はSweet32脆弱性等のブロックサイズ制約により非推奨（運用監視暗号）となっています。

  ・エの `RC4_128` および `MD5` は深刻な解読脆弱性が存在するため利用禁止・非推奨となっています。 ・アの `AES-GCM` およびイの `AES-CBC (SHA256)` は安全な暗号スイートとして推奨されています。

  したがって、利用を推奨していない暗号技術を含む暗号スイートは「ウ，エ」です。

  設問4：

  (1) OAuth 2.0認可コードグラントでは、認可サーバへアクセストークンを要求する際、直前のステップで認可サーバから発行された認可コード（`code` パラメータ）が必要です。

  攻撃者がクライアントIDとクライアントシークレット（エンコード値G）を入手しても、特定の会員が認可して発行された有効な `code` パラメータを横取り・取得できない限り、その会員のアクセストークンを取得することはできません。

  (2) PKCE (RFC 7636) の S256 (SHA-256) 方式における検証手順です。

  クライアントは事前に生成した `code_verifier`（検証コード）の SHA-256 ハッシュ値を base64url エンコードした `code_challenge`（チャレンジコード）を認可要求時に認可サーバに送付しています。

  アクセストークン要求時に送られてきた検証コードに対し、認可サーバ側で SHA-256 ハッシュ計算と base64url エンコードを行い、保存していたチャレンジコードと一致するかどうかを照合することで、正規のクライアントからの要求であることを検証します。

  設問5：

  (1) Gitなどのバージョン管理システム（サービスE）では、ファイルをワーキングツリー上で削除・コミットしても、過去のコミット履歴（変更履歴）内にファイルの内容がそのまま保持されます。

  OSSリポジトリは誰でも変更履歴のダウンロードが可能であるため、第三者は変更履歴を参照して削除前のファイルZを取得し、Xトークンを不正に入手しました。

  (2) 表9の従来の運用ルールでは「開発者自身がソースコードのアップロードとその承認の両方を実施できる」状態になっており、開発者全員に承認権限が付与されていました。

  不正なコードの混入を防ぐため、ソースコードを承認する承認権限は開発リーダーのみに制限し、開発者によるセルフ承認を禁止する変更を行います。

  (3) 表9の従来のCI連携設定では、X社CIに発行するXトークンに「リポジトリWの全ての権限（アップロード・承認・削除等）」が付与されていました。

  CIサービスがビルドと単体テストを実行するために必要なのはソースコードの取得のみであるため、最小権限の原則に従い、Xトークンには「ソースコードのダウンロード権限」のみを付与するように設定を見直します。