【令和7年春期 午後】情報処理安全確保支援士 問題別・学ぶべき知識（サプライチェーン・脆弱性優先度・モバイル・ASM）

令和7年春期 午後で問われたサプライチェーン・脆弱性優先度・モバイル・ASMの知識を、攻撃・影響・対策の流れと、全設問で必要になる補足知識に分けて整理します。

午後 問１　サプライチェーンのリスク対策

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

  起点：Webサイトが外部配布元のスクリプトを直接読込み

  攻撃の進行：配布元又は再委託先の侵害で悪性コードへ差替え

  結果・補足：利用者ブラウザで実行される。外部スクリプトを依存資産として台帳化し、不要なら削除、必要なら自社サーバへ固定版を配置する

• 対策・確認

  委託契約で再委託先にも同等の対策を要求し、SBOMで製品・部品・バージョンから影響範囲を即時検索できるようにする。

  静的検査はローカルコミット時に早期実行し、CI/CDでも必須ジョブとして自動実行する

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

  設問1：

  設問1(1)：

  セキュリティ・バイ・デザイン（Security by Design）とは，情報システムの企画・要件定義・設計段階からセキュリティ要件を組み込み，手戻りを防ぐアプローチです。

  設問1(2)：

  サプライチェーンの安全性を担保するため，再委託先に対しても直接の委託先と同等のセキュリティ管理要件の順守を義務付ける条項を契約に明記します。

  設問2：

  設問2(1)：

  外部サーバから都度読み込むのではなく，スクリプトを自社管理下のサーバにダウンロードして配置（セルフホスティング）することで，外部サーバの改ざん影響を遮断できます。

  設問2(2)：

  古いブラウザのサポート終了に伴い，該当スクリプトの読み込みコードをソースコードから完全に除去しました。

  設問2(3)：

  表1の項番1の情報資産一覧に，連携している外部サービス（外部スクリプト・API等）を追加し，SBOMに含まれない外部依存も把握できるようにしました。

  設問3：

  (1) 表1の工程と項番を表2の対象欄へ対応させると，SBOMは10，委託先一覧は4，設計確認は5，リリース管理は11となります。

  (2) 共用アカウントでは実際の利用者を特定できず，責任追跡性を確保できないためaは問題です。bは資産台帳でサーバ・機器を管理しており，cは要件定義・設計段階で欠陥を確認しているので，いずれも問題ありません。

  設問4：

  設問4：

  SBOM（ソフトウェア部品表）により，システムに組み込まれている全OSS・ライブラリの構成とバージョンが可視化され，新脆弱性（CVE）公開時に自社システムが影響を受けるかを迅速・機械的に特定できます。

  設問5：

  設問5(1)：

  開発LAN上の全サーバにアクセスする中継点である「踏み台サーバ」でアクセスログを一元取得します。

  設問5(2)：

  (あ)のローカルコミット時は開発者自身による迅速な手戻り修正が可能であり，(い)のCI/CD実行時はマージ後の自動検査として検査漏れを防止できます。

午後 問２　公開サイトの脆弱性診断と対応優先度判断

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

  起点：推測可能なitem値へ真偽条件を変えたSQLを送信

  攻撃の進行：応答差からブラインドSQLインジェクションを確認

  結果・補足：実データを抽出される。SSHは認証タイムアウトの多発を通知し、公開管理系にはクライアント証明書を要求する

• 対策・確認

  CVSS 4.0の環境要件で自組織の影響を補正し、FIRST公開のEPSSを継続監視する。

  診断で実際に悪用できた脆弱性、KEV掲載、外部公開の有無を机上スコアより優先して修正順を決める

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

  設問1：

  表1は，コンテンツ番号がない場合又はSQL構文エラーの場合に同じメッセージを返す仕様を使ったブラインドSQLインジェクションの確認です。

  aは単独の引用符で構文エラーになります。bとcも数値型の値へ不正な引用符を続けるので構文エラーとなり，a〜cはいずれもアです。dはAND 1=0で条件が偽になり該当行がないためア，eはAND 1=1で元の条件が成立するためイです。

  設問2：

  構成を変更していなくても，初回診断後に新たな脆弱性が発見されれば検出結果は変わります。またP社はCVSS基本値を独自の知見で補正するため，リスクが変化したと再評価して値を変更した場合も結果が変わります。

  設問3：

  (1) CRYPTRECのTLS暗号設定ガイドラインにおいて、ECDHEは128ビットセキュリティ以上を満たす楕円「曲線」、DHEは112ビットセキュリティ以上を満たす「鍵長」（2048ビット以上）が推奨基準となります。正解はウです。

  (2) 攻撃が行われるとOpenSSHログに「Timeout before authentication」が短時間に多数出力されるため、これを検知してアラート通知することで早期対応が可能です。

  (3) アクセス元の端末を限定・特定する対策として、クライアント証明書等を用いた「クライアント認証」が適切です。

  設問4：

  (1) WA-1は5桁の連番パラメータを変更するだけで容易に攻撃可能なためAC: L（Low）です。

  一方WB-1はランダムな英数字を含む推測困難なURL（administrator0001等）を事前に入手する必要があるため、攻撃条件の複雑さが高くAC: H（High）となります。

  (2) サイトCの仕様項番3「Webアプリケーションプログラムは，一般利用者権限の専用アカウントでプロセスを実行している」により、OSコマンドインジェクションが発生しても管理者権限操作は実行できません。

  設問5：

  (1) CVSSの現状値はPoCや攻撃コードの公開状況、対策パッチの有無などを調査・評価する必要があるのに対し、EPSS（Exploit Prediction Scoring System）はFIRST等が日々算出・公開しているスコア（0〜100%）をAPI等で直接参照できるため手間がかかりません。

  (2) 脆弱性の悪用確率は日々変動するため、公開後もEPSS値を継続的にモニタリング（監視）することが重要です。

  (3) P社の診断は単なるスキャンにとどまらず「実際に悪用可能であること」を実証して報告するため、悪用確率が高い（しきい値B超え）とみなすのが妥当です。

  設問6：

  表6の対応優先度マトリクスに基づき、1次評価領域とCVSS環境値を照合して優先度を決定します。

  ・m (PB-1): 領域I (EPSS 39% >= 1%, 基本値 8.1 >= 7.0) × 環境値 8.1 (7.0〜8.9) → A

  ・n (PC-1): 領域I (EPSS 96.5% >= 1%, 基本値 7.4 >= 7.0) × 環境値 7.4 (7.0〜8.9) → A

  ・o (PD-1): 領域IV (EPSS 0.0% < 1%, 基本値 5.7 < 7.0) → C

  ・p (PD-2): 領域I (EPSS 2.6% >= 1%, 基本値 8.1 >= 7.0) × 環境値 8.1 (7.0〜8.9) → A

  ・q (PE-1): 領域II (EPSS 8.7% >= 1%, 基本値 6.5 < 7.0) × 環境値 6.5 (4.0〜6.9) → B

  ・r (WA-1): 領域II × 環境値 4.3 (4.0〜6.9) → B

  ・s (WB-1): 領域II × 環境値 7.1 (7.0〜8.9) → A

  ・t (WC-1): 領域I × 環境値 9.8 (9.0〜10.0) → S

午後 問３　スマートフォンアプリの脆弱性対策

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

  起点：APKとHTTPS通信を解析

  攻撃の進行：アプリ内の暗号化アクセスキー、共通鍵、初期ベクトルを回収・復号

  結果・補足：AuthorizationヘッダでAPIへ接続し、連番注文番号からファイルを列挙取得する

• 対策・確認

  長期アクセスキーをアプリへ埋め込まず、サーバが対象ファイルだけの短期署名付きURLを発行する。

  証明書検証を無効化せず、WebView呼出し前にURLを構文解析してscheme・host・portを完全一致で許可する

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

  設問1：

  (1) 方式aはアクセスキーをAuthorizationヘッダーへ設定するため，通信を解析すればそこから取得できます。

  (2) 方式aでは暗号文・復号鍵・初期ベクトルが全てFアプリ内にあるので，アプリを解析して取り出し，AES-CBCで復号できます。

  (3) ファイル名は8桁の注文番号から成るため，00000001から順に変えて試行できます。

  (4) urlクエリパラメータへ攻撃者サイトを指定すればWebViewはそこへアクセスします。

  正規ドメイン文字列を攻撃者ドメインの前又はuserinfo部へ置く二例は図7の先頭一致も通り，攻撃者ドメインを直接指定する例も攻撃者サイトへのアクセス条件を満たします。

  設問2：

  (1) A社WebサーバのFQDNである「www.a-sha.co.jp」がSAN（Subject Alternative Name）として設定されます。

  (2) HTTPSプロキシ経由のTLSトンネリング手順です。

  ・a: プロキシに対するCONNECTメソッド（CONNECT www.a-sha.co.jp:443 HTTP/1.1 → オ）

  ・b: プロキシからの成功応答（HTTP 200 OK → ケ）

  ・c: TLSハンドシェイク開始（Client Hello → ウ）

  ・d: サーバからの応答（Server Hello → コ）

  ・e: サーバ証明書の送付（Certificate → ア）

  ・f: 証明書検証メッセージ（Certificate Verify → イ）

  ・g: ハンドシェイク完了（Finished → カ）

  ・h: アプリケーション層リクエスト（GET /campaign/... → キ）

  (3) 自己署名・プライベートCAによる中間者プロキシの証明書エラーを正規に解決するため、端末に該当CAのルート証明書をインストールして信頼済みルートとして登録します。

  設問3：

  署名付きURLは注文番号が確定した後，Fアプリへ通知する前に生成する必要があります。図4では注文内容をDBへ登録して注文番号を採番した直後の(い)が該当します。

  設問4：

  (1) WebViewには通常のブラウザのように接続先URLを確認する表示がなく，利用者が偽サイトを判別できません。

  (2) getToken関数の内部だけで確認すると，WebView表示時点では偽サイトへ遷移できます。WebViewを呼び出す前にURL先頭が指定の https://www.a-sha.co.jp/ かを検証します。

午後 問４　未把握の公開IT資産管理と脆弱性管理

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

  起点：廃止した外部サービスへのCNAMEだけが権威DNSに残る

  攻撃の進行：第三者が参照先サービスを再契約

  結果・補足：正規サブドメインで偽コンテンツを公開する。サービス終了と同時にCNAMEを削除し、反映確認まで行う

• 対策・確認

  WHOIS・DNS・証明書・外部観測から台帳外資産を発見し、ポートスキャンで公開サービス、脆弱性スキャナーで欠陥を確認する。

  継続する資産は停止して修正後に再開し、不要資産は切離して廃棄する

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

  設問1：

  CDNサービス解約後にサブドメインのDNSレコード（CNAMEレコード等）が残存していると、第三者が同一のCDNリソースを取得してサブドメインを悪用する「サブドメインテイクオーバー」の脆弱性が発生します。

  そのため、図1の権威DNSサーバにおいて、解約済みCDNを指している該当サブドメインのCNAMEレコードを削除する設定変更を行う必要があります。

  設問2：

  (1) 表1で台帳登録の対象外になっているのは，レンタルサービスと他社データセンターを契約して利用した公開IT資産です。

  (2) RFC 3912で定義された登録情報照会プロトコルはWHOISです。

  (3)(4) まずZサービスへV社を入力してFQDNとGIPを得ます。次にFQDNはXサービスでドメイン名と担当者識別番号を，GIPはYサービスで同じ情報をたどるため，あ＝Z，い＝X，う＝Y，d＝オ，e＝ア，f＝イ，g＝ク，h＝キです。

  設問3：

  (1) Webだけが公開されていることは，ポートスキャンでWebのポートだけが開いているかを確認します。

  (2) 内在する脆弱性は脆弱性スキャナーで確認します。

  (3) 継続利用する場合も，脆弱な状態のまま公開せず，一旦停止して修正後に再開します。利用しない場合は速やかにネットワークから切り離し，機器を廃棄します。

  設問4：

  (1) CVSSの当時の最新バージョンは4.0です。

  (2) KEVのフルスペルはKnown Exploited Vulnerabilities catalogなので，選択肢ウです。

  (3) KEV掲載の主な条件は，脆弱性が実際に悪用されたことです。

  (4) 情シ部が台帳上のSWを継続監視し，重要な脆弱性を見付けたら保有部門へ優先度を連絡して，対策の実施まで確認する流れに改めます。