【令和4年春期 午後Ⅱ】情報処理安全確保支援士 問題別・学ぶべき知識（Web脆弱性診断・クラウドID連携）

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

午後Ⅱ 問１　Webサイトのセキュリティ

• 仕組み・要点

  topicを内部向けURLへ変えるSSRF、returnURLを攻撃者サイトへ変えるオープンリダイレクト、外部サイトのフレームから操作させるクリックジャッキングなど、改ざんする入力と到達先から脆弱性を特定する

• 対策・確認

  returnURLは固定し、X-Frame-Options又はCSP frame-ancestorsで外部フレームを拒否する。

  自動診断が見落とすセッション管理・認可は、別利用者のIDや欠落パラメータを送る手動診断で確認する

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

  設問1：

  (1) サイトBではGETメソッドのクエリパラメータを受け取ってHTML属性値内に出力していたため、ダブルクォートで属性値を脱出してタグを挿入する文字列（ア）を送信します。

  (2) OSSライブラリの利用に際し、信頼できる公式サイトやリポジトリから入手することをルール化し、既知の脆弱性（CVE）情報を事前に調査・管理するプロセスを導入します。

  設問2：

  CSRFトークンは、攻撃者が推測・入手できないように「ログイン中の利用者ID」や「サーバー側のセッションオブジェクト」と厳密にひも付けて検証する必要があります。

  設問3：

  (1) クリックジャッキングは、透明（h: イ）にした対象サイト（c: β）を手前（g: イ）に重ね、奥（d: ア）にある可視の（e: ア）おとりボタン（f: α）をクリックさせようとする攻撃です。

  (2) iframeによる他サイトからの埋め込みを禁止・制限するレスポンスヘッダは「X-Frame-Options（エ）」および「Content-Security-Policy（イ: frame-ancestorsディレクティブ）」です。

  設問4：

  SSRF（Server-Side Request Forgery）の検証として、外部URLを指定するtopicパラメータの値を、社内専用のDBサーバの内部URLに変更してリクエストを送信しました。

  設問5：

  (1) P社宿泊サイトがリダイレクト先（Locationヘッダ）にHostヘッダ由来のURLを指定したため、サイトZは攻撃者（V氏）が用意したサイトへ自動的にリクエストを転送してしまいました。

  (2) リクエストパラメータやHostヘッダに依存せず、リダイレクト先やコールバックURL（returnURL）をアプリケーション側で固定値として定義・検証します。

  設問6：

  (1) 静的コード解析や自動スキャナでは業務ロジックや権限モデルの文脈を理解できないため、認可不備（他人のデータ閲覧・操作）や複雑なセッション管理不備は専門家による手動診断が必要です。

  (2) 半年に1回設けられている1か月間の休止期間（Webサイトの点検期間）を活用して専門家による診断を集中的に実施します。

  (3) 診断が必要な重要機能のリリース間隔を調整・延長したり、診断期間を組み込んだスプリント計画を策定します。

  (4) フレームワークが自動的にCSRFトークンを生成・セッションと紐付け、フォーム内にhidden要素として埋め込み、POST時に自動検証する機能です。

午後Ⅱ 問２　クラウドサービスへの移行

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

  起点：攻撃者がCDNと同じ共有IPを使う別サイトを経由

  攻撃の進行：IP許可だけをすり抜けてオリジンへ到達する

  結果・補足：CDN固有のHostヘッダや接続先SNIを検証し、オリジンをCDN経由通信だけに制限する

• 対策・確認

  SAMLResponseは署名を検証して偽造アサーションを拒否する。

  OAuthはstateでログインCSRF、PKCEで認可コード横取りを防ぎ、OIDCはIDトークンの署名・aud・nonceを検証して認証要求との対応を確認する

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

  設問1：

  (1) CDNのエッジサーバにコンテンツをキャッシュすることでオリジンサーバの負荷を軽減します。

  (2) 大量のリクエストを分散吸収することでDDoS攻撃（分散サービス不能攻撃）への耐性を高めます。

  (3) HTTP/1.1の仮想ホスト識別ヘッダは「Host」ヘッダです。

  (4) CDNでは単一のエッジIPアドレスを多数の顧客サイトで共有（マルチテナント）しているため、IPアドレス単位で遮断すると同一IPにホストされている他の無関係な正常Webサイトまで閲覧不能になります。

  (5) SNI（Server Name Indication）はTLSハンドシェイク時にクライアントが送信する「接続先サーバ名（ホスト名）」です。

  設問2：

  (1) Kerberos認証において、クライアントは取得したST（Service Ticket）を直接対象のサービスサーバ（GrWサーバ）に送信して提示するため、サービスアクセス時に認証サーバ（KDC）との通信は発生せず、認証サーバ側では不正利用を検知できません。

  (2) 攻撃者は手元に入手したチケット（暗号化データ）に対して自身の計算環境でオフライン総当たり解析を行うため、認証サーバにログイン試行が届かず、オンラインのアカウントロック機構が作動しません。

  設問3：

  (1) SP-Initiated SAML Redirectバインディングでは、IdPへのGETリクエストの「クエリ文字列」にSAMLRequestをエンコードして付加します。

  (2) SAMLのIdP（Identity Provider）としてクラウド認証基盤である「IDaaS」へアクセスします。

  (3) SAMLResponseに含まれるデジタル署名を検証し、アサーションが「偽造」・改ざんされていないことを確認します。

  (4) SAML認証で保護・管理対象となる認証ステップの番号です。

  設問4：

  (1) クライアントが「Sサービス（k: ウ）」、認可サーバが「IDaaS-G（l: イ）」、リソースサーバが「GrW-G（m: ア）」です。

  (2) OAuth 2.0認可コードフローにおける正しいリダイレクトおよびバックチャネル連携フローを選択します。

  (3) CSRF対策のstateパラメタは認可リクエストである「(2)」で送信し、コールバックである「(6)」で受信して一致検証します。

  (4) ネイティブアプリ等で認可コード横取りを防ぐ標準仕様は「PKCE（Proof Key for Code Exchange / RFC 7636）」（ウ）です。

  設問5：

  (1) RPが「X社動画サーバ（r: オ）」、OPが「T社認証サーバ（s: エ）」、リソースサーバが「T社投稿サーバ（t: ウ）」です。

  (2) 認可コードフローにおいてIDトークンはトークンエンドポイントからのトークンレスポンス「(8)」で返却されます。

  (3) JWT（JSON Web Token）のヘッダ・ペイロード・署名は「base64url」（イ）でエンコードされます。

  (4) リプレイ攻撃対策として、RPが「認証要求（w）」にnonce値を含めて送信し、返却された「IDトークン（x）」内のnonceクレームを検証します。