平成26年度 秋期 午後Ⅱ（旧試験）

本文の根拠

〔日本における ID 管理・認証の方式〕

日本認証サーバは，利用者認証が成功すると，認証 Cookie を発行し，認証成功を示すメッセージと日本のポータルサーバ（以下，日本ポータルという）へのリンクをブラウザに表示する。

〔日本における ID 管理・認証の方式〕

利用者がそのリンクをクリックすると，日本ポータルは，認証 Cookie の検証を行う。

図1の a は，日本認証サーバが利用者認証の成功後に発行し，ブラウザが日本ポータルと日本社内システムへ送り，それぞれが検証するデータである。本文はそれを“認証Cookie”と呼んでいるので，解答例は“認証Cookie”である。

図1の流れを追うと，日本認証サーバが「の発行」を行う処理，日本認証サーバから PC への HTTP 応答，PC から日本ポータルと日本社内システムへの HTTP 要求，日本ポータルと日本社内システムの「の検証」の6か所が同じ語で埋まる。Kerberos の TGT・ST は日本 DS が発行し，日本認証サーバの認証にだけ使うものなので，ここには入らない。

設問は“本文中の用語を用いて”と指定している。“Cookie”だけでも意味は通じるが，本文の“認証Cookie”（解答例は8字）とそろえて書くのが安全である。ST（サービスチケット）と書くと，日本ポータル以降に渡るものではないので誤りになる。

本文の根拠

〔アジア地域における ID 管理・認証の方式〕

ブラウザは，ホームページとして設定されたアジアポータルにアクセスしようとする。その際，アジア認証サーバは，アジア LDS を参照し，ID とパスワードによる利用者認証を行う。

図3

アジアPCからアジア認証サーバへ「HTTP要求（bのURI）」

図3

アジア認証サーバからアジアポータルへ「HTTP要求（bのURI）」

アジア PC のブラウザはホームページとして設定されたアジアポータルにアクセスしようとし，その要求はリバースプロキシ型のアジア認証サーバが受ける。認証サーバは ID とパスワードの入力画面を返し，認証に成功すると，同じ URI の要求をアジアポータルに中継する。したがって，2か所の b はどちらも“アジアポータル”である。

図2（欧米地域）でも，欧米 PC が欧米認証サーバに“欧米ポータルの URI”を要求し，認証サーバが欧米ポータルへ同じ要求を中継している。アジアはこの欧米の形から Kerberos の相互レルムチケットの部分を除いたものなので，対応づけると見つけやすい。

設問は“図3中から選び”と指定しており，アジア社内システムなど別の構成要素を答えないこと。アジア社内システムへの要求は図3の後半で“HTTP 要求（省略）”として別に示されている。

本文の根拠

〔アジア地域における ID 管理・認証の方式〕

しかし，アジア LDS への ID 登録や削除は人事システムと連携していない。

〔アジア地域における ID 管理・認証の方式〕

正社員及び契約社員は，アジア社内システムにアクセスする必要が生じた際に，自ら ID とパスワードの登録をアジア地域の情報システム部に依頼している。

〔日本における ID 管理・認証の方式〕

管理者が所属長に対して当該契約社員のシステム利用申請を行い，承認を得る。

アジア LDS への登録は，人事システムと連携しておらず，利用者本人が情報システム部に依頼する形である。日本では，正社員は人事管理手続に基づく承認の後に，契約社員は管理者から所属長への利用申請と承認の後に，ID を登録する。アジアにはこの承認の段階が書かれていないので，依頼さえすれば，社内システムを使う必要のない者の ID でも登録できてしまう。これが解答例の問題点である。

日本・欧米の手順と並べ，アジアだけに無いものが“承認（利用の必要性の確認）”であると読み取る。人事システムとの連携が無いので，退職者の ID の削除も漏れやすくなるが，設問は“登録手順”の問題点を問うているので，登録時の承認が無い点を答える。

解答例は40字で，45字の制限に収まる。“承認が行われず”と“必要がない者も登録できる”の二つを入れる。“人事システムと連携していない”とだけ書くと，なぜセキュリティ上の問題かが伝わらない。

採点講評（IPA）

設問1は，認証システム及び利用者ID管理プロセスに関する問題である。(3)は，正答率が低かった。各地域のID管理プロセスを比較した上で，アジア地域におけるID管理プロセスの問題点を解答してほしかった。

本文の根拠

〔日本における ID 管理・認証の方式〕

日本ポータル及び日本社内システムでの認証 Cookie の検証では，日本認証サーバと併せて開発された，エージェントと呼ばれる Java プログラムがアプリケーションプログラムからメソッドとして呼び出される。

下線①

エージェント型の認証サーバを採用した場合，G ポータルや G システムに市販のパッケージ製品を採用する際に大きなカスタマイズが必要となる。

エージェント型の認証サーバでは，認証 Cookie の検証を，保護する側のアプリケーションが認証サーバと併せて作られたエージェント（Java プログラム）をメソッドとして呼び出して行う。市販のパッケージ製品はそのような呼出しを前提にしていないので，G ポータルや G システムにそれを組み込むには，アプリケーション側を改造して，エージェントを呼び出すようにする必要がある。解答例は“GポータルやGシステムからエージェントを呼び出すための変更”である。

これに対し，リバースプロキシ型（製品 P）は，認証サーバがブラウザとアプリケーションの間に入って認証を済ませるので，アプリケーション側を変えずに済む。表1で日本だけがエージェント型であるのは，N 社が認証サーバと併せて自社開発しているからである。

解答例は29字で，35字の制限に収まる。“カスタマイズ”をそのまま繰り返すのではなく，何を変えるのか（呼出しを追加すること）を書く。

採点講評（IPA）

設問2は，認証システムの方式比較に関する問題である。(1)と(2)は正答率が低かった。エージェント型と呼ばれる認証システムの方式の一般的な考慮点について理解しておいてほしい。

本文の根拠

図2 注記2

欧米DS1及び欧米DS2の間で信頼関係が結ばれていること

図8

仮想デスクトップから利用者が所属する地域のDSへ「Kerberos要求（GDSのCRT要求，TGT）」

〔日本における ID 管理・認証の方式〕

現在，N 社の中の DS 間で信頼関係が結ばれているのは，欧米 DS1 と欧米 DS2 間だけである。

SPNEGO による SSO では，PC は自分の地域の DS から TGT を受け取っており，G 認証サーバの ST は GDS が発行する。地域の DS から GDS の相互レルムチケット（CRT）を得るには，両者の間に信頼関係が結ばれている必要がある。図2の注記2も，欧米で同じことを条件に挙げている。現在は欧米 DS1 と欧米 DS2 の間にしか信頼関係が無いので，GDS と各地域の DS の間にそれを設定する，というのが下線②の変更である。

図5の破線の部分に SPNEGO を採用すると，図8のように CRT を使った Kerberos のやり取りが増える。このとき，ドメイン名や ID・コンピュータ名が重複しないことも要るが，ID の重複は下線③の変更（設問2(3)）の側である。

解答例は20字で，25字の制限に収まる。“GDS と各地域の DS”の両方と“信頼関係”の2点を書く。“GDS の設定を変更する”だけでは何を変えるのかが分からない。

採点講評（IPA）

設問2は，認証システムの方式比較に関する問題である。(1)と(2)は正答率が低かった。エージェント型と呼ばれる認証システムの方式の一般的な考慮点について理解しておいてほしい。

本文の根拠

〔欧米地域における ID 管理・認証の方式〕

ID の体系は日本と同じであり，日本と重複している ID がある。

図2 注記2

欧米DS1及び欧米DS2がもつドメイン名，登録されているID及びコンピュータ名が重複していないこと

SPNEGO（Kerberos）を全地域に広げるには，DS の間で ID が重複していないことが条件になる。ID の先頭2桁は，正社員では AA，契約社員では本店・支店の識別番号で，欧米地域の ID の体系は日本と同じため，日本と欧米地域に重複している ID がある。下線③の“ID 体系に関する変更”は，この現状の問題を解決するために必要である。

なお，アジア地域には“他の地域と重複している ID はない”と本文に書かれている。したがって，重複があるのは日本と欧米地域の間であり，3地域すべてと書くと誤りになる。

解答例は21字で，30字の制限に収まる。“日本と欧米地域”と“ID の重複”の2点を入れる。

本文の根拠

ID 管理サブシステム

日次で各地域の人事システムから正社員の利用者情報を収集し，新たに登録された正社員に対して，GID と初期パスワードを生成して GLDS に登録する。

冒頭

契約社員は，支店ごとに契約社員を管理する者（以下，管理者という）が人事システムを使わずに管理している。

ID 管理サブシステムは，各地域の人事システムから利用者情報を収集する。ところが，契約社員は人事システムを使わず，管理者が管理している。そのため，契約社員の情報は人事システムに無く，GLDS への GID の登録の対象にならない。これが不十分な点で，解答例は“契約社員の利用者情報が取り込まれない点”である。

下線④は，Z 主任が“各地域の人事システムとは別のサーバから利用者情報を収集する必要がある”と助言したものである。人事システムとは別に契約社員の情報を持つサーバが，設問3(2)の答えになる。

解答例は19字で，25字の制限に収まる。“正社員の情報しか収集しない”と書いても同じ内容になるが，解答例は契約社員を主語にしている。

採点講評（IPA）

設問3は，ID管理システムの設計に関する問題である。正答率は期待どおりだった。

本文の根拠

〔日本における ID 管理・認証の方式〕

ID と証明書を日本 DS に登録し，ID と証明書を格納した IC カードを管理者経由で当該契約社員に貸与する。

〔欧米地域における ID 管理・認証の方式〕

欧米地域の情報システム部は，新しい正社員又は契約社員の ID と初期パスワードを欧米 DS1 に登録し，当該正社員又は管理者に通知する。

〔アジア地域における ID 管理・認証の方式〕

情報システム部は，依頼内容に沿ってアジア LDS に ID とパスワードを登録する。

契約社員の ID が登録されている場所を，地域ごとに本文から探す。日本は，契約社員の証明書と ID を日本 DS に登録する。欧米は，契約社員の ID と初期パスワードを欧米 DS1 に登録する。アジアは，アジア社内システムを使う者の ID とパスワードをアジア LDS に登録する。解答例は“日本DS”“欧米DS1”“アジアLDS”である。

欧米 DS2 には各サーバのコンピュータ名が登録されているだけで，利用者の ID は入っていない。アジア DS には入社時に全員の ID が登録されるが，GIAM システムで必要なのは社内システムを使う者であり，その ID を持つのはアジア LDS である（解答例がアジア LDS であることからの読み取りで，アジア DS が誤りかどうかは本文だけでは断定できない）。

図4から選ぶ設問なので，図4にある名称（日本DS，欧米DS1，アジアLDS）をそのまま書く。地域ごとに1つずつ選ぶ。

採点講評（IPA）

設問3は，ID管理システムの設計に関する問題である。正答率は期待どおりだった。

本文の根拠

G ポータル

G システム及び当該利用者が所属する地域のポータルサーバへのリンクを表示する。

〔日本における ID 管理・認証の方式〕

利用者がそのリンクをクリックすると，日本ポータルは，認証 Cookie の検証を行う。

図1

日本PCから日本認証サーバへ「HTTP要求（日本認証サーバのURI）」

図2

欧米PCから欧米認証サーバへ「HTTP要求（欧米ポータルのURI）」

地域のポータルへのアクセスが失敗するのは日本である。欧米とアジアでは，PC がポータルの URI を認証サーバ（リバースプロキシ）に要求し，認証サーバが中継するので，G ポータルに“欧米ポータル”“アジアポータル”の URI を載せればよい。日本では，日本ポータルが日本認証サーバの発行した認証 Cookie を検証する。G ポータルから直接日本ポータルの URI にアクセスすると，その Cookie が無いために認証に失敗する。

そこで，日本のリンクは，まず日本認証サーバの URI にアクセスさせ，SPNEGO で認証して認証 Cookie を発行させてから日本ポータルへ進ませる形にする。解答例はサーバ名が“日本認証サーバ”，地域が“日本”である。

サーバ名は10字以内の指定で，“日本認証サーバ”は7字。“日本ポータル”と答えると，失敗する側に戻ってしまう。地域は“本文中の用語”なので“日本”と書く。

採点講評（IPA）

設問4は，認証システムとポータルシステムの連携に関する問題である。地域は正答率が期待どおりだったが，サーバ名の正答率が低かった。通信シーケンスを理解した上で解答してほしかった。

本文の根拠

〔欧米地域からの要望への対応〕

VPN 接続用の ID（以下，VPNID という）とパスワード（以下，VPN パスワードという）が割り当てられ，ハードウェア型のワンタイムパスワード（以下，OTP という）トークンが貸与される。

図7

個人所有機器からシンクライアントサーバへ「ログオン要求（ID，パスワード，OTP）」

認証の3要素は，記憶（知っていること），所持（持っているもの），バイオメトリクス情報（本人の身体的特徴）である。拡張 GIAM システムでは，ID とパスワードが記憶の要素で，貸与されるハードウェア型 OTP トークンが表示するワンタイムパスワードが所持の要素である。解答例は“パスワード”と“OTPトークン”である。

図7のログオン要求は ID，パスワード，OTP の3つを送り，シンクライアントサーバが OTP を OTP 認証サーバで確認している。VPN 接続時の VPNID・VPN パスワードも記憶の要素だが，それだけでは要素が増えない。

字数は“パスワード”が5字，“OTPトークン”が7字で，8字以内に収まる。“OTP”だけでも通じるが，要素は“持っているもの”なので，トークンまで書くと伝わりやすい。同じ要素（ID とパスワード）を2つに数えてはいけない。

採点講評（IPA）

設問5は，2要素認証及びシンクライアントに関する問題である。正答率は低かった。一般的知識である，認証の3要素(記憶，所持，バイオメトリクス情報)，読取り装置を利用した2要素認証における考慮点，シンクライアントにおける考慮点について，理解してほしい。

本文の根拠

要望2

利用者が自宅から，個人所有の PC やタブレット端末（以下，個人所有機器という）を使って欧米社内システムを利用する方法を検討中である。

〔日本における ID 管理・認証の方式〕

日本 PC は N 社が一括調達したものであり，IC カードリーダは，日本 PC 専用に開発されたものである。

下線⑥

採用した場合，IC カードリーダの追加導入や持ち運びが必要になる上，テスト工程の期間と工数が大きくなると説明した。

IC カードリーダは日本 PC 専用に開発されたものである。一方，個人所有機器は利用者が自分で選んだ PC やタブレット端末で，機種も OS も一様ではない。IC カードによる認証を採用すると，そうした多様な機器のそれぞれで IC カードリーダが動作し，認証が成功することを確かめる必要があり，テスト工程の期間と工数が大きくなる。解答例は“多種の個人所有機器での利用者認証の動作検証”である。

日本 PC では，PC を一括調達し，リーダも専用に作っているので，この検証の手間が小さい。下線⑥の前半（リーダの追加導入や持ち運び）はコスト面の理由で，テスト工程の理由は後半である。

解答例は21字で，25字の制限に収まる。“動作検証”だけでなく，何についてか（多種の個人所有機器と利用者認証）を入れる。

採点講評（IPA）

設問5は，2要素認証及びシンクライアントに関する問題である。正答率は低かった。一般的知識である，認証の3要素(記憶，所持，バイオメトリクス情報)，読取り装置を利用した2要素認証における考慮点，シンクライアントにおける考慮点について，理解してほしい。

本文の根拠

要望2

インターネット経由で社内のシンクライアントサーバにアクセスし，仮想デスクトップから欧米社内システム及び G システムにアクセスする際においても SSO を実現してほしい。

拡張 GIAM システム

自宅又は出張先にいる利用者は，個人所有機器から自分が所属する地域の VPN サーバ経由で自分が所属する地域のシンクライアントサーバにアクセスし

シンクライアントでは，利用者の操作（画面の更新やキー入力）が，ネットワークを通じて仮想デスクトップとやり取りされる。自分が所属する地域のシンクライアントサーバなら距離が近いが，他の地域のサーバにアクセスすると，地域をまたぐ長い経路となり，ネットワーク遅延が大きくなる。その結果，仮想デスクトップの操作に対するレスポンスが悪化する。これが解答例である。

図6のとおり，各地域の DC に VPN サーバとシンクライアントサーバを置いて，利用者を所属する地域のものに接続させるのは，この遅延を避けるためと読める。講評が挙げる“シンクライアントにおける考慮点”も，この点である。

解答例は43字で，50字の制限に収まる。“ネットワーク遅延が大きい”という要因と，“レスポンスが悪化する”という問題の2つを入れる。

採点講評（IPA）

設問5は，2要素認証及びシンクライアントに関する問題である。正答率は低かった。一般的知識である，認証の3要素(記憶，所持，バイオメトリクス情報)，読取り装置を利用した2要素認証における考慮点，シンクライアントにおける考慮点について，理解してほしい。

本文の根拠

〔アジア地域における ID 管理・認証の方式〕

ただし，アジア認証サーバは，SPNEGO ではなくフォーム認証を利用しており，アジア地域の PC（以下，アジア PC という）に SPNEGO の設定はされていない。

表1

PC と社内システムにおけるシングルサインオン：日本と欧米地域は SPNEGO プロトコル（注1）によって実現（二つの欄が一つにまとまっている），アジア地域は実現されていない。

G 認証サーバは，PC から SPNEGO で認証する方式をとる。SPNEGO が使えない PC では，PC における利用者認証の後，G ポータルにアクセスするときに ID（GID）とパスワードをもう一度入力することになる。本文の表1と地域の説明を見ると，SPNEGO による SSO が実現されていないのはアジア地域だけなので，解答例は“アジア地域”である。

日本と欧米地域は，PC のブラウザと認証サーバが SPNEGO を使うように設定されている。アジア地域は，認証サーバがフォーム認証で，アジア PC にも SPNEGO の設定が無い。

設問は“本文中の用語を用いて”とあるので，“アジア地域”と書く。単に“アジア”でも通じるが，用語は表1の列見出しにそろえておく。

本文の根拠

〔アジア地域における ID 管理・認証の方式〕

アジア認証サーバは，SPNEGO ではなくフォーム認証を利用しており，アジア地域の PC（以下，アジア PC という）に SPNEGO の設定はされていない。

図8

G認証サーバから仮想デスクトップへ「HTTP応答（401，WWW-Authenticate:Negotiate，IDとパスワードの入力画面）」

SSO を実現するためには，設定が必要なのは，SPNEGO を使うように設定されていない構成要素である。本文は“アジア認証サーバは SPNEGO ではなくフォーム認証を利用”し，“アジア PC に SPNEGO の設定はされていない”と述べているので，アジア認証サーバとアジア PC の2つである。設定内容は，どちらも“SPNEGOの設定をする。”で，解答例も同じ（①と②は順不同）。

日本認証サーバと欧米認証サーバは，認証されていないブラウザの HTTP 要求に，401 と Negotiate の値をもつ WWW-Authenticate ヘッダを返す。ブラウザはこれを受けて，TGT から ST を取って提示する。そのため，PC 側のブラウザの設定と認証サーバ側の設定の両方が要る。

設定内容の字数は“SPNEGOの設定をする。”が13字で，15字以内に収まる。構成要素は，アジア DS やアジア LDS などと間違えないこと。

採点講評（IPA）

設問6は，認証システムの統合に関する問題である。(2)は正答率が低かった。SPNEGOプロトコルを利用した統合認証について，本文中の通信シーケンス並びにPC及び認証サーバに必要な設定内容を理解して解答してほしかった。複雑なシステムの設計においては，システムの動的な側面を通信シーケンスとして図示することによって，設計を検証することがしばしば行われる。セキュリティ技術者もこのような設計技法を身に付け，セキュリティシステムの設計で実践し，役立ててほしい。

本文の根拠

会話（T 氏）

特定の IP アドレスから 27 画面に対して，SQL インジェクションの代表的なパターンが試行されていました。

表2 番号12〜14

12：GET，/GoodsDetail，goodsNo=10001，200，1,798。13：GET，/GoodsDetail，goodsNo=10001'，500，527。14：GET，/GoodsDetail，goodsNo=10001 and 1=1，200，1,806。

SQL インジェクションの有無は，一重引用符（'）を送ってエラーを起こさせ，恒真条件（and 1=1 など）を付けると正常に戻るかどうかで判断する。表2の /GoodsDetail では，番号12（正常な値）が 200・1,798 バイト，番号13（'を付加）が 500・527 バイトと大きく変わっており，SQL の構文エラーが起きたと読める。番号14（and 1=1 を付加）は 200・1,806 バイトで，正常時の 1,798 バイトの約100.4％，つまり 95〜105％であり，注入した条件が SQL として解釈されて元の結果と同じ応答が返っている。a は“ウ（95〜105％）”，b は“ク（14）”である。

番号5〜7や9〜11の /Catalog と /GoodsSearch は，'を付けても 200 のまま同じサイズ（1,840 バイト，3,877 バイト）で，エラーが起きていない。そのため，こちらは引用符が無害化されていて注入できないと読める（番号7と11も 200 で同サイズだが，'でエラーが出ないので脆弱性の根拠にならない，というのが筋道である）。

解答群は記号で答える。b は選択肢のク（14）で，番号13と取り違えないこと。13 は 500 でステータスが条件（200）に合わない。

採点講評（IPA）

設問1は，SQLインジェクションに関する問題である。(1)と(2)は，正答率が期待よりも低かった。攻撃を受けた場合に，Webサーバのアクセスログがどのように残るかを理解しておいてほしい。

本文の根拠

表2 番号13

13：GET，/GoodsDetail，goodsNo=10001'，500，527。

表2 番号14

14：GET，/GoodsDetail，goodsNo=10001 and 1=1，200，1,806。

脆弱性があると考えられるログは番号13と14で，その URI のパス名は“/GoodsDetail”，クエリ文字列のパラメタ名は“goodsNo”である。解答例も同じである。

クエリ文字列は“goodsNo=10001'”のように“パラメタ名=値”の形なので，パラメタ名は等号の左側の“goodsNo”である。パス名は，URI のうちクエリ文字列より前の“/GoodsDetail”で，先頭のスラッシュまで含めて書く（表2の表記どおり）。

字数は“/GoodsDetail”が12字，“goodsNo”が7字で，どちらも15字以内に収まる。大文字小文字は表2のとおりに書く（GoodsDetail の G と D，goodsNo の N が大文字）。

採点講評（IPA）

設問1は，SQLインジェクションに関する問題である。(1)と(2)は，正答率が期待よりも低かった。攻撃を受けた場合に，Webサーバのアクセスログがどのように残るかを理解しておいてほしい。

本文の根拠

〔F 社ショッピングサイト α への攻撃〕

それぞれ 30 画面で構成されている。

会話（T 氏）

特定の IP アドレスから 27 画面に対して，SQL インジェクションの代表的なパターンが試行されていました。

携帯サイトは30画面で構成され，攻撃者が試行したのは27画面である。残り3画面には攻撃が行われていないので，ログから脆弱性の有無は分からない。同じ作りの画面には，同様に SQL インジェクションの脆弱性があるかもしれないので，攻撃を受けた画面だけでなく，サイト全体に対策を行うべきである。

携帯サイトは5年前の公開以来，一度も診断をしていない。そのため，攻撃されていない画面が安全であるという根拠も無い。

解答例は32字で，40字の制限に収まる。“残り3画面”と“脆弱性があるかもしれない”の2点を入れる。“念のため”だけでは理由にならない。

本文の根拠

〔セキュリティ対策プロジェクトの立上げ〕

(4) セキュリティ事故が発生した直後の A 社情報システム部への報告

〔F 社ショッピングサイト α への攻撃〕

その後，F 社では携帯サイトを再開し，N さんは A 社情報システム部に，F 社でセキュリティ事故が発生したことを報告した。

計画の(4)は，セキュリティ事故が発生した直後に A 社情報システム部へ報告することである。しかし N さんは，携帯サイトの対策が完了し，サイトを再開した後になってから報告している。事故の情報を緊急にグループ各社へ展開するという目的（U 課長の考え）に合わないので，事故の発生後にすぐ報告すべきだった。解答例は“A社情報システム部に事故発生後にすぐ報告していない点”である。

それ以外の対応（サーバのネットワークからの切離し，専門業者への調査依頼，修正後のソースコードの確認）は，本文の流れに沿った妥当な対応である。

解答例は26字で，30字の制限に収まる。“報告が遅い”だけではなく，誰に，いつまでに報告するのかを入れる。

本文の根拠

図1

IPS，WAF などによって，e からの通信が遮断されると，対象 Web サイトの脆弱性を検出できないので，e からの通信は遮断しないように設定した上で診断する。

IPS や WAF は，攻撃文字列を含む通信を遮断する。診断では，診断ツールが攻撃と同じ文字列を送るので，そのまま遮断されてしまい，対象 Web サイトの脆弱性を検出できなくなる。そこで，診断ツールからの通信を遮断しないように設定する。診断ツールを特定できるのは送信元 IP アドレスなので，解答例は“診断ツールのIPアドレス”である。

講評も，IPS や WAF が遮断するのは攻撃文字列を含む通信であり，診断時には攻撃文字列と同じ文字列が送られることを理解して解答してほしかった，と述べている。

解答例は12字で，15字の制限に収まる。“診断ツール”だけでなく，何で遮断対象から外すか（IP アドレス）まで書く。

採点講評（IPA）

設問2は，Webサイトの脆弱性診断に関する問題である。(1)は，正答率が低かった。IPSやWAFが遮断するのは攻撃文字列を含む通信である。診断時には攻撃文字列と同じ文字列が送られることを理解して，解答してほしかった。(2)と(3)については，正答率は高かった。

本文の根拠

図1 3. 診断の実施方法

社内ネットワークからの攻撃を想定する場合，ファイアウォールの内側から診断する。

図1 6. 診断実施後の対応

ファイアウォールの内側から行った診断で検出された脆弱性のうち f については，深刻な脆弱性であっても，対策の優先順位を下げてよい。

ファイアウォールの内側から診断すると，外側からはファイアウォールに遮断されて届かない通信に関わる脆弱性も検出される。インターネットからの攻撃者は，遮断されているポートには到達できないので，その脆弱性を悪用できない。したがって，深刻であっても対策の優先順位を下げてよいのは，“ファイアウォールで遮断されているポート番号の通信に関わる脆弱性”である（解答例）。

優先順位を下げてよいのであって，対策が不要というわけではない。内部の利用者や，ファイアウォール設定の誤りなどを想定すると，リスクは残る。

解答例は31字で，40字の制限に収まる。“ファイアウォール”と“ポート”の二つの用語を使う指定があるので，両方を入れる。

採点講評（IPA）

設問2は，Webサイトの脆弱性診断に関する問題である。(1)は，正答率が低かった。IPSやWAFが遮断するのは攻撃文字列を含む通信である。診断時には攻撃文字列と同じ文字列が送られることを理解して，解答してほしかった。(2)と(3)については，正答率は高かった。

本文の根拠

図1 6. 診断実施後の対応

脆弱性の修正完了後，公開前にプラットフォーム診断及び Web アプリ診断を再度行う。

脆弱性の修正は，プログラムや設定を変更するので，その変更が新たな脆弱性を作り込むおそれがある。そこで，修正後に公開前の診断を再度行い，検出された脆弱性が適切に修正されたことに加えて，修正によって新たな脆弱性が発生していないことを確認する。解答例は“修正によって新たな脆弱性が発生していないこと”である。

講評では(2)と(3)の正答率は高かったとされている。ガイドライン案が“修正完了後，公開前に”の“プラットフォーム診断及び Web アプリ診断”の両方を再度行うとしていることから，一部の診断で済ませない意図が読める。

解答例は22字で，30字の制限に収まる。“再発防止”などの一般論ではなく，“修正による新たな脆弱性”という点を書く。

採点講評（IPA）

設問2は，Webサイトの脆弱性診断に関する問題である。(1)は，正答率が低かった。IPSやWAFが遮断するのは攻撃文字列を含む通信である。診断時には攻撃文字列と同じ文字列が送られることを理解して，解答してほしかった。(2)と(3)については，正答率は高かった。

本文の根拠

図2

document.write(decodeURIComponent(location.hash));

図3

http://www.example.jp/domxss.html g <script>alert(1) h

図2の HTML は，location.hash（URI のフラグメント部分）を document.write でそのまま書き出す。location.hash は，先頭の“#”を含む文字列である。したがって，URI は“http://www.example.jp/domxss.html#<script>alert(1)</script>”で，g は“#”，h は“</script>”である。<script> と </script> で挟むと，書き出された部分がスクリプトとしてブラウザ上で実行され，“1”の警告ダイアログが出る（フラグメントはブラウザがサーバに送らないので，攻撃者の入力は Web サイトの応答には現れない）。

この構造が，本文の言う“攻撃者が注入するデータが Web サイトからの応答中に出力されない”DOM ベースの XSS の特徴である。

g は“#”の1字，h は“</script>”の9字。h は，図3の <script> に対応する閉じタグなので，スラッシュを忘れないこと。

採点講評（IPA）

設問3は，Webサイトの新しいセキュリティ対策に関する知識についての問題である。全体として正答率は低かった。(1)と(2)は，反射型のXSSとDOMベースのXSSについての問題であったが，仕組みを正しく理解していない解答が目立った。クリックジャッキングは，数年前から問題視されてきた脆弱性であるが，対策を行っているWebサイトはまだ少ない状況である。これらの脆弱性や攻撃に関する知識を確認してほしい。

本文の根拠

(Ⅰ)

反射型（reflected 型，non-persistent 型）の XSS と違って，DOM ベースの XSS では攻撃者が注入するデータが Web サイトからの応答中に出力されない。

反射型の XSS は，入力したデータが Web サイトの応答に出力されるので，スクリプトを含むデータを Web アプリに入力し，応答の中にそのスクリプトが出力されているかを確認すれば診断できる。解答例は“スクリプトを含むデータをWebアプリに入力し，それがWebサイトからの応答中に出力されているかを確認する。”である。

DOM ベースの XSS では，入力データはブラウザ上の JavaScript が処理するだけで，Web サイトからの応答に含まれない。応答の中を調べても不正なスクリプトは見つからないので，この診断方法では発見できない。解答例の理由は“Webサイトからの応答中に不正なスクリプトが含まれていないから”である。

講評は，仕組みを正しく理解していない解答が目立ったとしている。字数は，診断方法が53字（65字以内），理由が31字（35字以内）である。

採点講評（IPA）

設問3は，Webサイトの新しいセキュリティ対策に関する知識についての問題である。全体として正答率は低かった。(1)と(2)は，反射型のXSSとDOMベースのXSSについての問題であったが，仕組みを正しく理解していない解答が目立った。クリックジャッキングは，数年前から問題視されてきた脆弱性であるが，対策を行っているWebサイトはまだ少ない状況である。これらの脆弱性や攻撃に関する知識を確認してほしい。

本文の根拠

(Ⅱ)

クリックジャッキングの対策には，④HTTP 応答ヘッダで“X-FRAME-OPTIONS”に DENY を指定することによって，自サイトをフレーム内で表示させないようにする方法がある。

表3

フレーム内での表示の有無：サイト1〜4 なし，サイト5 あり（同じドメインページ内で表示），サイト6 あり（同じドメインページ内で表示）。

X-Frame-Options に DENY を指定すると，ブラウザはそのコンテンツをどのフレームの中にも表示しない（RFC 7034）。表3の“フレーム内での表示の有無”が“あり（同じドメインページ内で表示）”なのはサイト5とサイト6なので，この2つは自サイトの画面をフレームで表示しており，DENY にすると正規の利用で不具合が出る。

同じドメインのページからのフレーム表示だけを許せばよいので，DENY を SAMEORIGIN に変更する（RFC 7034 では，SAMEORIGIN は，コンテンツと異なるオリジンのページのフレーム内には表示しない）。解答例は“X-FRAME-OPTIONSヘッダのDENYをSAMEORIGINにする。”である。

変更内容は38字で，45字以内に収まる。サイトは“サイト5，サイト6”の2つを両方挙げる（設問は“全て答えよ”）。

採点講評（IPA）

設問3は，Webサイトの新しいセキュリティ対策に関する知識についての問題である。全体として正答率は低かった。(1)と(2)は，反射型のXSSとDOMベースのXSSについての問題であったが，仕組みを正しく理解していない解答が目立った。クリックジャッキングは，数年前から問題視されてきた脆弱性であるが，対策を行っているWebサイトはまだ少ない状況である。これらの脆弱性や攻撃に関する知識を確認してほしい。

本文の根拠

(Ⅲ)

HSTS とは，Web サイトが HTTPS の使用をブラウザに強制させる機能である。

図4

HTTPS応答（i:max-age=31536000）

HSTS（HTTP Strict Transport Security）は，Web サイトが HTTPS 応答のヘッダに Strict-Transport-Security を指定することで有効になる。値の max-age は，ブラウザがその設定を保持する秒数である（RFC 6797。31536000 秒は365日）。解答例は“ウ”である。

他の選択肢は，Content-Disposition（応答の扱い方，ダウンロードなどの指定），Content-Security-Policy（読み込めるリソースの制限），X-Content-Type-Options（MIME タイプの推測の抑止），X-XSS-Protection（ブラウザの XSS フィルタの制御）で，HTTPS の強制とは関係がない。

記号で答える設問で，“Strict-Transport-Security”の名前を覚えていないと答えられない。HSTS のスペルの中の“Transport Security”と対応させて覚える。

本文の根拠

(Ⅲ)

正規の Web サイトで HSTS が有効になるように設定していない場合，正規の Web サイトが HTTPS 通信だけを受け付けるように構成していても，中間者攻撃が行われると，⑤ブラウザが HTTP 通信で接続してしまい，中間者によって通信を盗聴されてしまう。

(Ⅲ)

利用者は毎回 j ことでこの攻撃を受けても気付くことができる。

中間者攻撃で HTTP 通信にされても，利用者がブラウザのアドレスバーを見れば，接続が https で始まっているかで気付ける。したがって，利用者が毎回すべきことは，ブラウザのアドレスバーの情報で，https で通信していることを確認することである。解答例は“ブラウザのアドレスバーの情報で，httpsで通信していることを確認する”である。

続く文が“j ことを利用者に徹底させるのは難しいので，HSTS のプロトコルが開発された”と述べている。HSTS を使えば，ブラウザが自動で https に切り替え，利用者の確認に頼らずに済む。

解答例は35字で，40字の制限に収まる。“具体的に”という指定があるので，“注意する”のような曖昧な書き方でなく，どこを見て何を確認するかを書く。

本文の根拠

(Ⅲ)

HSTS とは，Web サイトが HTTPS の使用をブラウザに強制させる機能である。

図4

HTTPS要求（https://www.example.jp/）

図4のとおり，HSTS はブラウザが一度 HTTPS で Web サイトにアクセスし，応答の Strict-Transport-Security を受け取って初めて有効になる。それ以前に，ブラウザが初めて Web サイトへ http でアクセスした場合は，HSTS の効果が無く，中間者攻撃で HTTP 通信のままにされて盗聴されうる。解答例は“初回にブラウザでWebサイトへhttpでアクセスした場合”である。

RFC 6797 は，この初回の接続を狙う中間者攻撃を“Bootstrap MITM Vulnerability”として挙げている。また，HTTP 経由で受け取った STS ヘッダは，ブラウザが無視する（RFC 6797 8.1）。

解答例は28字で，35字の制限に収まる。“有効期限が切れた場合以外”という条件なので，期限切れ以外の場合として，初回のアクセスを答える。