G 社は，ヘルスケアサービス新興企業である。利用者が食事，体重などを入力して，そのデータを管理したり，健康リスクの判定や食事メニューのアドバイスを受けたりできるサービス（以下，サービス Y という）を計画している。具体的には，クラウドサービス上にサービス Y 用のシステム（以下，S システムという）を構築して，G 社が既に開発しているスマートフォン専用アプリケーションプログラム（以下，G 社スマホアプリという）からアクセスする。S システムの要件を図1に示す。
図1 S システムの要件（抜粋）
G 社は，S システムの構築を IT ベンダー F 社に委託した。F 社との協議の結果，クラウドサービスプロバイダ E 社のクラウドサービス上に S システムを構築する方針にした。
〔API の設計〕
S システムには，将来的には他社が提供するスマートフォン専用アプリケーションプログラムからもアクセスすることを想定し，RESTful API 方式の API（以下，S システムの API を S-API という）を用意する。RESTful API の設計原則の一つにセッション管理を行わないという性質がある。この性質を a という。
E 社が提供するクラウドサービスのサービス一覧を表1に，サービス Y のシステム構成を図2に，S-API 呼出し時の動作概要を図3に，S-API の仕様を表2に，S システムの仕様を図4に，それぞれ示す。
表1 E 社が提供するクラウドサービスのサービス一覧（抜粋）図2 サービス Y のシステム構成図3 S-API 呼出し時の動作概要（抜粋）表2 S-API の仕様（抜粋）図4 S システムの仕様（抜粋）
〔脆弱性診断の結果〕
S システムの構築が進み全ての機能を動作確認できたので，G 社で S システムのセキュリティを担当する R さんが，セキュリティベンダーである U 社に脆弱性診断（以下，診断という）を依頼した。U 社による診断レポートを表3に示す。
表3 U 社による診断レポート（抜粋）
表3の項番1について，U 社のセキュリティコンサルタントで情報処理安全確保支援士（登録セキスペ）の Z 氏は，次のように説明した。
認証 API で，利用者 ID “user01”での認証が成功した後，診断中に発行された JWT のデコード結果は，表4のとおりであった。
表4 JWT のデコード結果（抜粋）
ここで，表4中の“RS256”の代わりに“NONE”を指定し，“user01”を他の利用者 ID に改ざんした JWT を送信したところ，改ざんした JWT の検証が成功し，他の利用者へのなりすましができた。
G 社は，試用モニターへのサービス Y の提供期間中に，インシデント対応に必要なログの取得方法を検討することになり，F 社と協議した。
F 社によれば，ログ取得モジュールを実装するには時間が掛かるが，ログ取得モジュールを実装しなくても，サービス N を導入することによって，通信ログを取得できるという。
サービス N における WAF ルールの記述形式を図5に示す。
図5 サービス N における WAF ルールの記述形式
R さんは，サービス N の S システムへの導入を責任者に提案し，承認を得た。サービス N の導入完了後，サービス Y の提供を開始した。
〔新たな脆弱性への対応〕
数週間後，ライブラリ H というオープンソースのライブラリに脆弱性 V という脆弱性があることが公表された。R さんは，脆弱性 V についての関連情報を図6のように取りまとめた。
図6 脆弱性 V についての関連情報（抜粋）
R さんは，脆弱性 V への対応方針を Z 氏に相談した。Z 氏は，F 社の回答を待ってからの対応では遅いので，システムに影響を与えない検証コードを S システムに対して実行し，外部から脆弱性 V を悪用できるか検証するよう提案した。R さんは，Z 氏の協力の下，図7に示す手順で検証を実施した。
図7 R さんが実施した検証手順図8 作成した検証コード
検証の結果，外部から脆弱性 V を悪用できることが確認できた。この結果を踏まえて，R さんは，脆弱性 V を悪用する攻撃に備え，E 社から WAF ルールが提供されるまでの間，現在判明している悪用パターンに対応可能な暫定的な WAF ルールで攻撃を遮断することにした。
R さんが考えた WAF ルールの案を表6に示す。
表6 WAF ルールの案
R さんは，例えば“jnDI”のように大文字・小文字を入れ替える手口によって，ルール1と2それぞれで，案のパターンを回避する方法があることに気付いた。④このような手口にも対応できるように案を変更した。その後，変更後の案の確認を Z 氏に依頼した。
Z 氏は，⑤本番運用開始後の一定期間においては，WAF ルールの動作には“検知”を設定して，サービス Y が今までどおり利用できるかを確認することを助言した。R さんは，Z 氏の助言を踏まえて，WAF ルールを設定した。
後日，S システムでは，ライブラリ H を利用しているとの回答が F 社からあった。また，E 社からサービス N における WAF ルールが提供された。その後，脆弱性 V を修正したバージョンがライブラリ H の公式 Web サイトで配布され，S システム内のライブラリ H のバージョンを最新にすることで，脆弱性 V への対応が完了した。
設問2(2)は，正答率がやや低かった。JSON Web Token（JWT）改ざんにおける検証方法を問うたが，既に実装されている対策を解答するなど，脆弱性を正しく理解していないと思われる解答が散見された。図4に示す仕様と表3に示す脆弱性を正しく理解してほしい。
設問2(3)40字以内
表5中の下線②について，P 呼出し処理に追加すべき処理を，40字以内で具体的に答えよ。
解答例
JWTに含まれる利用者IDがmidの値と一致するかどうかを検証する処理
解説
本文の根拠
表3 項番2
パラメータ mid に他の利用者 ID を指定すると，他の利用者 ID にひも付く利用者情報を取得，改変できてしまう。
図4 〔JWT を利用したアクセス〕
JWT 内の署名を検証した後，ペイロードに含まれた利用者 ID を確認して利用者を識別し，必要な情報を含めてレスポンスを返す。
表2 利用者 API
GET メソッドが使われた場合，パラメータ mid で指定された利用者 ID にひも付く利用者情報を含むレスポンスを返す。
利用者 API は，パラメータ mid で指定された利用者 ID の情報を読み書きする。一方，リクエストを送ってきたのが誰かは，署名を検証した JWT のペイロードにある利用者 ID で分かる。項番2の脆弱性は，この二つを照合せず，mid に他人の ID を入れるだけで他人の情報に届いてしまうことにある。
そこで P 呼出し処理に，JWT に含まれる利用者 ID と mid の値が一致するかを検証し，一致しなければ処理しない処理を追加する。JWT は署名で改ざんが検知できる（設問2(2)の修正後）ので，その利用者 ID は信頼でき，本人の情報にしかアクセスできなくなる。
共通モジュール P，及び共通モジュール P を呼び出す処理（以下，P 呼出し処理という）は，サービス L に定義されており，利用者ステータスの管理にも利用される。
表5 項番3
一方，実装は，指定されたパラメータを検証せず全て c に送信していた。
表2 利用者 API
PUT メソッドが使われた場合，パラメータ mid で指定された利用者 ID にひも付く利用者情報を更新する。
利用者 API の PUT で利用者情報を更新するのは共通モジュール P であり，P は“利用者ステータスの管理にも利用される”。P 呼出し処理が受け取ったパラメータを検証せずにすべて P に渡すと，仕様に無い status=paid を追加しただけで，P が利用者ステータスを有償利用者に書き換えてしまう。
したがって c は“共通モジュール P”である。リクエストの値をそのまま内部のデータ更新に流し込むことで，本来変更させない項目まで書き換えられる脆弱性（一般にマスアサインメントと呼ばれる）に当たる。
“表2中の用語で”という指定なので，“サービス M”や“データベース”ではなく，表2に出てくる“共通モジュール P”と書く。P 呼出し処理は送る側なので c には当たらない。
設問2(5)解答欄1つ
表5中の d に入れる適切な処理内容を，30字以内で答えよ。
〔d〕解答例
連続失敗回数がしきい値を超えたらアカウントをロックする処理
解説
本文の根拠
表5 項番4
d を実装する。そのしきい値は10とする。
表3 項番4
総当たり攻撃によって，文字列 X を使った認証メカニズムを突破できる。
項番4の脆弱性は，文字列 X を何度でも試せるために総当たりで当てられることである。“しきい値は10”という対策の記述から，試行回数に上限を設け，連続して失敗した回数がしきい値を超えたらアカウントをロックする（それ以上の試行を受け付けない）処理が d に入る。
d2dldCBodHRwOi8vYTIuYjIuYzIuZDIvaW5kZXguaHRtbA==のデコード結果は，wget http://a2.b2.c2.d2/index.html である。これは，コマンド C に相当する。
図6 (7)
攻撃対象サーバは，受信した LDAP レスポンスに記載された URL-J にアクセスし，J ファイルをダウンロードして，コマンド C を実行する。
検証コードで実行させるコマンド C は“wget http://a2.b2.c2.d2/index.html”であり，a2.b2.c2.d2 はテストサーバ自身の IP アドレスである。脆弱性 V が悪用できれば，S システムがこのコマンドを実行してテストサーバの index.html を取りに来る。
本番運用開始後の一定期間においては，WAF ルールの動作には“検知”を設定して，サービス Y が今までどおり利用できるかを確認する
図5
検知：通信を通過させ，ログに記録し，管理者にアラートを送信する。
図5
遮断：通信を遮断し，ログに記録し，管理者にアラートを送信する。
新しく作った暫定ルールは，正常なリクエストにも当たってしまう（誤検知する）おそれがある。最初から“遮断”にすると，誤検知した正常な通信まで止まり，サービス Y が使えなくなる。“検知”なら通信は通したまま記録とアラートだけが行われるので，誤検知による遮断を防ぎながら，ルールの当たり方を確かめられる。これが利点である。
H 社は，従業員 3,000 名の製造業であり，H 社製品の部品を製造する約 500 社と取引を行っている。取引先は，H 社に設置された取引先向け Web サーバに HTTPS でアクセスし，利用者 ID とパスワードでログインした後，H 社との取引業務を行っている。また，公開 Web サーバでは，H 社製品の紹介に加え，問合せや要望の受付を行っている。いずれの Web サーバが停止しても，業務に支障が出る。
H 社では，社内に設置している PC（以下，H-PC という）とは別に，一部の従業員に対して，VPN クライアントソフトウェアを導入したリモート接続用 PC（以下，リモート接続用 PC を R-PC という）を貸与し，リモートワークを実現している。R-PC と H 社との間の VPN 通信には，VPN ゲートウェイ（以下，VPN ゲートウェイを VPN-GW といい，H 社が使用している VPN-GW を VPN-H という）を使用している。
H 社のネットワークは，情報システム部の L 部長と T 主任を含む 6 名で運用している。H 社のネットワーク構成を図1に示す。
T 主任は，方法1については，VPN-H の認証強化を検討することにした。また，方法2については，VPN-H の脆弱性対策と，VPN-H へのポートスキャンに対する応答を返さないようにする方法（以下，ステルス化という）を検討することにした。方法1と方法2について T 主任がまとめた対策案を表3に示す。
表3 方法1と方法2について T 主任がまとめた対策案
〔DDoS 攻撃に対する調査〕
次に，T 主任は，DDoS に関連する攻撃について調査し，H 社で未対策のものを表4にまとめた。
表4 H 社で未対策の DDoS に関連する攻撃
次は，表4についての T 主任と L 部長の会話である。
T 主任：項番1，2，4の DDoS 攻撃のサーバへの影響は，UTM の IPS 機能と WAF 機能で軽減することができます。
L 部長：そうか。機能の設定に関する注意点はあるのかな。
T 主任：例えば，アノマリ型 IPS 機能で，トラフィック量について，しきい値が高すぎる場合にも，①しきい値が低すぎる場合にも弊害が発生するので，しきい値の設定には注意するようにします。また，項番3の対策として，現在の DNS サーバを廃止して，権威 DNS サーバの機能をもつサーバ（以下，DNS-K という）とフルサービスリゾルバの機能をもつサーバ（以下，DNS-F という）を社内に新設します。インターネットから社内への DNS 通信は b への通信だけを許可し，社内からインターネットへの DNS 通信は c からの通信だけを許可します。
〔対策 V-1 についての検討〕
次は，対策 V-1 についての L 部長と T 主任の会話である。
L 部長：対策 V-1 での注意点はあるのかな。
T 主任：最近は，多要素認証の利用が多くなってきたこともあり，多要素認証を狙った攻撃が発生しています。多要素認証を狙った攻撃例を表5に示します。
表5 多要素認証を狙った攻撃例
L 部長：攻撃例1については，不正なリモート接続を阻止するために，メールで受信したメッセージ内の URL リンクを安易にクリックしないよう注意喚起する必要があるな。
T 主任：はい。しかし，当社では，業務の手続の督促などで従業員に URL リンクが含まれるメールを送っているので，URL リンクのクリックを禁止することはできません。不審な URL かどうかを見極めさせることは難しいでしょう。そこで，②たとえ罠の Web サイトへの URL リンクをクリックしてしまっても，不正なリモート接続をされないように，従業員全員が理解できる内容を，注意喚起する必要があります。
〔対策 V-3 についての検討〕
次は，対策 V-3 についての L 部長と T 主任の会話である。
L 部長：対策 V-3 について説明してほしい。
T 主任：VPN-H には，どのような通信要求に対しても応答しない“Deny-All”を設定した上で，あらかじめ設定されている順番にポートに通信要求した場合だけ所定のポートへの接続を許可するという設定（以下，設定 P という）があります。
L 部長：設定 P の注意点はあるのかな。
T 主任：設定されている順番を攻撃者が知らなくても，③攻撃者が何らかの方法でパケットを盗聴できた場合，設定 P を突破されてしまいます。
L 部長：設定 P とは別の方法はあるのかな。
T 主任：VPN-H の機能にはありませんが，SPA（Single Packet Authorization）というプロトコルがあります。SPA の主な仕様を表6に示します。
表6 SPA の主な仕様
T 主任：SPA なら，④攻撃者が何らかの方法でパケットを盗聴できたとしても，突破はされません。
L 部長：そうか。VPN 通信機能と同様の機能をもち，SPA を採用している製品があるかどうか，ベンダーに相談してみよう。
L 部長がベンダーに相談したところ，S 社が提供しているアプライアンス（以下，S-APPL という）の紹介があった。L 部長と T 主任は，S-APPL の導入検討を進めた。
〔S-APPL の導入検討〕
S-APPL は，VPN 通信機能，SPA パケットを検証する機能などをもつ。S-APPL と接続するためには，S-APPL のエージェントソフトウェア（以下，S ソフトという）を接続元の PC に導入し，接続元の PC ごとの ID と秘密情報を，S-APPL と接続元の PC それぞれに設定する必要がある。なお，秘密情報は，SPA パケットの HMAC ベースのワンタイムパスワードの生成などに使われる。S-APPL と S ソフトの主な機能を表7に示す。
取引先は，H 社に設置された取引先向け Web サーバに HTTPS でアクセスし，利用者 ID とパスワードでログインした後，H 社との取引業務を行っている。また，公開 Web サーバでは，H 社製品の紹介に加え，問合せや要望の受付を行っている。いずれの Web サーバが停止しても，業務に支障が出る。
表4 項番1
公開 Web サーバ，DNS サーバを攻撃対象に，偽の送信元 IP アドレスとランダムな宛先ポート番号を設定した UDP データグラムを大量に送り付ける。
表4 項番4
HTTP GET Flood 攻撃，例 a。
HTTP GET Flood 攻撃は，Web サーバに HTTP の GET リクエストを大量に繰り返し送り，サーバの処理能力を使い果たさせてサービスを止める DDoS 攻撃である。L7（アプリケーション層）の攻撃なので，対象は HTTP（HTTPS）で応答するサーバになる。
H 社で Web サーバとして公開されているのは，公開 Web サーバと取引先向け Web サーバの二つで，冒頭に“いずれの Web サーバが停止しても，業務に支障が出る”とある。表4項番1の例にならい“○○を攻撃対象に，△△を送る”の形で，二つの Web サーバを攻撃対象として HTTP GET リクエストを繰り返し送る，と書く。
VPN ダイアログに利用者 ID とパスワードを入力し，その認証が完了すると，セキュリティコード入力画面が表示され，SMS でセキュリティコードがスマートフォンに送信される。送信されたセキュリティコードを，セキュリティコード入力画面に入力することで認証される。
表5 攻撃例1 (1)
攻撃者が，フィッシングメールを使って，VPN ダイアログの画面を装った罠の Web サイトに正規利用者を誘導し，正規利用者に利用者 ID とパスワードを入力させる。
表5 攻撃例1 (4)
攻撃者が，社内ネットワークに不正に接続する。
攻撃例1は，罠の Web サイトを正規利用者と正規の VPN-H の間に置き，入力された認証情報をその場で正規の画面に中継するフィッシング（リアルタイムフィッシング）である。(1)で利用者 ID とパスワードを得た攻撃者は，(2)でそれを正規の VPN ダイアログに入力する。認証が完了すると，表2の注1)のとおり正規利用者のスマートフォンに SMS でセキュリティコードが送られる。これが d である。
正規利用者は罠のサイトの続きとしてセキュリティコードの入力を求められ，受け取ったコードを罠のサイトに入力してしまう。攻撃者はそれを読み取り，正規のセキュリティコード入力画面に入力して認証を通す。これが e で，(4)の不正接続につながる。
TCP の SYN パケット又は UDP の最初のパケット（以下，SPA パケットという）には，HMAC ベースのワンタイムパスワードが含まれており，送信元の真正性を送信先が検証できる。
表6 項番3
SPA パケットの最後尾フィールドには先行フィールドのハッシュ値が格納されている。
設定 P が破られるのは，盗聴したものと同じ通信を再現できるからだった。SPA パケットは，ワンタイムパスワードとランダムデータを含むので毎回異なる（ユニークである）。送信先は以前受け取ったものと同じランダムデータをもつパケットを破棄する（項番2）ので，盗聴したパケットをそのまま送り直しても受け付けられない。
対応後，取引先は貸与された取引専用 PC から S-APPL の VPN を経由して取引先向け Web サーバにアクセスする。UTM ではインターネットから取引先向け Web サーバへの直接の通信を拒否するので，サーバはインターネットから直接接続される対象ではなくなる。
S-APPL では SPA で送信元の真正性を検証し，秘密情報をもつ取引専用 PC 以外の通信は破棄する。したがってボットネットなどからの攻撃の通信は取引先向け Web サーバに届かず，DDoS 攻撃の影響を更に軽減できる。解答例は“取引専用 PC 以外からの通信は到達しない”“ボットネットからの通信が遮断される”“外部からの接続対象サーバではなくなった”の三つを別解としている。
字数は40字以内（解答例は32〜34字）。どの別解でも，“取引先向け Web サーバに攻撃の通信が届かなくなる”ことを，その理由（取引専用 PC だけ・UTM で拒否）と一緒に書く。
出典：令和6年度 春期 情報処理安全確保支援士試験 午後 問2（表記を一部改変）
問3 Web セキュリティ
Web セキュリティに関する次の記述を読んで，設問に答えよ。
D 社は，従業員 1,000 名の小売業である。自社のホームページや EC サイトなどの Web サイトについては，Web アプリケーションプログラム（以下，Web アプリという）に対する診断（以下，Web アプリ診断という）を専門会社の Z 社に委託して実施している。Web アプリ診断は，Web サイトのリリース前だけではなく，リリース後も定期的に実施している。Z 社の Web アプリ診断は，脆弱性診断ツールによるスキャンだけではなく，手動による高度な分析も行う。
〔新たな Web サイトの構築〕
D 社では，新たに EC サイト X（以下，サイト X という）と商品企画サイト Y（以下，サイト Y という）を W 社が提供するクラウドサービス（以下，クラウド W という）上に構築することになった。
サイト X では，D 社が取り扱う商品をインターネットを介して会員に販売する予定である。取引は毎月 10,000 件ほどを見込んでいる。サイト Y では，サイト X で販売する新商品の企画・開発を顧客参加型で行う。サイト X とサイト Y は，いずれも Web サーバとデータベースサーバ（以下，DB サーバという）で構成する。Web サーバについてはクラウド W の仮想 Web サーバサービスを利用し，DB サーバについてはクラウド W のリレーショナルデータベースサービスを利用する。サイト X とサイト Y はいずれも，コンテンツマネジメントシステム（以下，CMS という）を使って構築される。サイト X とサイト Y にはいずれも，Web アプリ，HTML による静的コンテンツ，DB サーバに格納したデータを使った動的コンテンツなどを用意する。
D 社は，V 大学と新商品開発の共同研究を行っている。新商品開発の共同研究では，V 大学が運用する情報交換サイト（以下，サイト P という）を利用している。サイト Y は，サイト P で取り扱っている情報などを表示する。
D 社は，Web サイト構築に関連するデータやドキュメントの保存場所として，クラウド W のストレージサービス（以下，ストレージ W という）を利用する。
D 社は，サイト X 及びサイト Y の設計書を作成した。設計書のうち，サイト X，サイト Y 及びサイト P のネットワーク構成を図1に，サーバやサービスの説明を図2に示す。
図1 サイト X，サイト Y 及びサイト P のネットワーク構成図2 サーバやサービスの説明
〔サイト X〕
サイト X には，会員用の利用者アカウントと D 社管理者用の利用者アカウントがある。サイト X のログインセッション管理は，cookie パラメータの SESSIONID で行う。SESSIONID には，値と Secure 属性だけがセットされる。なお，サーバ側のセッションの有効期間は 24 時間である。設計書のうち，サイト X の機能一覧を表1に示す。
表1 サイト X の機能一覧（抜粋）
サイト管理機能は，D 社の内部ネットワーク以外からも利用する可能性があり，サイト X では，接続元の制限は行わない。
サイト X とサイト Y の構築は順調に進み，D 社はリリース前の Web アプリ診断を Z 社に委託した。Z 社は，サイト X とサイト Y それぞれに対して Web アプリ診断を実施した。
(3) Z 社は，手順1，2の応答が“エラー”であることから一定の CSRF 対策ができているが，手順3の応答が“正常に処理”であることから③利用者に被害を与える可能性があると判断した。
Z 社は，対策には二つの方法があることを説明した。
csrf_token の処理の修正
cookie への SameSite 属性の追加
サイト X の構成次第では，SameSite 属性を cookie に付与することも有効な対策となり得る。SameSite 属性は，Strict，Lax，None の三つの値のうちのいずれかを取る。サイト X にログインした利用者の Web ブラウザにおいて，サイト X 内で遷移する場合と外部 Web サイトからサイト X に遷移する場合では，SameSite 属性の値によってサイト X の cookie 送信の有無が表3のように異なる。
表3 SameSite 属性の値の違いによる cookie 送信の有無
〔認可制御の不備について〕
Z 社が認可制御の不備を検出した経緯は，次のとおりであった。
(1) Z 社は，利用者 α，利用者 β という二つの利用者アカウントを用いて，注文履歴を閲覧した際のリクエストを確認した。注文履歴を閲覧した際のリクエストを図5及び図6に示す。
(1) サイト P の新着情報を取得する際に，利用者の Web ブラウザが Web サーバ Y に送るリクエストを確認したところ，図7のとおりであった。
図7 利用者の Web ブラウザが Web サーバ Y に送るリクエスト
(2) ⑥図7のリクエストのパラメータの値を Web サーバ Y の CMS の管理ログイン画面の URL に変更することで，その画面にアクセスできるが，ログインはできないことを確認した。
(3) ⑦図7のリクエストのパラメータの値を別の URL に変更するという方法（以下，方法 F という）で SSRF を悪用して，クレデンシャル情報を取得し，ストレージ W から情報を盗み出すことができることを確認した。
(4) IMDS にアクセスする方式を方式1から方式2に変更すると，方法 F ではクレデンシャル情報を取得できないので，ストレージ W から情報を盗み出すことができない。しかし，図7のリクエストのパラメータの値を変更することで，Web サーバ Y から送られるリクエストに任意のメソッドの指定及び任意のヘッダの追加ができる方法（以下，方法 G という）がある。方法 G を用いれば，方式2に変更しても，⑧クレデンシャル情報を取得し，ストレージ W から情報を盗み出すことができることを確認した。
Z 社は，クラウド W 上のネットワークでのアクセス制御の設定，及び⑨サイト Y の Web アプリに追加すべき処理を提案した。
リリース前の脆弱性診断で検出された脆弱性の対策が全て完了し，サイト X とサイト Y は稼働を開始した。
図3は問合せ機能（項番5）に name パラメータでスクリプトを送ったものだが，そのレスポンスにはスクリプトが出てこない。入力した値は問合せ情報として保存され，後で別の画面に表示される。表1で問合せ情報を表示する機能は，項番9の問合せ管理機能（“問合せ機能で入力された問合せ情報が閲覧できる”）である。
本文中の下線①について，システム運用担当者とシステム開発者が，アクセスが禁止されているのにアクセスできてしまう情報は何か。図2中のユーザーマスターテーブルの列名で，それぞれ全て答えよ。また，その情報が出力される場所を，解答群の中から選び，それぞれ記号で答えよ。解答群：ア（開発ログサーバの AP ログを保存したテキストファイル），イ（本番 AP サーバの/sbin ディレクトリ配下のバイナリファイル），ウ（本番 AP サーバの/var/data ディレクトリ配下の CSV ファイル），エ（本番 AP サーバの/var/log/serverlog ディレクトリ配下のテキストファイル），オ（本番ログサーバの AP ログを保存したテキストファイル）（冊子の注記：不備により設問2(3)「システム運用担当者」の「アクセスできてしまう情報」及び「出力される場所」は成立しない。（令和6年7月19日追記）。このため，システム運用担当者の欄は収録していない）
図3の24行目は，this.toString() でインスタンス変数の値をまとめて AP ログとしてログサーバに送る。本番ではこれが本番ログサーバに AP ログとしてテキストファイルで保存される（表1 No.15）。インスタンス変数はユーザーマスターテーブルの各列に対応するので，ログには重要情報に当たるパスワード（のハッシュ値，例外時は平文），氏名，住所，電話番号，メールアドレスが含まれる。
システム開発者は develop グループで本番ログサーバへのアクセス権があり，障害調査で AP ログを見るが，重要情報へのアクセスは禁止されている。したがってシステム開発者がアクセスできてしまう情報はパスワード，氏名，住所，電話番号，メールアドレスで，出力される場所はオ（本番ログサーバの AP ログを保存したテキストファイル）である。ユーザーOID・ユーザーID・郵便番号・作成日時・更新日時は表1 No.5 の重要情報に入っていない。
なお，システム運用担当者の欄（21，22行目の標準出力が本番 AP サーバの /var/log/serverlog に出力される件）は，IPA が“不備により設問が成立しない”としたため収録していない。表1 No.16 の /var/log/serverlog のパーミッションは，正誤表で774から775に訂正されている。
設問2(4)解答欄1つ
図4中の f に入れる適切な字句を答えよ。
〔f〕解答例
SHA-256
SHA-384
SHA-512
解説
本文の根拠
表1 No.19
パスワードは，CRYPTREC 暗号リスト（令和5年3月30日版）の電子政府推奨暗号リストに記載されているハッシュ関数でハッシュ化して DB に保存する。
そのため g には，例外を投げ直す処理を書く。ソースコードなら throw new RuntimeException(e)（元の例外 e を原因として包んだ実行時例外を投げる），処理内容なら“ランタイムエラーを例外として throw する”である。例外が投げられればコンストラクタは完了せず，addUser による保存にも進まない。
ソルトは addUser の呼出しごとに異なるので，ログイン時の照合には保存時のソルトが要る。テーブルの定義は変えないので，ソルトはパスワード列にハッシュ値と一緒に入れるしかない。アは salt + パスワードをハッシュ化し，その前に salt を付けて保存するので，照合時は先頭32バイトからソルトを取り出して同じ計算ができる。答えはアである。
![枠で囲んだ説明。・ルールは，[検証対象]，[パターン]及び[動作]の三つを1行に記述する。・[検証対象]には，次のいずれかを指定する。GET：GET メソッドのパラメータの値を検証対象とする。POST：POST メソッドのパラメータの値を検証対象とする。PUT：PUT メソッドのパラメータの値を検証対象とする。ANY：全てのメソッドのパラメータの値を検証対象とする。Header：全てのヘッダの値を検証対象とする。COOKIE：cookie の値を検証対象とする。Multipart：Multipart/form-data のフィールドの値を検証対象とする。・[パターン]には，次の要素で構成される正規表現を指定する。^：文字列の先頭とマッチする。\W：任意の非英数字とマッチする。x|y：x 又は y とマッチする。(x|y)z：xz 又は yz とマッチする。[xyz]：x，y 又は z のいずれかにマッチする。.：任意の文字とマッチする。\.：“.”とマッチする。*：直前の要素の0回以上の繰返しにマッチする。・[動作]には，次のいずれかを指定する。許可：通信を通過させ，ログに記録しない。検知：通信を通過させ，ログに記録し，管理者にアラートを送信する。遮断：通信を遮断し，ログに記録し，管理者にアラートを送信する。](/data/figures/2024r06h-sc-pm/q1-f5.png)
![枠で囲んだ説明。[クラウド W にあるサーバ及びストレージ W について] クラウド W 上のサービスの管理のためのアクセスの際は，クラウド W 用の利用者 ID，アクセスキーなどのクレデンシャル情報をリクエストに含める必要がある。D 社が利用するクラウド W 上のサービスには，D 社用に発行されたクレデンシャル情報でアクセスでき，全ての操作ができる。[IMDS について] IMDS は，VPC の各サーバから特定の URL にアクセスされると特定の情報を返す。例えば，https://○○○.○○○.○○○.○○○/meta-data/credential に GET メソッドでアクセスされると，クラウド W 上のサービスのクレデンシャル情報を返す。IMDS には，インターネットから直接アクセスできないプライベート IP アドレス（○○○.○○○.○○○.○○○）が設定されている。IMDS にアクセスする方式は，次のいずれかを採用する必要がある。D 社では，方式1を採用する。方式1：特定の URL にアクセスするだけで情報を取得できる。方式2：トークンを発行する URL に PUT メソッドでアクセスし，レスポンスボディに含まれるトークンを入手してから，そのトークンをリクエストヘッダに含めて特定の URL にアクセスすると情報を取得できる。[CMS について] Web サーバ X の https://□□□.jp/admin 又は Web サーバ Y の https://■■■.jp/admin にアクセスすると，それぞれのサーバの CMS の管理ログイン画面にアクセスできる。ログインは，POST メソッドでは許可されるが，GET メソッドでは許可されない。各 CMS の管理ログイン画面へのアクセスは，VPN 接続された D 社管理者 PC，又は VPC 内からのアクセスだけに制限される。D 社では，各 CMS の管理者アカウントは初期パスワードのまま運用する。](/data/figures/2024r06h-sc-pm/q3-f2.png)
![枠で囲んだリクエストとレスポンス。
[リクエスト]
POST /shop/contact HTTP/1.1
Host: （省略）
（省略）
Content-Type: application/x-www-form-urlencoded
Content-Length: （省略）
Cookie: SESSIONID=nt1t3dmxmlmwuicyiz3h4nq1
（空行）
subject_id=004&name=%22%3e%3cscript%3ealert%281%29%3c%2fscript%3e%3c%22&tel=（省略）&mail=（省略）&mail2=（省略）&comment=（省略）
（空行）
[レスポンス]
（省略）
（空行）
<h1>問合せを受け付けました。</h1>
（省略）
注記 パラメータ name の値は "><script>alert(1)</script><" を URL エンコードした値である。](/data/figures/2024r06h-sc-pm/q3-f3.png)
![Java のソースコード（行番号付き）。
（省略）//package 宣言，import 宣言など
1: public UserData(HttpServletRequest request) {
2: this.userId = request.getParameter("userId");
3: this.password = request.getParameter("password");
（省略）//入力値チェックなど
4: try {
5: MessageDigest mdObj = MessageDigest.getInstance("SHA-1");
6: byte[] hashByte = mdObj.digest(this.password.getBytes());
7: this.password = String.format("%x", new BigInteger(1, hashByte));
8: } catch (NoSuchAlgorithmException e) {
9: log.debug("error:" + e);
10: }
（省略）
11: }
//引数 conn は DB コネクションオブジェクトを示す。
12: public void addUser(Connection conn) {
13: PreparedStatement psObj;
14: String sql = "INSERT INTO USER_MASTER" +
15: "(USER_OID, USER_ID, PASSWORD, USER_NAME, ZIP_CODE" +
（省略）;
16: try {
17: psObj = conn.prepareStatement(sql);
18: psObj.setString(1, this.userOid);
19: psObj.setString(2, this.userId);
20: psObj.setString(3, this.password);
（省略）
//次の2行はデバッグログの出力
21: System.out.println("SQL:" + sql);
22: System.out.println("InsertData:" + this.toString());
//次の2行はログサーバへの AP ログの出力
23: log.debug("SQL:" + sql);
24: log.debug("InsertData:" + this.toString());
25: psObj.execute();
26: conn.commit();
27: } catch (SQLException e) {
（省略）//例外処理
28: }
（省略）
29: }
（省略）
注記 log.debug()は，引数の文字列をログサーバに送信するメソッドである。](/data/figures/2024r06h-sc-pm/q4-f3.png)
![Java のソースコード（行番号付き）。
（省略）//package 宣言，import 宣言など
1: public UserData(HttpServletRequest request) {
2: this.userId = request.getParameter("userId");
3: this.password = request.getParameter("password");
（省略）//入力値チェックなど
4: try {
5: MessageDigest mdObj = MessageDigest.getInstance("［ f ］");
6: byte[] hashByte = mdObj.digest(this.password.getBytes());
7: this.password = String.format("%x", new BigInteger(1, hashByte));
8: } catch (NoSuchAlgorithmException e) {
9: log.debug("error:" + e);
//回復不能な例外発生
10: ［ g ］;
11: }
（省略）
12: }
//引数 conn は DB コネクションオブジェクトを示す。
13: public void addUser(Connection conn) {
14: PreparedStatement psObj = null;
15: String sql = "INSERT INTO USER_MASTER" +
16: "(USER_OID, USER_ID, PASSWORD, USER_NAME, ZIP_CODE" +
（省略）;](/data/figures/2024r06h-sc-pm/q4-f4.png)
![設問2(7)の中に示されている解答群（表の形）。
ア：
byte[] hashByte = mdObj.digest((salt + this.password).getBytes());
this.password = salt + String.format("%x", new BigInteger(1, hashByte));
イ：
byte[] hashByte = mdObj.digest((salt + this.password).getBytes());
this.password = String.format("%x", new BigInteger(1, hashByte));
ウ：
byte[] hashByte = mdObj.digest(this.password.getBytes());
byte[] saltByte = mdObj.digest(salt.getBytes());
this.password = String.format("%x", new BigInteger(1, hashByte)) + String.format("%x", new BigInteger(1, saltByte));
エ：
byte[] hashByte = mdObj.digest(this.password.getBytes());
this.password = salt + String.format("%x", new BigInteger(1, hashByte));
オ：
byte[] hashByte = mdObj.digest(this.password.getBytes());
this.password = String.format("%x", new BigInteger(1, hashByte));
byte[] saltHashByte = mdObj.digest((salt + this.password).getBytes());
this.password = String.format("%x", new BigInteger(1, saltHashByte));](/data/figures/2024r06h-sc-pm/q4-f5.png)