N さん：被害者が画面2-2’でメンバ ID とパスワードを入力すると，それらは a というホスト名の Web サーバに送信されます。この場合，画面2-2’が表示された時点で，被害者が偽のログインフォームだと気付くかというと，それは難しいでしょう。
J 主任：なるほど。こんな被害が発生するのですね。
N さん：XSS 脆弱性を使った他の攻撃例も紹介しましょう。Web ブラウザには，b という仕組みが実装されているので，仮に，懸賞システムのコンテンツと，攻撃者が用意した Web サーバ上に置いてある攻撃者のコンテンツの両方を，フレームを使用して，Web ブラウザ上で同一画面に表示したとしても，攻撃者のコンテンツ内のスクリプトで，懸賞システムのコンテンツを参照することはできません。しかし，図7の HTML ソースコードでは，b が役立ちません。攻撃者が用意した https://wana.example.jp/getFrame.js というスクリプトで，3行目のフレームの内容を参照することができるので，その内容を攻撃者が用意した Web サーバに簡単に送信できます。
図7 攻撃用 HTML ソースコード例
N さん：攻撃者が，自分の Web サーバ上にスクリプトを用意し，図7の HTML ソースコードへのリンクを電子メールで送信するなどして，その HTML ソースコードを被害者の Web ブラウザに読み込ませることによって，①画面 3-7 の表示内容が窃取される可能性があります。
J 主任：そう考えると，懸賞システムの全ての画面で，表示される情報が窃取される危険性がありますね。
L 社は，XSS 脆弱性が存在するソースコードを修正した。
〔CSRF 対策の説明と懸賞システムの修正〕
N さんが引き続き CSRF 対策について説明した内容を，図8に示す。
図8 CSRF 対策に関する説明
N さんの説明を受けて，L 社では懸賞システムについて，CSRF 対策を行う画面遷移と行わない画面遷移を，表2のように決定した。
表2 CSRF 対策を行う画面遷移と行わない画面遷移
〔再発防止策の検討〕
M 社では，無事，懸賞システムの運用を開始したものの，J 主任は，脆弱性が作り込まれないよう再発防止策が必要であると考えた。図9は懸賞システムの開発開始時点の，L 社の Web アプリケーション開発ガイドライン（以下，ガイドラインという）である。
図9 懸賞システムの開発開始時点の L 社のガイドライン（抜粋）
今回，XSS 脆弱性の原因となった図4のソースコードを作成した T 君に事情を聞いたところ，“②画面 2-1 において Web ブラウザ側のスクリプトで入力値を検査していたので，URL パラメタである keyword の値を信頼できるデータと判断して，出力データの生成にそのまま使用した”と答えた。
J 主任は，信頼できるデータの定義を厳密に定めようと，N さんに相談した。この時の N さんの回答を，図10に示す。
図10 N さんの回答（抜粋）
J 主任は，他の脆弱性に関する調査も進め，ガイドラインを修正した。このガイドラインによって，その後 L 社では，セキュリティについての品質が向上した。
画面2-2’の偽のログインフォームは，図6 のスクリプトが document.write で書き出したものである。4行目の form 要素の action 属性が“https://wana.example.jp/login”なので，ログインボタンを押すと，入力したメンバ ID とパスワードは POST メソッドでこの URL に送られる。送信先の Web サーバのホスト名（FQDN）は wana.example.jp である。
スクリプトの置き場所（https://wana.example.jp/Login.js）とフォームの送信先が，同じ wana.example.jp にある点に注意する。入力値の行き先を決めるのは form 要素の action 属性で，画面が表示されている kensho.m-sha.co.jp ではない。
本文中の b に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア Asynchronous JavaScript + XML イ HTTP Strict Transport Security ウ JavaScript Object Notation エ Same Origin Policy
〔b〕解答例
エ
解説
本文の根拠
N さんの発言（b）
仮に，懸賞システムのコンテンツと，攻撃者が用意した Web サーバ上に置いてある攻撃者のコンテンツの両方を，フレームを使用して，Web ブラウザ上で同一画面に表示したとしても，攻撃者のコンテンツ内のスクリプトで，懸賞システムのコンテンツを参照することはできません。
あるオリジンから読み込んだコンテンツのスクリプトが，別のオリジンのコンテンツを参照できないようにする Web ブラウザの仕組みは，Same Origin Policy（同一オリジンポリシ，エ）である。オリジンはスキーム・ホスト・ポートの組で，二つの URI はこの三つが同じときに同一オリジンとされる（RFC 6454）。懸賞システム（kensho.m-sha.co.jp）と攻撃者のサーバ（wana.example.jp）はホストが違うので，フレームで同じ画面に並べても，攻撃者のスクリプトから懸賞システムのフレームの中身は読めない。
本文は続けて，図7 では b が役立たないとしている。これは設問1(4)のとおり，攻撃者のスクリプトを XSS 脆弱性によって懸賞システムのページの中で動かすので，スクリプトが懸賞システムと同じオリジンで実行されるからである。
誤りの選択肢との違い。Asynchronous JavaScript + XML（Ajax）はページを再読込みせずにサーバと非同期に通信する技法，HTTP Strict Transport Security は Web サイトへの接続を HTTPS に限るよう Web ブラウザに指示する仕組み（RFC 6797），JavaScript Object Notation（JSON）はデータの記述形式で，どれもコンテンツの参照を制限する仕組みではない。
CSRF は，攻撃者が用意した罠のページから，ログイン中の利用者の Web ブラウザに正規の画面遷移のリクエストを送らせる攻撃である。対策の定番は，前画面のフォームに攻撃者が推測できない値（トークン）を埋め込み，画面遷移時に受け取った値と照合することである。推測できないようにするため，e は“ランダムな値”になる。
U 社は，従業員数 1,500 名の機械部品製造会社である。横浜に本社及び工場があり，国内 10 か所に営業所がある。U 社では，本社に DMZ を設置し，電子メール（以下，メールという）の送受信，Web の閲覧及び Web サーバによる情報公開に利用している。ドメイン名は，u-sha.co.jp（以下，U 社ドメインという）である。U 社ドメインの管理には，B 社 DNS サービスを利用している。
U 社では，コピー機能，プリント機能，イメージスキャン機能及びイメージ送信機能が一体になった複合機を導入している。
U 社で使用しているメールアドレスを表1に示す。
表1 U 社で使用しているメールアドレス
〔U 社情報システムの構成〕
U 社情報システムのネットワーク構成を図1に，機器の機能概要を表2に示す。
図1 U 社情報システムのネットワーク構成表2 機器の機能概要（抜粋）表2 機器の機能概要（抜粋）（続き）
B 社の DNS サービスに登録されている U 社ドメインの設定を図2に示す。
図2 U 社ドメインの設定（抜粋）
〔情報セキュリティ対策の強化〕
最近，U 社と同業の C 社において，DMZ 上の機器への不正侵入による情報漏えい事件が発生したとの報道があった。事件を知った U 社の経営幹部は，U 社でも同様の問題が起こるおそれがあるかどうかについて，早急に調査するように，情報システム部長に指示した。調査は，情報システム部の K さんが担当し，セキュリティ専門業者 Y 社の W 氏から支援を受けることになった。
〔DMZ 上の機器の設定の点検〕
K さんは，DMZ 上の機器の設定を点検することにした。まず，外部メールサーバ，Web サーバ及び DMZ 上の L2SW を点検することとし，W 氏に相談した。W 氏は，図3のようにインターネットで行われている攻撃の例を説明し，まず，プロキシサーバについて設定を点検すべきであると指摘した。
図3 インターネットで行われている攻撃の例
W 氏は K さんに，プロキシサーバの設定の点検方法を説明した。
〔プロキシサーバの設定の点検〕
K さんは，プロキシサーバの DNS キャッシュ機能について，名前解決問合せパケットの d のランダム化設定の有無を調べ，適切に設定されていることを確認した。K さんは，その設定が行われていない場合，どのようなことが起きるのかを W 氏に質問した。W 氏は，DNS 名前解決通信では UDP が使われており，UDP ヘッダの d のランダム化が設定されていないと，図4に示すような DNS キャッシュ機能への攻撃が成功する可能性が高まると答えた。
図4 DNS キャッシュ機能への攻撃
W 氏は，図4の攻撃の結果，e が，DNS キャッシュに保存させられた MX レコードを参照するので，①メール配送に影響が生じることを説明した。K さんは，W 氏の説明を理解した。
次に，K さんは，URL として，https://www.example.ne.jp/user035/index.html をフィルタリングしようと設定してみたが，パス名を含めた URL 全体を設定できず，ホスト単位のフィルタリングだけが設定できる仕様となっていたことを説明し，その理由を W 氏に質問した。W 氏の回答は，次のとおりであった。
この URL の場合，プロキシサーバ経由で HTTP over TLS 通信が行われる。
PC の Web ブラウザは，CONNECT メソッドを用いてプロキシサーバに接続し，サーバ www.example.ne.jp との間のトンネルの確立を要求する。
PC の Web ブラウザは，プロキシサーバからステータスコードが 200 である応答を受信した後，サーバ www.example.ne.jp との間の TLS セッションを開始する。
W 氏の説明を受け，K さんは，②HTTP over TLS 通信では URL フィルタリングがホスト単位となることを理解した。
K さんは，プロキシサーバが DNS c 攻撃に悪用されないようにする対策を含めて，他の設定を点検し，他に問題がないことを確認した。
〔外部メールサーバの設定の点検〕
K さんは，外部メールサーバの設定を点検した。W 氏は，複合機用メールアドレスを詐称したメールがインターネットから送信されて，マルウェア感染が起きるおそれがあることを指摘した。指摘を踏まえ，K さんは，③外部メールサーバの設定を変更した。さらに，念のため，複合機用メールアドレスを詐称するメールについての注意喚起情報を社内に周知した。
u-sha.co.jp. IN TXT "v=spf1 +ip4:x1.y1.z1.235 -all"
a：インターネットから受け取ったメールを，宛先が自組織と関係のない第三者であっても中継してしまうメールサーバの状態をオープンリレー（第三者中継）という。迷惑メールの送信者はこれを踏み台にする。表2 (1)のように，エンベロープの宛先のドメイン名が U 社ドメイン以外のメールを拒否すれば，外部メールサーバは U 社宛てのメールしか受け付けず，第三者への中継をしない。
b：SPF は，送信元のドメインの管理者が，そのドメインのメールを送信してよいサーバの IP アドレスを DNS に公開し，受信側が送信元の IP アドレスと照合する仕組みである（RFC 7208）。メールの送信元ドメインを詐称していないかを確かめるこの種の技術を送信ドメイン認証と呼び，SPF のほかに DKIM などがある。図2 は U 社ドメインの SPF の設定で，外部メールサーバ（x1.y1.z1.235）以外から送られた U 社ドメインのメールは“-all”によって Fail と判定される。
字数はそれぞれ 10 字以内で，解答例は a が“オープンリレー”（7 字），b が“送信ドメイン”（6 字）。講評は b の正答率が低かったとし，電子メールを悪用した攻撃手法と対策の理解を求めている。b は“認証技術”の前に入る語なので，“送信ドメイン”までを書き，“送信ドメイン認証”と重ねない。
K さんは，プロキシサーバが DNS c 攻撃に悪用されないようにする対策を含めて，他の設定を点検し，他に問題がないことを確認した。
表2 プロキシサーバ
DNS キャッシュ機能及びオープンリゾルバ防止機能
オープンリゾルバは，誰からの名前解決の問合せにも答えてしまう DNS キャッシュサーバである。攻撃者は，送信元 IP アドレスを攻撃対象の IP アドレスに詐称した問合せをオープンリゾルバに大量に送り，その応答を攻撃対象に送り付けさせる。応答は問合せより大きくできるので，攻撃者の送った量より大きなトラフィックが攻撃対象に届く。これが DNS リフレクション攻撃（DNS アンプ攻撃とも呼ぶ）で，c は“リフレクション”である。
本文は c を“オープンリゾルバ防止機能が適切に設定されていない場合に起きる”攻撃とし，“プロキシサーバが DNS c 攻撃に悪用されないようにする”と書いている。プロキシサーバ自身が被害を受けるのではなく，踏み台として他者への攻撃に悪用される攻撃である点が手掛かりになる。出題趣旨も，他のサイトへの攻撃に加担させられ加害者となることに触れている。
W 氏は，DNS 名前解決通信では UDP が使われており，UDP ヘッダの d のランダム化が設定されていないと，図4に示すような DNS キャッシュ機能への攻撃が成功する可能性が高まると答えた。
図4 (3)
攻撃者が，プロキシサーバに対して DNS キャッシュポイズニング攻撃を行い，用意した MX レコードを DNS キャッシュに保存させる。
DNS キャッシュポイズニングでは，攻撃者は DNS キャッシュサーバが送った問合せに対し，本物の応答より先に偽の応答を届けようとする。キャッシュサーバは，問合せと同じ ID を持ち，問合せの送信元ポート番号宛てに返ってきた応答だけを受け付ける。送信元ポート番号が固定だと，攻撃者は 16 ビットの ID だけを当てればよいので，偽の応答が受け付けられやすい。送信元ポート番号を問合せごとにランダムにすれば，当てる組合せが増えて攻撃が成功しにくくなる。d は“送信元ポート番号”である。
本文は d を“UDP ヘッダの”項目としている。UDP ヘッダにあるのは送信元ポート番号・宛先ポート番号・長さ・チェックサムで，このうち問合せのたびに問合せ側が選べるのが送信元ポート番号である（宛先は DNS の 53 番に決まっている）。RFC 5452 も，問合せには予測できない送信元ポートを使うことを求めている。
S 社は，従業員数 100 名の EC サービス会社である。今回，新たにショッピングサイト（以下，S サイトという）と S サイト専用のスマートフォンアプリケーション（以下，S アプリという）から構成されるシステム（以下，S システムという）の開発プロジェクトを立ち上げた。プロジェクトリーダには，サービス開発部の R さんが任命され，S システムのセキュリティについては，セキュリティ専門業者の A 氏の支援を受けることになった。
〔S システムの概要〕
S システムの構成を図1に，S アプリの機能概要を図2に示す。
図1 S システムの構成図2 S アプリの機能概要（抜粋）
〔S アプリでのサーバ証明書の検証試験〕
開発がテスト工程に入り，R さんは，A 氏と共同で，S システムのセキュリティに関する試験を検討し，S サーバの認証を行うためのサーバ証明書の検証が S アプリで適切に行われていることの確認を試験に含めた。
R さんは，図3に示すサーバ証明書の検証試験環境を S 社内に設置し，スマートフォンからは無線 LAN 機能でこの検証試験環境に接続することにした。また，サーバ証明書の検証試験環境で用いる機器と設定を表1に，不正なサーバ証明書の検出についての試験項目を表2にまとめた。
なお，S アプリと試験用 Web サーバ間で HTTPS 通信が確立することは，サーバ証明書の検証試験を実施する前に，試験用 Web サーバに S サイト用サーバ証明書を登録して確認している。
設問1(1)のとおり，S アプリが S サーバの FQDN で接続すると，試験用 DNS サーバの A レコードによって接続先が試験用 Web サーバになる必要がある。試験用のサーバ証明書は試験用 Web サーバに登録するので，S アプリはその証明書を受け取って検証する。b は“試験用Webサーバ”である。
本文も，S アプリと試験用 Web サーバ間で HTTPS 通信が確立することを事前に確認したとしており，S アプリの接続先が試験用 Web サーバであることを前提にしている。A レコードは FQDN を IP アドレスに対応付けるレコードなので，“S サーバの FQDN → 試験用 Web サーバの IP アドレス”となる。
字数制限は無く，図1 又は図3 の構成要素から選ぶ。解答例は“試験用Webサーバ”（9 字）。“試験用 DNS サーバ”“試験用 DHCP サーバ”は名前解決や IP アドレスの割当ての役で，証明書を提示するサーバではない。
本文中の下線①について，攻撃者が，W-AP の設定をどのように細工すると，S アプリの利用者のうち，公衆無線 LAN の利用者のスマートフォンを自動的に W-AP に接続させることができてしまうか。W-AP の設定上の細工を 45 字以内で具体的に述べよ。
解答例
SSID，暗号化方式と事前共有鍵に，公衆無線LANで使用されているものを設定する。
解説
本文の根拠
〔S アプリでのサーバ証明書の検証不備による影響の検討〕（下線①）
①S アプリの利用者が，図4中の W-AP に接続すると，中間者攻撃を受けることを説明した。
図4
スマートフォン（中に S アプリ）が破線（無線通信）で“攻撃者が準備する機器”の W-AP に接続する。
スマートフォンは，一度接続した無線 LAN の SSID と接続の設定を覚えておき，同じ SSID・同じ設定のアクセスポイントの電波を見つけると自動的に接続する。攻撃者が W-AP の SSID，暗号化方式と事前共有鍵を，公衆無線 LAN で使われているものと同じに設定すれば，その公衆無線 LAN を利用したことのあるスマートフォンは，本物と区別せずに W-AP に自動接続してしまう。
こうして W-AP に接続させれば，図4 のとおり，攻撃者の DHCP サーバ・DNS サーバを使わせて，S サイトへの通信を中間者サーバに向けられる。公衆無線 LAN は利用者に事前共有鍵を広く知らせることが多いので，攻撃者も同じ値を設定できる。講評は，無線 LAN アクセスポイントへの接続の仕組みを理解していない解答が散見されたとしている。
字数は 45 字以内で，解答例は“SSID，暗号化方式と事前共有鍵に，公衆無線LANで使用されているものを設定する。”（41 字）。解答例は SSID だけでなく暗号化方式と事前共有鍵も挙げているので，SSID と暗号化の設定の両方を公衆無線 LAN に合わせることを書く。
![左に画面2-1（キャンペーン検索）。“キーワードが含まれるキャンペーンを検索します。”の文の下に，キーワードの入力欄（“チョコ”と入力されている）と検索ボタンがある。矢印で右の画面2-2（検索結果）へ遷移する。画面2-2には“[チョコ]を検索した結果です。”の文の下に，1 ミルクチョコレートキャンペーン，2 ホワイトチョコレートキャンペーン，3 ブラックチョコレートキャンペーン が並び，OKボタンがある。](/data/figures/2016h28h-sc-pm1/q1-f3.png)
![枠内の Java ソースコード（14行）。1: （省略） // import 文など 2: public class Gamen2_2 extends HttpServlet { 3: （省略） // その他のメソッドの定義など 4: public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException { 5: PrintWriter out = res.getWriter(); 6: String kw = req.getParameter("keyword"); // キーワード欄の入力値を取得 7: （省略） // out に HTML の HEAD 部を出力 8: out.println("<BODY>"); 9: out.println("<H1>検索結果</H1>"); 10: out.print("[" + kw + "]を検索した結果です。<br>"); 11: （省略） // out に検索結果以下の HTML を出力 12: } 13: （省略） // その他のメソッドの定義など 14: }](/data/figures/2016h28h-sc-pm1/q1-f4.png)
