平成30年度 春期 午後Ⅱ（旧試験）

本文の根拠

図4 脆弱性2

検索ページで使用されるスクリプトに DOM-based XSS が存在する。攻撃者が“#”から始まるフラグメント識別子に攻撃コードを記述できる。

〔検出事項1の対応方針の検討〕 Nさん

その文字列がレスポンス中にスクリプトとして出力されるかどうかで判断する方法（以下，検知方法 1 という）

〔検出事項1の対応方針の検討〕

検知方法 1 では脆弱性 2 を検知できない。

検知方法1は，スクリプトに相当する文字列を含むリクエストを送り，その文字列がレスポンスの中にスクリプトとして現れるかどうかでサーバ側の反射型XSSを判断する方法である。脆弱性2は，攻撃コードを“#”から始まるフラグメント識別子に書く形のDOM-based XSSである。RFC 3986は，フラグメント識別子は参照の前にURIの残りの部分から切り離され，その中身は利用者エージェント（ブラウザ）だけが解釈すると定めている。つまりフラグメントの値はサーバに送られず，レスポンスの内容も脆弱性の有無で変わらない。解答例は“脆弱性の有無によってサーバからのレスポンスに違いがないから”である。

脆弱性1（反射型XSS）は攻撃コードがレスポンスに出力されるので，レスポンスを見るツールで検知できる。脆弱性2は，ブラウザ上のスクリプトがフラグメントの値を読んで画面を書き換える点に問題があり，原因はサーバの応答ではなくクライアント側のスクリプトにある。WAFもサーバへ届くリクエストを調べる仕組みなので，フラグメントの値は見えない。

字数は35字以内で，解答例は29字である。“サーバからのレスポンス”と“違いがない”の二つを残す。“サーバに送られないから”だけでも筋は通るが，設問は“レスポンスの内容を見て判断するツール”が検知できない理由を問うので，レスポンスに違いが出ない点まで書く。

採点講評（IPA）

設問1(1)，(2)は，DOM-based XSSに関する設問であったが，反射型XSSについて言及した解答が散見された。DOM-based XSSが引き起こされる原理についてよく理解しておいてほしい。また，設問1(3)は，正答率が低かった。HttpOnly属性はCookieの値を不正に操作されることを防ぐために有効なので，よく理解しておいてほしい。

本文の根拠

〔検出事項1の対応方針の検討〕

R ポータルへのアクセスを繰り返すことなく，脆弱性 2 の有無を分析する方法

図4 脆弱性2

検索ページで使用されるスクリプトに DOM-based XSS が存在する。

〔検出事項1の対応方針の検討〕 Nさん

攻撃者が脆弱性 1 の有無を分析しようと攻撃試行すると，検知できます。

下線②は，Rポータルへのアクセスを繰り返さずに脆弱性2の有無を分析する方法である。脆弱性1のようにリクエストを送ってレスポンスを見る方法ではサーバへのアクセスが要るが，DOM-based XSSの原因は検索ページが読み込むスクリプトの中にある。そこで攻撃者は，検索ページのスクリプトを手元に取得して読み，フラグメント識別子の値がどのように使われ，画面にどう反映されるか（挙動）を確認すればよい。解答例は“スクリプトを分析し，フラグメント識別子の値の変化による挙動を確認する。”である。

スクリプトはブラウザに配布されるので，攻撃者は一度取得すれば何度でも読める。サーバへの試行を繰り返さないので，WAFに攻撃試行として検知されることもない。これが，本文の“WAFでも脆弱性2を検知できない”の背景である。

字数は40字以内で，解答例は35字である。“スクリプトを分析し”と“フラグメント識別子の値の変化による挙動”の二つを残す。“脆弱性の原理を踏まえ”という指定があるので，単に“解析ツールで調べる”とせず，フラグメント識別子に着目していることを書く。

採点講評（IPA）

設問1(1)，(2)は，DOM-based XSSに関する設問であったが，反射型XSSについて言及した解答が散見された。DOM-based XSSが引き起こされる原理についてよく理解しておいてほしい。また，設問1(3)は，正答率が低かった。HttpOnly属性はCookieの値を不正に操作されることを防ぐために有効なので，よく理解しておいてほしい。

本文の根拠

〔検出事項1の対応方針の検討〕 M主任

R ポータルはセッション管理を Cookie で実現しているので，XSS 攻撃によって Cookie を窃取されないようにする必要もある。

〔検出事項1の対応方針の検討〕 M主任

R ポータルの動作に影響が出ないことを確認した上で，Cookie の発行時に HttpOnly 属性を付与する

HttpOnly属性は，Cookieをスクリプトからは読めないようにする属性である。RFC 6265の4.1.2.6は，HttpOnly属性がCookieの適用範囲をHTTPリクエストに限り，ブラウザのスクリプト用のAPIのような“HTTP以外”の経路にはCookieを渡さないようにするものだと定めている。したがって，Rポータルのスクリプトが（document.cookieなどで）Cookieの値を読んで使う実装になっていると，HttpOnly属性を付与した後にそのスクリプトがCookieの値を取得できなくなり，動作に影響が出る。解答例は“Rポータルが利用しているスクリプトがCookieの値を利用している場合”である。

下線③の“Rポータルの動作に影響が出ないことを確認した上で”は，まさにこの副作用を確かめるという意味である。HttpOnly属性はXSSそのものを防ぐ対策ではなく，XSSが起きても，スクリプトによるCookieの窃取を防ぐ対策である。採点講評も，HttpOnly属性はCookieの値を不正に操作されることを防ぐために有効なので，よく理解しておいてほしいと述べている。

字数は45字以内で，解答例は35字である。“スクリプト”が“Cookieの値を利用している”の二つを残す。“JavaScriptを使っている場合”のように範囲を広げすぎると，Cookieを読まないスクリプトまで含んでしまうので，Cookieの値を使うことまで書く。

採点講評（IPA）

設問1(1)，(2)は，DOM-based XSSに関する設問であったが，反射型XSSについて言及した解答が散見された。DOM-based XSSが引き起こされる原理についてよく理解しておいてほしい。また，設問1(3)は，正答率が低かった。HttpOnly属性はCookieの値を不正に操作されることを防ぐために有効なので，よく理解しておいてほしい。

本文の根拠

〔検出事項2の対応方針の検討〕

共通管理者アカウントが正しく利用されていることが確認できる証跡は取得している

表3 項番3

踏み台サーバからサーバセグメントの全てのサーバへ，サーバの共通管理者アカウントによる認証

本文（踏み台サーバの操作記録）

踏み台サーバには操作記録機能があり，ログインした利用者のデスクトップ画面が数秒間隔で画像データとして記録され，実行したコマンドやキーボード入力がテキストで記録される。

本文

管理 ID は職員ごとに異なっている。

サーバセグメントのサーバには共通管理者アカウントでログインするので，サーバのログだけでは，誰がログインしたのかが分からない。ところが，そのログインは必ず踏み台サーバを経由し（表3の項番3），踏み台サーバには職員ごとに異なる管理IDでログインしている。そして踏み台サーバには操作記録機能があり，ログインした利用者のデスクトップ画面，実行したコマンド，キーボード入力が記録される。この機能で共通管理者アカウントの利用の中身（誰が何をしたか）を確認できる。解答例は“踏み台サーバの操作記録機能によって，ログインした利用者のデスクトップ画面，実行したコマンド，及びキーボード入力を記録する。”である。

設問は“どのような機能を使ってどのような証跡を取得しているか”の二点を問うので，“操作記録機能”という機能と，“デスクトップ画面，コマンド，キーボード入力”という証跡の両方を書く。アクセスログ（誰が，いつログイン，ログアウトしたか）も取得されているが，それだけでは共通管理者アカウントを使った人の特定と操作内容の確認には足りない。

字数は70字以内で，解答例は61字である。“本文中の字句を用いて”と指示されているので，機能名は“踏み台サーバの操作記録機能”，証跡は“デスクトップ画面”“コマンド”“キーボード入力”と本文の語をそのまま使う。

本文の根拠

〔検出事項3の対応方針の検討〕 案2

案 2 は，DB サーバをサーバセグメントに移動し，表 5 に示すルールを追加するなど，FW のフィルタリングルールを変更するとともに，図 2 の L3SW によって，利用者セグメントからのアクセスを禁止する案である。

表4 注記3

項番 14〜29 には，送信元が DMZ の機器であり，かつ，宛先がサーバセグメントの機器であるルールは存在しない。

本文

WebAP サーバと DB サーバは ODBC（Open Database Connectivity）を用いて特定のポート間で通信している。

表4 項番9

項番 9：運用管理 PC から DB サーバへ，SSH，許可。

案2ではDBサーバがDMZからサーバセグメントに移るので，DMZにあるWebAPサーバからDBサーバへの通信が，FWを通ってサーバセグメントに入ることになる。表4の注記3のとおり，DMZからサーバセグメントへのルールは今は存在しないので，これを許可するルールを足す。送信元はWebAPサーバ（a），宛先はDBサーバ（b），サービスはWebAPサーバとDBサーバが使っているODBC（c）である。

不要になるルールは，表4の中でDBサーバを宛先にする項番9（運用管理PCからDBサーバへのSSH）である。DBサーバがサーバセグメントに入ると，運用管理PC（利用者セグメント）からDBサーバへの接続はFWを通らなくなる。表3のとおり，運用管理PCからサーバセグメントのサーバには，踏み台サーバを経由してアクセスする（項番2，3）。ルールの項番を問う設問なので，“ルール9”ではなく“9”と項番だけを答える。

字数制限は無い。abcは“送信元”“宛先”“サービス”の欄で，表5の行（項番14）の意味から機器名とサービス名を入れる。cはポート番号ではなくサービス名（ODBC）で，WebAPサーバとDBサーバの通信が本文でODBCと書かれていることから決まる。

採点講評（IPA）

設問3は，全体的に正答率が高かった。本文中に示したデータベースサーバの移設に伴うリスクについて，正しく理解できていることがうかがわれた。

本文の根拠

本文

DB サーバには，システム運用課員によるログインと，WebAP サーバからの接続だけが許可されている。

表3 項番1

項番 1：人事総務課の一部の職員の PC から踏み台サーバへ，管理 ID とパスワードによる認証，リモートデスクトップ。

表3 項番3

踏み台サーバからサーバセグメントの全てのサーバへ，サーバの共通管理者アカウントによる認証

本文

人事総務課の人事サーバ管理：サーバセグメントに設置されている人事サーバのデータを更新する。

R団体のセキュリティ対策基準では，DBサーバにログインできるのはシステム運用課員だけである。案2でDBサーバをサーバセグメントに移すと，表3の項番3により，踏み台サーバからサーバセグメントの全てのサーバに共通管理者アカウントで接続できる。しかも項番1は人事総務課の一部の職員のPCから踏み台サーバへのリモートデスクトップを許可している。つまり人事総務課の職員が踏み台サーバを経由して，共通管理者アカウントでDBサーバにログインできてしまい，これが基準違反になる。解答例は“人事総務課の職員が踏み台サーバを経由してDBサーバに共通管理者アカウントでログインする行為”である。

設問の“誰が，どのようなアクセス経路で，何を行うと”に合わせて，誰（人事総務課の職員），経路（踏み台サーバ経由），何を（共通管理者アカウントでDBサーバにログイン）の三つを書く。人事総務課の職員は人事サーバを管理する立場なので，本来はDBサーバに入る立場ではない。

字数は55字以内で，解答例は45字である。経路を“踏み台サーバを経由して”と書き，リモートデスクトップやFWのルールの細部までは書かない。

採点講評（IPA）

設問3は，全体的に正答率が高かった。本文中に示したデータベースサーバの移設に伴うリスクについて，正しく理解できていることがうかがわれた。

本文の根拠

図3 検出事項2

検出事項 2：踏み台サーバを除く全てのサーバの管理者用アカウントに，共通管理者アカウントが使用されている。

〔検出事項3の対応方針の検討〕 M主任

案 2 を採用する場合は，検出事項

案2を採用すると，設問3(2)のとおり，人事総務課の職員が踏み台サーバ経由で共通管理者アカウントを使ってDBサーバにログインできてしまう。この問題の原因は，サーバが共通管理者アカウントで運用されている点である。図3で共通管理者アカウントの使用を指摘しているのは検出事項2なので，案2は検出事項2（共通管理者アカウントを個別のアカウントにする対策）と併せて実施する必要がある。解答は2である。

共通管理者アカウントを個別のアカウントに変えれば，誰がどのサーバにログインできるかをアカウントごとに制御でき，DBサーバにシステム運用課員以外が入れないようにできる。検出事項3（DBサーバがDMZにある点）は案1・案2そのものが対策であり，併せて実施する相手ではない。検出事項1はXSS，検出事項4は製作パートナへの貸与図面の管理で，DBサーバの管理者アカウントとは関係しない。

字数制限は無く，番号だけを答える。“検出事項 d の対策”と，空欄の前後が“番号”の形になっているので，“2”と数字だけを書く。

採点講評（IPA）

設問3は，全体的に正答率が高かった。本文中に示したデータベースサーバの移設に伴うリスクについて，正しく理解できていることがうかがわれた。

本文の根拠

図7 コンテナ方式の利用イメージ

プロトタイプ製作の契約ごとに，R 団体は，必要な数の CCI を製作パートナにメディアで渡す。

図7 コンテナ方式の利用イメージ

仮に製作パートナが，同一の CC を複数台の PC にインストールしても，そのうち最初にコンテナドライブにアクセスした 1 台だけがコンテナドライブにアクセスできる。

〔検出事項4の対応方針の検討〕 Nさん

第一に，製作パートナが使用している図面アプリなど，機密モードで起動できるアプリケーションソフトウェアを確認する必要があります。

コンテナ方式では，製作パートナの契約ごとに，R団体が必要な数のCCI（CCのインストーラ）をメディアで渡す。CCには識別情報があり，インストール後に最初にコンテナドライブにアクセスしたPC1台だけが使える（図7）。したがって，何台のPCで図面を扱うか（CCIをいくつ渡すか）をあらかじめ確認しておく必要がある。解答例は“製作パートナに渡すCCIの数”である。DRM方式にはCCもCCIも無いので，これはコンテナ方式だけに当てはまる確認事項である。

設問は“コンテナ方式だけに該当する確認事項”を問うている。採点講評も，DRM方式とコンテナ方式の両方に該当する確認事項を答えた誤答が一部にあったと述べている。たとえば“製作パートナが使用している図面アプリ”は，DRM方式でも対応しているかの確認が要るので，両方に当てはまり，コンテナ方式だけの事項ではない。第一の確認事項（機密モードで起動できるアプリ）が先に挙げられているので，第二はコンテナ方式固有の“CCIの数”になる。

字数は20字以内で，解答例は14字である。“製作パートナに渡すCCIの数”と，CCIの数が何で決まるかが分かるように書く。PCの台数や利用者数と書いても，CCIの数に結び付けて書けていれば考え方は同じである。

採点講評（IPA）

設問4は，全体的に正答率が高かった。

本文の根拠

図7 コンテナ方式の利用イメージ

仮に製作パートナが，同一の CC を複数台の PC にインストールしても，そのうち最初にコンテナドライブにアクセスした 1 台だけがコンテナドライブにアクセスできる。

図7 コンテナ方式の利用イメージ

仮想デスクトップ環境には CC をインストールすることはできない。

〔検出事項4の対応方針の検討〕 Nさん

基本的には DRM 方式と同じですが，コンテナ方式の場合は，まずは

DRM方式では，S図面をメールで協力者に送り，利用者IDとパスワードを電話などで伝えれば，協力者が自分のPCで開ける。コンテナ方式では，CCは最初にコンテナドライブにアクセスしたPC1台にひも付くので，CCを協力者のPCにインストールしても使えない。さらに機密モードのPCは，PCの他のドライブや外部記憶媒体，ネットワークにはアクセスできない。そこで協力者が図面を扱えるようにするには，製作パートナのPC（CCをインストール済みのPC）そのものを協力者宛てに輸送するしかない。解答例は“CCをインストールしたPCを協力者宛てに輸送”である。

輸送後，利用者IDとパスワードを電話で協力者に伝えれば，協力者が機密モードにログインして図面を閲覧できる。M主任の“コンテナ方式の方が，不正行為はより困難だ”という評価は，ファイルを送るだけでは済まず，PCごとの輸送という手間が要ることを指している。

字数は30字以内で，解答例は22字である。“CCをインストールしたPC”と“協力者宛てに輸送”を残す。“CCIを送る”とすると，CCは最初にアクセスしたPC1台にひも付くのでインストールし直しても使えず，不正行為が成立しない。

採点講評（IPA）

設問4は，全体的に正答率が高かった。

本文の根拠

図6 DRM方式の利用イメージ

DRM サーバは，R 団体の DMZ 上に設置され，利用者の認証機能や，利用者の図面へのアクセスを制御する機能をもっている。

図6 DRM方式の利用イメージ

PC と DRM サーバとの間で通信が行われ，認証ダイアログが表示される。

〔検出事項4の対応方針の検討〕 M主任

このような不正行為への技術的対策としては，FW での対策が効果的だな。

DRM方式のS図面は，DRM対応の図面アプリで開くときにPCとDMZ上のDRMサーバが通信し，認証ダイアログで利用者IDとパスワードを入れて初めて開ける。Nさんが述べた不正行為（協力者がS図面を受け取り，利用者IDとパスワードを電話で教えてもらって開く）は，協力者のPCがDRMサーバと通信できることが前提である。そこでFWで，DRMサーバへの通信を製作パートナのグローバルIPアドレスからだけに制限すれば，協力者のPC（製作パートナのネットワークの外）はDRMサーバに接続できず，S図面を開けなくなる。解答例は“DRMサーバへの通信を製作パートナのグローバルIPアドレスからだけに制限する”である。

設問は“FWで…することができる”の形で，技術的対策を問う。接続元の制限は，FWのフィルタリングルール（送信元IPアドレスによる許可）で実現できる対策である。協力者は製作パートナとは別の組織の第三者なので，通信元のグローバルIPアドレスが製作パートナのものとは異なると考えられる。

字数は45字以内で，解答例は38字である。“DRMサーバへの通信”と“製作パートナのグローバルIPアドレスからだけ”の二つを残す。“不正な通信を遮断する”のような一般論では，何を条件に遮断するのかが書けていないので誤りになる。

採点講評（IPA）

設問4は，全体的に正答率が高かった。

本文の根拠

表1 No.3

攻撃手法 K に使われる文字列が Web サーバ X の標準設定では①アクセスログに残らないので，脆弱性 K が原因である可能性は否定できない。

表1 No.2

特定の文字列を含む HTTP リクエストを送信すると，Web アプリの実行ユーザ権限で任意のファイルの読出しと書込みができる可能性がある

表2 （い）

POST データ：keyword=New

攻撃手法Kは，特定の文字列を含むHTTPリクエストを送る攻撃である。一般的なWebサーバのアクセスログは，リクエストの1行目（メソッド，URL，HTTPバージョン）を記録する書式が標準で，たとえばApache HTTP Serverのログ書式の%rは“First line of request”（リクエストの最初の行）を記録し，共通ログ書式（CLF）もこの%rを使う。GETのパラメタはURLの一部なのでこの行に残るが，POSTデータはリクエストの本文に入るので，標準設定ではアクセスログに残らない。表2のとおり，WebサイトZの操作例でもPOSTデータでパラメタを送っている。攻撃に使われる文字列がPOSTデータに含まれていれば，ログを見ても痕跡は見付からない。解答例は“攻撃に使われる文字列がPOSTデータ内に含まれている場合”である。

表1のNo.3は，ログに痕跡が無くても，攻撃手法Kが使われた可能性を否定できないと述べている。ログに残らない場合があるので，ログに痕跡が無いことは“攻撃されなかった”ことの証明にならない。

字数は35字以内で，解答例は28字である。“POSTデータ内に文字列が含まれる場合”と攻撃の条件を書く。“ログが取得されていない場合”のように設定の不備と書くと，“標準設定では残らない”という本文の前提とずれる。採点講評は，HTTPメソッドとWebサーバのアクセスログの関係を理解しておいてほしいと述べている。

採点講評（IPA）

設問1(1)，(3)は，正答率が低かった。HTTPメソッドとWebサーバのアクセスログの関係は攻撃の監視・分析において，SSHの認証方式はシステム運用管理において，それぞれ必要となる知識であるので，よく理解しておいてほしい。

本文の根拠

〔Webサイトの運用について〕

Web サイト X とシステム構成が全く同じ Web サイト Y を，別のデータセンタ Y に災害対策用として設置している。

表1 No.5

アクセスログを確認したところ，外部からのアクセスはなく，改ざんされた痕跡も見付けられなかった。

〔Webサイトの運用について〕

コンテンツも，まず Web サイト Y を更新し，問題がなければ，Web サイト X を更新している。

F氏の会話

スクリプトを埋め込まれるなど，他の形でページが改ざんされている可能性もあるので確認が必要です。

表1のNo.1の調査はリンクの書き換えを探したもので，スクリプトの埋め込みなど他の形の改ざんは見付けられない。確認の方法として，WebサイトXの全ファイルを，改ざんされていないWebサイトYの全ファイルと比較する方法が挙げられる。WebサイトYはXと構成が同じで，コンテンツもXより先に更新して問題が無いことを確かめてからXに反映しているので，Yのファイルは正しい内容の基準になる。さらに表1のNo.5のとおり，Yには外部からのアクセスも改ざんの痕跡も無い。解答例は“WebサイトYの全ファイルと比較”である。

全ファイルを比較すれば，ページ単位の目視確認と違って，リンク以外の変更（埋め込まれたスクリプトなど）も漏れなく見付けられ，機械的にできるので効率も良い。F氏の“漏れがなく，効率も良い”はこの意味である。

字数は20字以内で，解答例は16字である。“全ファイルを”の続きとして“WebサイトYの全ファイルと比較”と，比較の相手と動作を書く。“表1の結果を考慮し”という指定は，Yが改ざんされていないという結果をさしている。比較の相手にXのバックアップなど別のものを書くと，この結果を踏まえた答えにならない。

本文の根拠

〔セキュリティ専門業者による調査〕

メンテナンスで使っている SSH サービスに対して辞書攻撃が容易に成功することが確認された。

〔セキュリティ専門業者による調査〕

SSH の認証方式をパスワード認証方式以外に設定する

〔セキュリティ専門業者による調査〕

B 社 PC-LAN 内に攻撃者が侵入できると，Web サイト Y に不正にログインできる。

辞書攻撃は，パスワードの候補を次々に試す攻撃なので，パスワード認証を使うかぎり成立する。SSHの認証方式のうちパスワード以外の代表的なものは公開鍵認証方式である。SSHの認証プロトコルを定めたRFC 4252は，7節でパスワード認証とは別に公開鍵認証（publickey）を定めており，クライアントが利用者の秘密鍵で署名し，サーバが公開鍵で署名の正しさを確かめる。パスワードを推測して入るという攻撃が使えなくなる。解答は“公開鍵認証方式”である。

B社PC-LAN内に攻撃者が侵入した場合に備えるための助言なので，PC-LAN内からはSSHにアクセスできても，秘密鍵を持っていなければログインできない形にするのが狙いである。採点講評は，SSHの認証方式はシステム運用管理において必要となる知識なので，よく理解しておいてほしいと述べている。

字数は10字以内で，解答例は7字である。“公開鍵認証”でも意味は通じるが，設問は“認証方式の名称”なので，“公開鍵認証方式”と答える。“ワンタイムパスワード”のようにSSHで一般的でない方式や，“パスワード認証方式以外”という答えは名称にならない。

採点講評（IPA）

設問1(1)，(3)は，正答率が低かった。HTTPメソッドとWebサーバのアクセスログの関係は攻撃の監視・分析において，SSHの認証方式はシステム運用管理において，それぞれ必要となる知識であるので，よく理解しておいてほしい。

本文の根拠

〔全社のWebサイトのセキュリティ強化〕

漏れがあった理由を各 Web サイト担当者にヒアリングしたところ，脆弱性が発表されていることを知らなかったとのことであった。

〔全社のWebサイトのセキュリティ強化〕

今後は情報システム部が一括して脆弱性情報を収集し，各 Web サイト担当者にその情報を提供することにした。

〔セキュリティ専門業者による調査〕

OS 及びミドルウェア（以下，プラットフォームという）

〔Webサイトの運用について〕

Web アプリケーションフレームワーク（以下，WF という）

情報システム部が脆弱性情報を一括して収集するには，どのWebサイトがどの製品のどの版を使っているかを把握している必要がある。対応が漏れたのは，担当者が脆弱性の公表を知らなかったためである。WFやプラットフォーム（OS，ミドルウェア）の脆弱性は，製品名と版が分かれば公表情報と照らせるので，担当者には“Webサイトで使用しているOS，ミドルウェア及びWFの名称並びにそれぞれのバージョン情報”を報告させる。解答例はこれである。

この情報は，ソフトウェアの構成の台帳にあたる。採点講評は，脆弱性管理にはソフトウェア構成管理が必要なことについて，受験者の理解が進んでいることがうかがわれる，としている。更改などで構成が変わったら，その都度報告させるのも，台帳を最新に保つためである。

字数は50字以内で，解答例は44字である。対象を“OS，ミドルウェア，WF”の三つ，内容を“名称とバージョン情報”の二つに分けて書く。“使用しているソフトウェア一覧”とまとめると，何を指すのかが曖昧になる。

採点講評（IPA）

設問2は，正答率が高かった。脆弱性管理にはソフトウェア構成管理が必要なことについて，受験者の理解が進んでいることがうかがわれる。

本文の根拠

図4 A社診断項目

cトラバーサル

図10 診断手順書第2版

トークンなどを削除しても処理が実行される。

図4 A社診断項目

eヘッダインジェクション

図4 A社診断項目

メールヘッダインジェクション

図4 A社診断項目

クリックf

cは“ディレクトリ”（ディレクトリトラバーサル）である。パス名を操作して意図しないファイルを読み書きする攻撃で，OSコマンドインジェクションと同じく，入力値の扱いの不備を診断する項目である。dは“クロスサイト”（クロスサイトリクエストフォージェリ）である。図10の診断手順に“トークンなどのパラメタが存在しない”“トークンなどを削除しても処理が実行される”とあり，利用者が意図しない処理を実行させられるかを診断している。eは“HTTP”（HTTPヘッダインジェクション）で，次の項目がメールヘッダインジェクションなので対になる。fは“ジャッキング”（クリックジャッキング）である。

設問はc，d，e，fを“それぞれ10字以内”で答えるもので，いずれも空欄の前後と合わせて名称になる字句を入れる。dは図4，図5，表3，図10と本文の複数の箇所で同じ語が入り，いずれも“リクエストフォージェリ”の前に付く。“クロスサイトリクエストフォージェリ”のうち，空欄の外にある“リクエストフォージェリ”は書かない。

字数はそれぞれ10字以内で，解答例は6字，6字，4字，6字である。空欄の外にある語まで含めて“ディレクトリトラバーサル”などと答えると，10字を超えるか，語が重なる。

本文の根拠

表4 No.3

検索画面，bag，200，該当商品数：30 件。

表4 注記

診断時に DB には商品が 100 件登録されていた。

表2 （い）

keyword の値を DB から検索し，該当する商品を次画面に表示する。

表4のNo.3は，keywordの値がbagのとき30件だった。No.1のbag' and '1'='1は，bagの条件に“'1'='1”という常に成り立つ条件をANDでつないだものである。SQLインジェクションが存在すれば，この入力がSQL文の条件の一部として実行されるので，絞り込みの結果は変わらず，gは30である。No.2のbag' and '1'='2は，“'1'='2”という常に成り立たない条件をANDでつないだものなので，bagに該当する商品も含め1件も該当せず，hは0である。ステータスコードは3件とも200で，画面の表示だけで違いが分かる。

診断ツールJは，この結果の差（30件と0件）から，入力が条件として実行されている，つまりSQLインジェクションが存在すると判定する。採点講評は，gに，DBに登録されていた全件数である100件という解答が散見されたと述べている。100件になるのはOR条件のように常に成り立つ条件が絞り込みを無くす場合で，ここのようにANDでつなぐと元の結果（30件）が保たれる。

字数制限は無く，数値だけを答える。表3の（ア）の診断方法は“表4に示す自動診断ツールJの入出力結果を基に判定”なので，No.1とNo.2の結果の違いを読む。

採点講評（IPA）

設問4(1)gは，DBに登録されていた全件数である100件という解答が散見された。SQLインジェクションが存在する場合にどのようなSQL文が実行されるかを考えて，解答してほしかった。

本文の根拠

図8

https://www.z-site.com/calendar?inputfieldid=i

図9

var returnobj = window.opener.document.getElementById('i');

図7 カレンダ機能

https://www.z-site.com/calendar?inputfieldid=haitatsukiboubi

図7のとおり，カレンダのURLのパラメタinputfieldidの値（通常はhaitatsukiboubi）が，図9のスクリプトのgetElementByIdの引数の文字列にそのまま埋め込まれる。この文字列リテラルの中に，引用符を閉じる文字を含む値を入れると，スクリプトを書き足せる。イ（');alert('NG）を入れると，図9は getElementById('');alert('NG'); となり，引用符が対応して構文が崩れず，alert('NG') が実行されて警告ダイアログに“NG”が出る。解答は“イ”である。

ほかの選択肢は，埋め込んだ後の文字列が構文として成り立たない。ア（"><script>alert('NG');</script>）は，先頭の引用符が文字列を閉じないまま続くので，getElementById('"><script>alert(' のあとに NG という識別子が現れて構文エラーになる。エ（<script>alert('NG');</script>）も同じ理由で，文字列リテラルの途中で'が現れて構文エラーになる。ウ（'alert('NG');）は getElementById(''alert('NG');'); となり，空の文字列の直後に識別子が続いて構文エラーになる。

字数制限は無く，記号で答える。引用符が閉じていて，かつ後ろの ');（図9の元の閉じ括弧と引用符）とつながって文が成立するかを，実際に埋め込んで確かめるとよい。

本文の根拠

〔WebサイトZに対する診断の実施〕

有料会員だけが購入できることになっている限定商品を一般会員が購入できてしまうというものであった。

表5 No.1

一般会員アカウントでログインして，商品一覧画面の URL にアクセスする。

表2 （え）

操作例：有料会員の場合だけ表示される限定商品一覧画面で商品を選び，“選択”ボタンをクリックする。

表2 （う）

code の値で DB を検索し，該当する商品をカートに入れ，次画面に表示する。

表2の（う）（一般の商品一覧）と（え）（有料会員だけに表示される限定商品一覧）は，どちらもURLがhttps://www.z-site.com/kounyuで，POSTデータはcodeだけである。サーバは，codeの値でDBを検索して商品をカートに入れるが，操作した利用者が有料会員かどうかを確認していない（認可制御の欠落）。したがって，一般会員がログインして商品一覧画面を開き，（う）の操作を実行するときにcodeの値を限定商品の値（たとえば（え）の例の1000021）に書き替えれば，限定商品がカートに入る。表5のNo.2はこの操作で，結果の“カートに限定商品が入った状態となる”と合う。解答例は“（う）の操作を実行するときに，codeの値を限定商品の値に書き替える”である。

限定商品一覧画面は有料会員だけに表示され，一般会員には画面上のリンクが出ない。しかし購入処理は一覧画面と同じURLで共通なので，リンクを隠すだけでは防げない。

字数は40字以内で，解答例は34字である。“表2中の画面遷移を指定して”とあるので，“（う）の操作”と書き，操作の中身（codeの値を限定商品の値に書き替える）をあわせて述べる。画面遷移の記号（う）を書かずに“商品選択時に”とすると，指定を満たさない。

本文の根拠

図10 診断手順書第2版

アクセス制御の不備や認可制御の欠落を確認する場合には，事前にkアカウントを用意し，lを確認する。

図10 診断手順書第2版

kアカウントそれぞれについて，パラメタの値を変更するなどして，許可されていない操作ができる場合に脆弱性ありと判定する。

表5 No.1

一般会員アカウントでログインして，商品一覧画面の URL にアクセスする。

表5の確認方法は，一般会員のアカウントで操作して，有料会員にだけ許される操作（限定商品の購入）ができるかを調べるものだった。これを手順書に一般化すると，診断の準備として“権限が異なる複数のアカウント”（kは，一般会員と有料会員など）を用意し，lとして“許可されている操作の違い”（アカウントごとに何が許されているか）を確認しておく。診断のときは，各アカウントについてパラメタの値を変更するなどして，許可されていない操作ができるかを調べる。解答例は，kが“権限が異なる複数の”，lが“許可されている操作の違い”である。

kは“アカウント”の直前に入る語句で，図10にkが2回出てくるので，どちらにも当てはまる。“複数の”と“権限が異なる”の二つが要る。単に“一般会員の”とするのは，この診断では有料会員も必要なので不足である。

字数は，kが15字以内で解答例は9字，lが20字以内で解答例は12字である。lは，何を確認するのかを“許可されている操作”と書き，アカウントごとの“違い”まで入れる。採点講評は，アクセス制御や認可制御の診断方法について，よく理解しておいてほしいと述べている。

採点講評（IPA）

設問4(4)k，lは，正答率が低かった。アクセス制御や認可制御の診断方法について，よく理解しておいてほしい。

本文の根拠

図11 Webセキュリティガイド第3版

注意事項：各工程の最後にレビューを行い，作業の妥当性を確認すること

〔改善案の検討〕

今回のように開発を外部の業者に委託する場合，図 11 に従って開発されていることを確認するには工夫が必要である。

〔Webサイトの運用について〕

Web セキュリティガイドは，開発及び運用を委託している外部の業者にも順守を義務付けている。

図11のWebセキュリティガイド第3版は，各工程の最後にレビューを行って作業の妥当性を確認することを求めている。社内で開発するなら，その過程を確認できるが，外部に委託すると，委託先が実際にレビューをして，その妥当性を確認したのかが分からない。そこで，検収条件（成果物を受け取るときの条件）に，作業の妥当性を確認できる詳細なレビュー記録を委託先が提出していること，を加える。解答例は“作業の妥当性を確認できる詳細なレビュー記録を委託先が提出していること”である。

WebサイトZの開発は外部のP社に委託しており，委託時にはWebセキュリティガイドの最新版を渡している。ところが脆弱性は作り込まれていて，その原因はいずれも確認不足だった。ガイドを渡して順守を義務付けるだけでは，守られたかどうかが分からないので，検収で証拠（記録）を求める。

字数は40字以内で，解答例は34字である。“レビュー記録”と“委託先が提出”の二つを残す。“詳細な”を落とすと，“レビューをした”という形式的な記録で済んでしまう。レビューの妥当性を確認できる内容だという点を入れる。

本文の根拠

〔自社による診断の実施検討〕

表 3 の診断結果から，Q さんは脆弱性を作り込まないよう Web セキュリティガイドに項目を追加した。

〔WebサイトZに対する診断の実施〕

Q さんが，脆弱性が作り込まれた原因を P 社に確認したところ，いずれも確認不足であるとのことであった。

〔全社のWebサイトのセキュリティ強化〕

Web セキュリティガイドの記載が抽象的なので，誤った実装をしてしまったことが分かった。

WebサイトZの診断で見つかった脆弱性は，Webセキュリティガイドを渡してあったにもかかわらず，作り込まれたものである。つまりガイドが対策として十分に働いていない部分がある。そこで，個々の脆弱性について作り込まれた原因（どの工程の何が抜けていたか）を調べ，同じ原因で脆弱性を作り込まないための注意すべきポイントをガイドに追加する。解答例は“脆弱性の作り込み原因を調査して，注意すべきポイントを追加する。”である。

本文でも，XSSを作り込んだ原因をヒアリングして，記載が抽象的だったことが分かり，実装方法を具体的に書き足した（図3）。表3の診断結果から項目を追加する対応も同じ考え方である。診断の結果を“見つかった脆弱性を直して終わり”にせず，ガイドに反映して，次の開発で作り込まないようにする。

字数は40字以内で，解答例は31字である。“作り込み原因の調査”と“注意すべきポイントをガイドに追加”の二つを残す。“脆弱性を修正する”だけでは，その場の対応であって，ガイドの改善に利用する答えにならない。