平成25年度 秋期 午後Ⅰ（旧試験）

本文の根拠

表2 検出パターン1・2

HTTP レスポンスボディに検査文字列がエスケープ処理などを行われずに出力される場合，脆弱性ありと判定

表2 検出パターン4

HTTP レスポンスボディの特定の URI 属性（src, action, background, href, content）に検査文字列が出力される場合，脆弱性ありと判定

表1 項番③

URL を出力するときは，“http://”又は“https://”で始まる URL だけを許可する。

表2の“脆弱性ありと判定する基準”を，表1の実施項目の文言と突き合わせる。検出パターン1・2・3は，検査文字列が“エスケープ処理などを行われずに出力される”ことを基準にしており，表1では②（Web ページに出力する全ての要素に対して，エスケープ処理を施す）の不備を見つけるものである。パターン3は入力場所が URL 中の最後の“/”に続く文字列という違いだけで，基準は“同上”とされているので同じく②になる。

パターン4は検査文字列が“javascript:alert(document.cookie);”で，基準は URI 属性（src，href など）に検査文字列が出力されるかどうかである。これは URL の先頭を“http://”か“https://”に限る③の不備を見つけるものである。IPA の“安全なウェブサイトの作り方”も，リンク先の URL には“http://”や“https://”から始まる文字列だけを許可するよう求めている。

ここは選択式なので字数の詰め方は要らない。②と③は，出力内容そのものを無害化するか（②），出力してよい URL の形を限るか（③）という違いで見分ける。講評が指摘するとおり，選択問題でも正答率が低かったので，表2の基準の文言が表1のどの項番に対応するかを一つずつ確かめるとよい。

採点講評（IPA）

設問1(1)では判定基準と対策との関連性について出題した。選択問題にもかかわらず，正答率が低かった。

本文の根拠

図1 18行目

escapeHTML(rqUrl)

図1 注記

escapeHTML は HTML の特殊文字 5 文字

表2 検出パターン4

javascript:alert(document.cookie);

図2 項目③

URI 属性出力に対しては制限が必要である。

図1では，リクエストパラメタ name，loc，url の値を取得した後，18〜20行目の出力でいずれも escapeHTML を通している。escapeHTML が処理するのは注記にある特殊文字5文字（<，>，&，"，'）だけである。したがって，表2の検査文字列のうち，これら5文字を含むパターン1・2（'>"><hr> など）は無害化されて出力され，脆弱性ありとは判定されない。

パターン4の“javascript:alert(document.cookie);”にはこの5文字が一つも含まれないので，エスケープしても形が変わらない。これが18行目の href 属性（URI 属性）にそのまま出力されるので，パターン4で脆弱性ありと判定される。図2の診断結果にも，③について“URI 属性出力に対しては制限が必要である。”とある。

ここは番号を答える設問なので字数の詰め方は要らない。本文は，他の脆弱性ありと判定されたものはなかったとしているので，パターン1〜3は除いて4と答える。

採点講評（IPA）

設問1の(2)～(4)，設問2(1)～(3)，(5)，(6)ではそれぞれ原因箇所，問題の種類，対策方法を出題した。原因箇所を正しく特定できると正解を導き出せる。また，原因箇所の特定ができなくても，問題文中の診断結果をよく読めば，問題の種類を特定でき，対策方法を導き出せる。これらの関係を別々に考えるのではなく，一組として理解できれば，さらに正答率が高まるはずである。

本文の根拠

図1 9行目

String rqUrl = request.getParameter("url");

図1 18行目

escapeHTML(rqUrl)

〔社内検査〕

図1に，他の脆弱性ありと判定されたものはなかった。

a で見たとおり，検出されたのはパターン4で，検査文字列は URL の値として扱われて URI 属性に出力される。図1で URL を扱うのは，パラメタ url を rqUrl に取得する9行目と，それを href 属性に書き出す18行目である。出力しているのは18行目なので，原因箇所は18行目になる。

18行目の“<a href="…">”は，escapeHTML でエスケープはしているが，URL の先頭が“http://”か“https://”かどうかは調べていない。9行目は値を受け取るだけで，出力の対策をする場所ではない。19，20行目は loc と name の出力で，表2のパターン4の対象（URI 属性）ではない。

行番号を答える設問なので字数の詰め方は要らない。設問(4)は，ここで答えた18行目に実施する対策を問うているので，a から b までを一組で考えるとよい（講評も，原因箇所を特定できれば正解を導けるとしている）。

採点講評（IPA）

設問1の(2)～(4)，設問2(1)～(3)，(5)，(6)ではそれぞれ原因箇所，問題の種類，対策方法を出題した。原因箇所を正しく特定できると正解を導き出せる。また，原因箇所の特定ができなくても，問題文中の診断結果をよく読めば，問題の種類を特定でき，対策方法を導き出せる。これらの関係を別々に考えるのではなく，一組として理解できれば，さらに正答率が高まるはずである。

本文の根拠

表1 項番③

URL を出力するときは，“http://”又は“https://”で始まる URL だけを許可する。

図2 項目③

URI 属性出力に対しては制限が必要である。

18行目の原因は，href 属性に出力する URL が“javascript:”で始まるものでも，escapeHTML を通ると変わらずに出力される点である。表1の実施項目③は，URL を出力するときに“http://”又は“https://”で始まる URL だけを許可するものなので，これを18行目の出力の前に実施する。IPA の“安全なウェブサイトの作り方”でも，リンク先の URL には“http://”や“https://”から始まる文字列のみを許可する方式（ホワイトリスト方式）で実装するよう求めている。

図2は③を“不合格”とし，備考に“URI 属性出力に対しては制限が必要である。”と書いている。②のエスケープ処理は18行目で行われているので，答えは②（エスケープ）ではなく③（URL の形を限る）の側になる。

40字以内の制限に対し，解答例は“http://”又は“https://”の引用符を含めて36字。“http://”と“https://”の二つの書き出しと，それ“だけを許可する”（許可する範囲を限る方式）という二つの要素を入れる。

採点講評（IPA）

設問1の(2)～(4)，設問2(1)～(3)，(5)，(6)ではそれぞれ原因箇所，問題の種類，対策方法を出題した。原因箇所を正しく特定できると正解を導き出せる。また，原因箇所の特定ができなくても，問題文中の診断結果をよく読めば，問題の種類を特定でき，対策方法を導き出せる。これらの関係を別々に考えるのではなく，一組として理解できれば，さらに正答率が高まるはずである。

本文の根拠

図3 5〜6行目のコメント

rsKey にデータベースに登録されたキーワードで検索回数が一番多いものを取得

図3 17行目

+ rsKey);

図3 24行目

選択候補地区名の値は運用者が設定

図4 53行目の前

検索に使用したキーワード rqKey の値をデータベースに登録

図3では，画面の HTML を組み立てる出力のうち，escapeHTML を通していないものを探す。変数 rsKey を出力する17行目と，変数 rsLoc を option 要素の value 属性と内容に出力する24行目が，エスケープなしで出力している。この二つの行には，表1の②（エスケープ処理）に当たる対策が無い。

17行目の rsKey は，図4の末尾で検索に使ったキーワード rqKey がデータベースに登録され，図3で検索回数の一番多いものを取り出した値である。つまり利用者が入力した文字列がデータベースを経由して戻ってくるので，文字列の中にスクリプトが含まれていれば，そのまま出力されてしまう。24行目の rsLoc は運用者が設定した値だが，表1の②は“全ての要素”に対してエスケープ処理を施すとしているので，値の出どころによらず，施していなければ対策漏れである。

行番号を答える設問なので字数の詰め方は要らない。解答例の備考どおり，c と d は順不同で，17と24のどちらを先に書いてもよい。

採点講評（IPA）

設問1の(2)～(4)，設問2(1)～(3)，(5)，(6)ではそれぞれ原因箇所，問題の種類，対策方法を出題した。原因箇所を正しく特定できると正解を導き出せる。また，原因箇所の特定ができなくても，問題文中の診断結果をよく読めば，問題の種類を特定でき，対策方法を導き出せる。これらの関係を別々に考えるのではなく，一組として理解できれば，さらに正答率が高まるはずである。

本文の根拠

表1 項番②

Web ページに出力する全ての要素に対して，エスケープ処理を施す。

図2 項目②

社内検査の検査対象以外に，対策漏れがある。

c，d の17行目と24行目は，いずれも変数の値をそのまま出力していて，必要なエスケープ処理を施していない。表1でこれに当たるのは②（Web ページに出力する全ての要素に対して，エスケープ処理を施す）である。

図2でも②は“一部不合格”で，備考は“社内検査の検査対象に関してはエスケープ処理が施されている。しかし，社内検査の検査対象以外に，対策漏れがある。”とある。図1と図4はエスケープしているが，図3の二か所が抜けていた，という状況と一致する。

実施項目を選ぶ設問なので字数の詰め方は要らない。③（URL の形の制限）や④（script 要素）は，17行目・24行目の出力が表示するテキストやオプションの値であって URL でもスクリプトでもないので当たらない。

採点講評（IPA）

設問1の(2)～(4)，設問2(1)～(3)，(5)，(6)ではそれぞれ原因箇所，問題の種類，対策方法を出題した。原因箇所を正しく特定できると正解を導き出せる。また，原因箇所の特定ができなくても，問題文中の診断結果をよく読めば，問題の種類を特定でき，対策方法を導き出せる。これらの関係を別々に考えるのではなく，一組として理解できれば，さらに正答率が高まるはずである。

本文の根拠

表2 検出パターン1・2・4

GET パラメタ及び POST パラメタに

表2 検出パターン3

URL 中最後の“/”に続く文字列

図3 5〜6行目のコメント

選択候補地区名の値は運用者が設定

D 君の社内検査は表2の判定基準に従い，検査文字列を入力する場所は“GETパラメタ及びPOSTパラメタ”と“URL 中最後の“/”に続く文字列”に限られる。図3の17行目と24行目に出力される rsKey と rsLoc は，これらの入力場所から直接入る値ではなく，データベースから取り出した値である。そのため，表2の検査をしても，その出力に脆弱性があることは見つからない。

本文は“検査対象を f に限定している”と書いていて，“表2中の字句を用いて”と指示している。図3の rsKey と rsLoc はリクエストパラメタではないので，答えは表2の“検査文字列を入力する場所”の欄にある GET パラメタと POST パラメタを用いて書く。

20字以内の制限に対し，解答例は“GETパラメタ及びPOSTパラメタ”の17字。“GET”“POST”の二つとも落とさないこと。

採点講評（IPA）

設問1の(2)～(4)，設問2(1)～(3)，(5)，(6)ではそれぞれ原因箇所，問題の種類，対策方法を出題した。原因箇所を正しく特定できると正解を導き出せる。また，原因箇所の特定ができなくても，問題文中の診断結果をよく読めば，問題の種類を特定でき，対策方法を導き出せる。これらの関係を別々に考えるのではなく，一組として理解できれば，さらに正答率が高まるはずである。

本文の根拠

図1 注記

escapeHTML は HTML の特殊文字 5 文字（<, >, &, ", '）のエスケープ処理を行うメソッドとして別途定義されている。

〔プログラムの修正〕(1)

定義されているメソッド

図3の修正は，17行目と24行目の出力にエスケープ処理を適用するものである。本文は“定義されているメソッド”を適用すると書いており，図1の注記が escapeHTML を“HTML の特殊文字5文字のエスケープ処理を行うメソッドとして別途定義されている”としている。図1の18〜20行目や図4の35行目，41〜42行目でも同じ escapeHTML が使われていて，同じ書き方で図3にも適用すればよい。

メソッド名は大文字・小文字を含めて原本どおりに書く（escapeHTML）。

メソッド名を答える設問なので字数の詰め方は要らない。講評も，プログラム中から読み取る設問で正答率は高かったとしている。

採点講評（IPA）

設問2(4)では，対策に用いるメソッド名をプログラム中から読み取ることについて出題した。正答率は高かった。

本文の根拠

図4 25〜27行目のコメントとその下

オプションの選択が変更された際に msg1 のテキスト領域に“【地区名】説明”として表示

図4 26行目

escapeHTML(rqLoc)

図2 項目④

スクリプト要素の内容を動的に生成している。命令として解釈される可能性がある。

図4の14〜30行目は，script 要素の中身（JavaScript）を out.print で一行ずつ出力して組み立てている。その中で，リクエストパラメタ loc の値 rqLoc を，26行目で escapeHTML を通してスクリプトの文字列リテラルとして埋め込んでいる。これは図2が④（スクリプト要素の内容を動的に生成しない）を“不合格”とし，“スクリプト要素の内容を動的に生成している。命令として解釈される可能性がある。”と指摘している箇所である。

他の動的な出力は，表示される HTML の本文（35行目の rqKey，41〜42行目の rsName，rsUrl，rsText）や属性値（47〜48行目の rqLoc）で，HTML としてエスケープされている。script 要素の中に値を埋め込んでいるのは26行目だけなので，原因は26行目になる。

行番号を答える設問なので字数の詰め方は要らない。IPA の“安全なウェブサイトの作り方”も，<script>…</script> 要素の内容を動的に生成する仕様は避けるよう勧めている。

採点講評（IPA）

設問1の(2)～(4)，設問2(1)～(3)，(5)，(6)ではそれぞれ原因箇所，問題の種類，対策方法を出題した。原因箇所を正しく特定できると正解を導き出せる。また，原因箇所の特定ができなくても，問題文中の診断結果をよく読めば，問題の種類を特定でき，対策方法を導き出せる。これらの関係を別々に考えるのではなく，一組として理解できれば，さらに正答率が高まるはずである。

本文の根拠

表1 項番④

スクリプト要素の内容（“<script>…</script>”の“…”部分）を動的に生成しない。

図2 項目④

スクリプト要素の内容を動的に生成している。命令として解釈される可能性がある。

h の26行目は，script 要素の内容に rqLoc を埋め込んでいる行である。表1でこれに当たるのは④（スクリプト要素の内容を動的に生成しない）で，図2の④の備考がそのまま“スクリプト要素の内容を動的に生成している。命令として解釈される可能性がある。”と書いている。

26行目は escapeHTML を通している（②は施している）が，図2が④を不合格とするとおり，スクリプト要素の内容を動的に生成していること自体が④の不備である。本文が“不十分であった”と書いているのは，②を全くしていないのではなく，④の観点で足りないという意味である。

実施項目を選ぶ設問なので字数の詰め方は要らない。②と④の違いは，②が出力内容を無害化する対策，④が出力する場所そのもの（スクリプト要素の内容）を動的にしない対策であること。

採点講評（IPA）

設問1の(2)～(4)，設問2(1)～(3)，(5)，(6)ではそれぞれ原因箇所，問題の種類，対策方法を出題した。原因箇所を正しく特定できると正解を導き出せる。また，原因箇所の特定ができなくても，問題文中の診断結果をよく読めば，問題の種類を特定でき，対策方法を導き出せる。これらの関係を別々に考えるのではなく，一組として理解できれば，さらに正答率が高まるはずである。

本文の根拠

図4 17〜21行目のコメント

選択ボタン押下時に選ばれている select オプションの値を変数 url と name の値に設定

図4 25行目

document.form1.msg1.value

図4 47〜48行目

escapeHTML(rqLoc)

26行目の目的は，msg1 のテキスト領域に“【地区名】説明”の“地区名”として rqLoc の値を表示することである。スクリプトの中に値を書き込む代わりに，スクリプトが実行時に取り出すようにすれば，スクリプト要素の内容を動的に生成しないという④の対策になる。

図4の47〜48行目は，form1 の中に name="loc" の hidden フィールドを出力し，その value 属性に escapeHTML(rqLoc) を書き出している。つまり loc の値は既にフォームの項目として画面に載っている。したがって26行目を，その値を読む document.form1.loc.value に置き換えれば，25行目と27行目と合わせて“document.form1.msg1.value = "【" + document.form1.loc.value + "】 " + …”という式になり，rqLoc はスクリプトの中に出てこなくなる。

1行のソースコードで答える設問なので字数の詰め方は要らない。解答例は out.print("document.form1.loc.value"); で，out.print で書き出す文字列として“document.form1.loc.value”を引用符で囲むこと，末尾の“;”を落とさないこと。講評は，修正範囲をできるだけ限定してプログラムを修正する力をつけてほしいとしている。

採点講評（IPA）

設問2(7)では，特定した原因箇所を修正することについて出題した。無解答が多かった。できるだけ修正範囲を限定した上で，プログラムを修正する能力をつけてほしい。

本文の根拠

〔スマホアプリの利用者認証〕

端末識別番号の特性を考えると，自分の端末識別番号を別の端末で利用されて，サービスを不正利用されるおそれがある

〔スマホアプリの利用者認証〕

スマートフォンには，IMEI（International Mobile Equipment Identity）などの固有の端末識別番号が付与されています

端末識別番号は端末ごとに付与された固有のコードで，端末を区別する識別子ではあるが，利用者本人だけが知る秘密の値ではない。そのため，他人がその値を知って別の端末から使うことができてしまう。C 課長の指摘“自分の端末識別番号を別の端末で利用されて，サービスを不正利用されるおそれがある”は，この特性を言ったものである。

識別子（誰かを区別するもの）と認証情報（本人であることを示す秘密）は役割が違う。パスワードのように本人だけが知っているはずの値なら認証に使えるが，端末識別番号は秘密ではないので，そのまま利用者認証に使えない。

20字以内の制限に対し，解答例は“秘密情報ではないという特性”の13字。“秘密”という語を入れ，“識別番号は固有である”のような，認証に使えない理由にならない特性を書かない。

採点講評（IPA）

設問1では，スマホアプリの利用者認証について出題した。(2)は選択問題にもかかわらず，正答率は低かった。暗号方式やハッシュ関数について正確に覚えておいてほしい。

本文の根拠

〔スマホアプリの利用者認証〕

端末識別番号を基にスマホアプリ内で②鍵付きハッシュ関数で算出したハッシュ値を使うという方法はどうでしょう。

鍵付きハッシュ関数は，共有した秘密の鍵とハッシュ関数を組み合わせて，メッセージが改ざんされていないことと作成者を確認する仕組みで，HMAC がこれに当たる（RFC 2104 は HMAC を“暗号学的ハッシュ関数を用いたメッセージ認証の仕組み”とし，秘密の共有鍵と組み合わせて使うと説明している）。したがって解答群ではイの HMAC が正しい。

アの AES は FIPS 197 で規定されたブロック暗号で，ハッシュ関数ではない。ウの RIPEMD とエの SHA-256 はどちらもハッシュ関数だが，それ自体は鍵を取らない。SHA-256 は FIPS 180-4（Secure Hash Standard）のハッシュ関数に含まれる。

記号で答える設問なので字数の詰め方は要らない。講評は，選択問題でも正答率が低かったので，暗号方式やハッシュ関数について正確に覚えておいてほしいとしている。“鍵付き”という語が付くものは HMAC と覚える。

採点講評（IPA）

設問1では，スマホアプリの利用者認証について出題した。(2)は選択問題にもかかわらず，正答率は低かった。暗号方式やハッシュ関数について正確に覚えておいてほしい。

本文の根拠

〔スマホアプリの利用者認証〕

このスマホアプリ専用の鍵を一つ用意して，スマホアプリ内に格納しておけば，不正利用を防ぐことができるのではないか

〔スマホアプリの利用者認証〕

鍵を秘密にしておくことが難しい

B さんの案は，スマホアプリ専用の鍵を一つだけ用意して，全てのスマホアプリの中に格納する方法である。スマホアプリは誰でも入手できる配布物なので，攻撃者は自分のスマートフォンに入れたアプリを手元で解析できる。アプリの実行ファイルを解析して中身を読み取ること（リバースエンジニアリング）で，格納された鍵を取り出せてしまう。鍵が分かれば，攻撃者は他人の端末識別番号に対するハッシュ値も自分で計算できる。

鍵を共通で一つだけ持たせる以上，アプリに組み込んだ時点で配布先の全員に渡ったのと同じことになる。C 課長が“鍵を秘密にしておくことが難しい”と言うのは，この点を指している。

30字以内の制限に対し，解答例は“スマホアプリをリバースエンジニアリングする。”の22字。解答例の用語はリバースエンジニアリングで，アプリを解析して鍵を取り出すという筋を一文に収める。

採点講評（IPA）

設問1では，スマホアプリの利用者認証について出題した。(2)は選択問題にもかかわらず，正答率は低かった。暗号方式やハッシュ関数について正確に覚えておいてほしい。

本文の根拠

表1 (4) 予約案内

スマートフォン内のアドレス帳の全件データを WebAP に送信

〔予約案内サービスの問題〕

アドレス帳の全件データが R 社に送信されることについては利用者に説明していないので問題である

〔予約案内サービスの問題〕

“アドレス帳の全件データの送信”が行われない別の案（以下，A 案という）が提示され，A 案を採用することになった。

予約案内サービスの現行案は，利用者が“はい”を選ぶと，アドレス帳の全件データを WebAP に送り，WebAP が全件の中から参加予定者を選んでメールを送る。メンバが問題としたのは，利用者が案内したい人以外の分まで含めて R 社に送られる点である。A 案は“全件データの送信が行われない”案なので，友達の選択をスマートフォンのスマホアプリ側で済ませる形にすればよい。

つまり，アドレス帳から参加予定者のメールアドレスをスマホアプリ上で選択し，選択したものだけを WebAP に送る。WebAP は受け取ったメールアドレスに予約情報を記載したメールを送れば，要件（参加予定者にメールで案内する）を満たす。

40字以内の制限に対し，解答例は“スマホアプリでメールアドレスを選択して，それをWebAPに送信する。”の34字。“スマホアプリで選択する”と“選択したメールアドレスだけを WebAP に送る”の二つの要素を入れる。講評は，全件データを送信しなくても要件を満たせる手段を考えれば正解を導けるとしている。

採点講評（IPA）

設問2では，スマホアプリを利用したサービスにおける問題点の改善案について出題した。正答率は高かった。アドレス帳の全件データを送信しなくても要件を満たせる手段を考えれば，正解を導けるはずである。

本文の根拠

表2

AuthKey パラメタの値を別利用者の値に変更：YoyakuCode が 201310000034 の予約情報の表示

表2

YoyakuCode パラメタの値を 201310000071 に変更：YoyakuCode が 201310000071 の予約情報の表示

表2

DateTime パラメタの値を現在から 4 分前の時刻に変更：YoyakuCode の値に該当する予約情報の表示

図3 2.

DateTime の値とサーバ側の時刻とのずれが 5 分以上の場合はアプリケーションエラーを返す。

表2で，応答がアプリケーションエラーにも認証エラーにもならなかったのは，AuthKey を別利用者の値に変えたとき（YoyakuCode 34 の予約情報が返る），YoyakuCode を 201310000071 に変えたとき（71 の予約情報が返る），DateTime を現在から4分前にしたとき（YoyakuCode に該当する予約情報が返る）である。AuthKey を別利用者の値に変えても認証エラーにならず，もとの YoyakuCode（34）の予約情報が返るので，AuthKey と YoyakuCode の組合せは確かめられていない。図3の動作概要(c)は AuthKey が保持されている値と一致するかだけを，(d)は YoyakuCode が DB の予約明細コードと一致するかだけを見ている。両者の対応を見ていないので，利用者 V の AuthKey のまま YoyakuCode を利用者 W のものに変えれば，W の予約情報が返る。

一方，利用者 V のリクエスト（図4）の DateTime は数日前のものなので，(e)の“サーバ側の時刻とのずれが5分以上の場合はアプリケーションエラー”に当たる。したがって，もう一つ変更が要るのが DateTime で，送信時の時刻とのずれが5分未満の値にすれば，エラーにならずに W の予約情報（YoyakuCode 201310000071）が得られる。

二つのパラメタとその内容を，順不同で答える設問である。講評にあるとおり，DateTime を AuthKey と誤って答える例が多かったので，各パラメタの役割（AuthKey は利用者認証用のキーで，利用者 V の値のままでよい）を押さえる。解答例は“YoyakuCode＝利用者WのYoyakuCode”，“DateTime＝送信時とのずれが5分未満の時刻”。

採点講評（IPA）

設問3では，スマホアプリからのリクエストを処理するWebアプリケーションの問題点について出題した。(1)では二つのパラメタのうち“DateTime”を“AuthKey”と誤って解答した受験者が多かった。各パラメタの役割をよく理解して，正解を導いてほしかった。各パラメタの役割を理解できれば，(2)の追加する仕様として“YoyakuCode”と“AuthKey”との対応をチェックしなければならないということも導けるはずである。

本文の根拠

図3 2.(c)

AuthKey の値が WebAP に保持されている利用者認証用の値と一致しない場合は認証エラーを返す。

図3 2.(d)

YoyakuCode の値が DB サーバに保持されている予約明細コードと一致しない場合はアプリケーションエラーを返す。

他人の予約情報が取得できた原因は，AuthKey（認証済みの利用者を示す）と YoyakuCode（取得する予約明細）がそれぞれ別々にしか検査されておらず，二つの組合せが正しいかを確かめていないことである。図3の(c)は AuthKey の正しさだけ，(d)は YoyakuCode が DB に存在するかだけを見ている。

対策は，図3の2.に，その YoyakuCode が AuthKey の利用者自身の予約明細コードであるかを確かめる仕様を足すことである。対応していなければアプリケーションエラーを返す，とすれば，利用者 V が W の YoyakuCode を送っても情報は返らない。講評も，各パラメタの役割を理解できれば，YoyakuCode と AuthKey との対応をチェックしなければならないと導けるとしている。

55字以内の制限に対し，解答例は“YoyakuCodeの値がAuthKeyに対応する予約明細コードでないときはアプリケーションエラーを返す。”の53字。“対応するか確かめる”という条件と，“対応しなければエラーにする”という動作の二つを入れる。

採点講評（IPA）

設問3では，スマホアプリからのリクエストを処理するWebアプリケーションの問題点について出題した。(1)では二つのパラメタのうち“DateTime”を“AuthKey”と誤って解答した受験者が多かった。各パラメタの役割をよく理解して，正解を導いてほしかった。各パラメタの役割を理解できれば，(2)の追加する仕様として“YoyakuCode”と“AuthKey”との対応をチェックしなければならないということも導けるはずである。

本文の根拠

図2 (1)

利用者が，利用者の氏名，利用者 ID，ワンタイムパスワード送信先として希望する携帯電話メールアドレスを指定して，利用者 ID 登録の申請メールを作成し，送付

図2 (3)

管理責任者が，申請メールの携帯電話メールアドレスに仮パスワードを送信

図2の手順では，利用者になりたい人が申請メールに自分で希望する携帯電話メールアドレスを書き，管理責任者はその申請メールの携帯電話メールアドレスに仮パスワードを送る。申請メールは誰でも作成できるので，第三者が利用者になりすまして，自分の携帯電話メールアドレスを指定して申請すれば，仮パスワードが第三者の携帯電話に届く。これが“簡単に入手できてしまう”理由である。

対策は，申請メールの内容だけを信用せず，管理責任者が申請者に直接（電話や対面で）申請の事実を確認する，という本人確認である。申請メールの送信元は偽装できるし，メールアドレスと氏名が正しいかも申請メールだけでは分からないので，メールとは別の経路で確認する必要がある。

各25字以内の制限に対し，解答例は“第三者自身の携帯電話メールアドレスを指定して申請”が24字，“管理責任者が申請者に直接申請の事実を確認する。”が23字。方法には“第三者自身の”携帯電話メールアドレスを指定する，という点を，対策には“直接”確認するという点を入れる。

採点講評（IPA）

設問1では，2要素認証の利用を開始するプロセスについて出題した。2要素認証は，パスワードだけを用いた認証に比較すると安全性を格段に高めることが可能であるが，運用が不適切であるとその目的は達成できない。2要素認証の利用開始プロセスにおいてどのようなリスクがあるかを認識し，正しいプロセスを設計することが重要である。

本文の根拠

図3 注1

このクッキーは 90 日間有効である。

図3 (2)

利用者 ID に対して発行した，有効期間内のクッキーが送られてきた場合は(6)へ，それ以外の場合は(3)へ

〔C サービスの認証の強化〕

盗難，紛失があった場合には必ず総務部に連絡することになっている。

図3の認証では，ログイン時に携帯電話に送られたワンタイムパスワードを入力して認証に成功すると，利用者 ID に対するクッキー（有効期間90日）がブラウザに保存される。(2)にあるとおり，有効期間内のクッキーが送られてくれば(3)のワンタイムパスワードの手順を飛ばして(6)に進む。個人の携帯電話が盗まれ，利用者 ID とパスワードが推測されると，盗んだ人がワンタイムパスワードを受け取って認証に成功し，クッキーを入手できる。その後は携帯電話を失った利用者が対処しても，クッキーが有効な間は，パスワードと携帯電話を使わずにログインできる。これが，不正使用が長期間続く理由（クッキーが有効である間，不正使用が可能なこと）である。

対策は，認証に使っている携帯電話について，紛失や盗難が起きたら届け出る義務を定め，総務部が届出を受けたらただちに C サービスのパスワードを変更する，という運用である。講評は，クッキーに関する対応を答える受験者が多かったが，効果は限定的であり，管理者が速やかに対応できるように確実に届け出させることが必要だとしている。

理由は30字以内に対し解答例が22字。対策は70字以内に対し解答例が63字で，“届出を義務化”“直ちにパスワードを変更”の二つの要素を入れる。

採点講評（IPA）

設問2では，2要素認証に利用している携帯電話に盗難，紛失があった際の対応について出題した。不正使用が継続してしまう理由については正答率が高かった。一方，その対策についての正答率は低く，クッキーに関する対応を答えた受験者が多く見受けられた。クッキーに関する対応では効果は限定的である。認証に利用している要素（この場合は携帯電話）の盗難・紛失に対しては，管理者が速やかに対応できるように，確実に届け出させることが必要であることを認識してほしい。

本文の根拠

表2 1行目 想定シナリオ・業務レベル

C サービス停止の 24 時間後にはプロジェクト資料を使う業務を再開できる。

表2 1行目 現実化してから

ファイルサーバを用いて，b する。

表2 2行目 現実化してから

C サービスのデータを代替サービスに移行する。

〔C サービスの認証の強化〕

社内にファイルサーバを設置して利用していたが

a・b は1行目（C サービスが2週間停止し，その後復旧する）の欄である。業務レベルは“停止の24時間後にはプロジェクト資料を使う業務を再開できる”で，停止中は C サービスを使えない。事前準備として，C サービスにあるプロジェクト資料を定期的にファイルサーバへバックアップしておけば（a），停止してから，ファイルサーバを用いてバックアップしたプロジェクト資料を共有する（b）ことで，業務を続けられる。P 社には社内のファイルサーバがもともとあり，リモート PC からも RAS 経由で社内システムにアクセスできる。

c は2行目（C サービスの提供が終了する）の欄である。現実化してから“C サービスのデータを代替サービスに移行する”ので，事前に，C サービスからデータをどのような方法で取り出せるか，つまりデータの移行方法を確認しておく。移行できなければ代替サービスに乗り換えても業務効率を落とさずに続けられない。

字数は a が35字以内（解答例27字），b が25字以内（19字），c が15字以内（8字）。a には“定期的に”と“ファイルサーバ”へ“バックアップ”の三つを，b には“バックアップしたプロジェクト資料”を“共有”するという二つを入れる。講評は，事業継続の設問は正答率が高く，可用性の検討と事前の対策の必要性は理解されていたとしている。

採点講評（IPA）

設問3では，パブリッククラウドサービスを用いた業務の事業継続に関して出題した。正答率は高かった。パブリッククラウドサービスを利用する際には，可用性についても検討を行い，必要な対策をあらかじめ実施することが必要であるという点については理解されていたようだ。