平成26年度 春期 午後Ⅰ（旧試験）

本文の根拠

〔ソフトウェアの基本設計〕

セッション管理には，ログオン時にランダム文字列をセッション ID として割り当てた上で，クエリパラメタの中にセッション ID を格納する方式を採用するつもりです。

〔ソフトウェアの基本設計〕

GET メソッドではなく POST メソッドを使用しておかないと，①HTTP ヘッダ内のフィールドが原因で，バナー広告に設定されたリンク先の Web サーバへセッション ID が漏えいする

V 君の方式は，セッション ID をクエリパラメタ，つまり URL の一部に入れる。URL にセッション ID が載ったページから広告主のサイトへのリンクをたどると，ブラウザは“どのページからたどってきたか”を HTTP ヘッダの Referer フィールドに入れて送る。この中にセッション ID を含む URL がそのまま入るので，リンク先の Web サーバにセッション ID が漏れる。RFC 9110 の 17.9 も，Referer がユーザの閲覧履歴を明かしうると注意している。

Q 主任が POST メソッドを勧めているのは，POST ならセッション ID が URL ではなくメッセージボディに入り，Referer に載らないからである。本文が“HTTP ヘッダ内のフィールド”と限定しているので，答えはヘッダのフィールド名になる。

英字 10 字以内の制限に対し，解答例は“Referer”の7字。綴りは Referer で，間違えやすいので書き取れるようにしておく。

採点講評（IPA）

設問1は，全体として正答率が高かった。Webアプリケーションにおけるクライアントサイドスクリプトの役割とセキュリティ上の限界については，脆弱性を排除するために確実に理解しておく必要がある。

本文の根拠

図2

アップロードするファイルの拡張子を調べて，画像ファイルかどうか判定し，画像でないファイルの送信を停止する。

〔ソフトウェアの基本設計〕

制限する方式として，V 君は，Web ブラウザにおいてスクリプトによって判定することを考えた。

図2のスクリプトは，利用者の Web ブラウザの中で動き，拡張子を調べて画像でなければ送信を止める。つまり判定はブラウザの機能に頼っており，ブラウザを操作する契約者の側で止められる。契約者がブラウザの設定でスクリプトの実行を無効にすれば，この判定は動かず，画像でないファイルもそのまま送信できる。

どのファイルをアップロードできるかを決める役目が，利用者側のブラウザに置かれていることが問題点である。次の設問(3)の“スクリプトによらない方式”は，この問題点をなくすための対策になっている。

30字以内の制限。解答例は“ブラウザの設定でスクリプトを無効化する。”（20字）。“ブラウザの設定”と“スクリプトを無効化”の二つの要素を入れる。

採点講評（IPA）

設問1は，全体として正答率が高かった。Webアプリケーションにおけるクライアントサイドスクリプトの役割とセキュリティ上の限界については，脆弱性を排除するために確実に理解しておく必要がある。

本文の根拠

〔システム・ソフトウェア要件定義〕

S サービスは Java サーブレットを利用した Web アプリケーションで構成することにした。

図1

クライアント側は Web ブラウザだけとし，専用アプリケーションは使用しない。

下線②の問題は，拡張子の判定が利用者のブラウザで行われ，契約者が止められる点にあった。スクリプトによらない方式とは，判定をブラウザの外，つまりサーバ側に置く方式である。S サービスは Java サーブレットを使った Web アプリケーションで構成されるので，ファイルを受け取った Web アプリケーション側で拡張子を判定し，画像ファイルのものでなければ受け付けない。

要件案はクライアント側を Web ブラウザだけとし，専用アプリケーションを使わないと決めているため，クライアント側に別の判定の仕組みを足すという答えにはならず，サーバ側（Web アプリケーション）で行う，という方向になる。

30字以内の制限。解答例は“Webアプリケーションで拡張子判定を行う。”（21字）。判定する場所（Web アプリケーション）と判定の中身（拡張子判定）の二つを入れる。

採点講評（IPA）

設問1は，全体として正答率が高かった。Webアプリケーションにおけるクライアントサイドスクリプトの役割とセキュリティ上の限界については，脆弱性を排除するために確実に理解しておく必要がある。

本文の根拠

図6

16: unsigned short int f_version, cols, rows, colors;

図6

38: bytesOfBuff = bytesOfRow * fhBuf.rows;

図6

50: fread(pixBuf, kColors, fhBuf.cols, fp);

〔画像処理プログラムでの不具合〕

この処理系において，int 型は 4 バイト，short int 型は 2 バイト，char 型は 1 バイトである。

ヘッダ部の cols と rows は，2バイトの符号なし整数（unsigned short int）なので，それぞれ 65535 まで取れる。36〜37 行で bytesOfRow は，cols×3 を 256 の倍数に切り上げた値になり，最大で 196608 である。38 行はこれに rows を掛けて int 型（4バイト）の bytesOfBuff に入れるので，最大で 196608×65535＝12,884,705,280 となり，int 型で表せる範囲（kMaxInteger＝0x7fffffff＝2,147,483,647 まで）を超える。この桁あふれが 38 行で起きる“整数オーバフロー”で，a が入る。

桁あふれして小さな値（又は負の値）になった bytesOfBuff は，39 行の“kMaxMatData より大きいか”の検査をすり抜け，41 行の malloc では小さな領域しか確保されない。ところが 47〜53 行のループは，rows 行ぶんの本来の大きさのデータを 50 行の fread で pixBuf へ書き込むので，確保した領域を超えて書き込まれる。これが“バッファオーバフロー”で，b が入る。

字数はどちらも 15 字以内。解答例は“整数オーバフロー”（8字）と“バッファオーバフロー”（10字）。a は“桁あふれ”といった意味の言い換えでなく，用語で書く。

採点講評（IPA）

設問2は，全体として正答率が低かった。

本文の根拠

図6

36: bytesOfRow = fhBuf.cols * fhBuf.colors;

図6

37: bytesOfRow += 255 - ((bytesOfRow + 255) % 256);

図6

38: bytesOfBuff = bytesOfRow * fhBuf.rows;

図6

11: const int kMaxInteger = 0x7fffffff;

整数オーバフローが起きるのは，38 行の掛け算 bytesOfRow × fhBuf.rows の結果が int 型の最大値 kMaxInteger を超えるときである。bytesOfRow は，36 行でヘッダ部の列数（cols）と各ピクセルのバイト数（colors）の積にし，37 行でその値を 256 バイト境界に合わせるパディングを加えたものである。したがって条件は“（列数×各ピクセルのバイト数＋パディング）×行数が kMaxInteger を超える”となる。

図3のとおり，列数・行数・各ピクセルのバイト数は，どれも画像ファイルのヘッダ部に書かれた値で，ファイルの作り手が決められる。ファイルのサイズが小さくても，ヘッダ部の値が大きければこの条件を満たせる。“ファイルサイズが大きい”と答えると，実際のファイルの大きさとヘッダ部の値が一致しない，攻撃者が作った画像を考慮していないことになる。

60字以内の制限。解答例は“ヘッダ部の列数と各ピクセルのバイト数の積にパディングを加えたものと，行数の積がkMaxIntegerを超える。”（55字）。設問が kMaxInteger という字句を使うよう指定しているので，必ず入れる。

採点講評（IPA）

設問2は，全体として正答率が低かった。設問2(2)において，単にファイルサイズに着目した解答が多かったが，攻撃用にヘッダ部を改ざんするなどの特別な作り込みがされたファイルについても考慮することが必要である。

本文の根拠

図7

if ( c < d ) throw out_of_range("Image too large");

図6

11: const int kMaxInteger = 0x7fffffff;

図6

35: if (fhBuf.cols == 0 || fhBuf.rows == 0) throw out_of_range("Illegal header");

図6

38: bytesOfBuff = bytesOfRow * fhBuf.rows;

追加する行は，37 行（bytesOfRow が決まった後）と 38 行（掛け算）の間に置き，掛け算が kMaxInteger を超えるときに例外にする。“bytesOfRow * fhBuf.rows > kMaxInteger”と書くと，この比較の左辺の掛け算で，すでに整数オーバフローが起きてしまう。そこで，掛け算を割り算に直して，オーバフローの起きない式で比べる。図7は“c < d”の形で，どちらか一方に kMaxInteger を含む必要があるので，“kMaxInteger / bytesOfRow < fhBuf.rows”（イ群）か，“kMaxInteger / fhBuf.rows < bytesOfRow”（ア群）になる。整数の割り算は切り捨てだが，どちらも“bytesOfRow × fhBuf.rows が kMaxInteger を超える”ことと同じ意味になる。

割る数は 0 でない必要があるが，35 行で cols と rows がどちらも 0 でないことを確かめており，34 行で colors が kColors（3）と確認されるので bytesOfRow も 0 にならない。どちらの割り算でも 0 除算にはならない。解答例は，同じ群の組合せで答えればどちらも正解としている（c が kMaxInteger / fhBuf.rows なら d は bytesOfRow，c が kMaxInteger / bytesOfRow なら d は fhBuf.rows）。

この設問は字数制限のない式の穴埋めで，間違えやすいのは次の点である。掛け算のまま“bytesOfRow * fhBuf.rows < kMaxInteger”と書くと，比べる前にオーバフローして意味が無い。また，c と d を別の群から取って“kMaxInteger / fhBuf.rows < fhBuf.rows”のように組み合わせると，条件が成り立たない。

採点講評（IPA）

設問3は，全体として正答率が低かった。設問に挙げた不等式において，左辺及び右辺それぞれの演算で整数オーバフローが発生する可能性についての考慮が不足した解答が目立った。

本文の根拠

〔インターネット接続システムの概要〕

ログを収集，転送する方式には，UNIX で一般的に使われている a というプロトコルを利用している。

〔インターネット接続システムの概要〕

インターネット接続システムの各サーバでは，サーバへのアクセス及びサーバ上でのプログラムの動作のログをログサーバに保存している。

空欄 a は，UNIX で一般的に使われ，各サーバのログをログサーバへ収集・転送するプロトコルで，syslog である。syslog は，RFC 5424 が“イベントの通知メッセージを伝えるためのプロトコル”と位置付けているもので，サーバ上のプログラムの動作やアクセスのログを，ネットワーク越しにログサーバへ送る使い方に当たる。

本文の手掛かりは“UNIX で一般的に使われている”と“ログを収集，転送する”の二つで，どちらも syslog を指す。図1では各サーバとは別にログサーバが置かれており，この構成とも合う。

英字 8 字以内の制限。解答例の“syslog”は6字で，大文字小文字は問われない用語である。

本文の根拠

図3

a-sha.co.jp. IN TXT "v=spf1 +ip4:x1.y1.z1.4 b "

〔インターネット接続システムの概要〕

A 社のメールアドレスを使ったメールを送信するのは外部メールサーバだけである。

図3

注記 1 x1.y1.z1.3 は迷惑メール対策装置の IP アドレス，x1.y1.z1.4 は外部メールサーバの IP アドレスである。

図3の TXT レコードは SPF の設定で，“+ip4:x1.y1.z1.4”は，A 社のメールを送信できるサーバとして外部メールサーバの IP アドレスを許可している（修飾子の“+”は pass で，書かなければ既定で“+”になる。RFC 7208 4.6.2）。A 社のメールアドレスで送信するのは外部メールサーバだけなので，それ以外のサーバから A 社ドメインで送られたメールは，なりすましとして拒否させたい。そのためのものが，レコードの最後に置く“all”メカニズムで，どの送信元にも必ず一致する（RFC 7208 5.1）。これに修飾子“-”を付けた“-all”は，それまでのメカニズムに一致しなかった送信元に fail を返す。受信側の迷惑メール対策装置は，SPF 判定が NG のメールを拒否する（図2）。

似た書き方との違いは次のとおり。“+all”は全ての送信元を pass にするので，なりすましを防げない。“~all”は softfail，“?all”は neutral で，どちらも明確な fail にならない。講評も，なりすましを拒否してもらうために SPF レコードの設定方法を是非知っておいてほしい，と述べている。

字数は“英字及び記号 5 字以内”。解答例の“-all”は4字で，記号の“-”を落とさずに書く。

採点講評（IPA）

設問1(2)は，正答率が低かった。電子メールにおけるなりすましを拒否してもらうために，SPF(Sender Policy Framework)レコードの設定方法を是非知っておいてほしい。

本文の根拠

図3

a-sha.co.jp. IN MX 10 msv1.a-sha.co.jp.

図3

a-sha.co.jp. IN MX 20 msv2.a-sha.co.jp.

図3

注記 1 x1.y1.z1.3 は迷惑メール対策装置の IP アドレス，x1.y1.z1.4 は外部メールサーバの IP アドレスである。

表2

2：インターネット，外部メールサーバ，SMTP，許可。

表1

外部メールサーバ：内部メールサーバからインターネットへのメール転送機能及びメールに対するウイルススキャン機能がある。

図3の MX レコードは，優先度 10 が msv1（x1.y1.z1.3，迷惑メール対策装置），優先度 20 が msv2（x1.y1.z1.4，外部メールサーバ）である。普通の送信側は優先度の小さい msv1 に送るが，迷惑メールの送信者は，優先度の低い msv2 を狙ったり，外部メールサーバの IP アドレスを直接指定したりして送ることができる。FW の表2 項番 2 は，インターネットから外部メールサーバへの SMTP を許可しているので，この通信は FW を通る。外部メールサーバには，表1のとおりウイルススキャン機能はあるが迷惑メールフィルタリング機能は書かれていない。このため，迷惑メール対策装置を経由せずに送られたメールは，フィルタリングされないまま，外部メールサーバから内部メールサーバへ転送される（表2 項番 5）。

調査では全ての機器が設定どおり動いていた，と本文にあるので，機器の故障ではなく，この設定の穴が原因である。

35字以内の制限。解答例は“インターネットから迷惑メール対策装置を経由せずに送られていた。”（31字）。“どこから”（インターネット）と“どう送られたか”（迷惑メール対策装置を経由せず）の二つを入れる。

本文の根拠

〔迷惑メール対策装置のユーザ登録ルールの見直し〕

たとえ取引先の IP アドレスを IP アドレス WL に登録していたとしても，メールが急に届かなくなる可能性もある。

表3

1：IP アドレス WL，IP アドレスの並び，メールの送信元 IP アドレス。

IP アドレス WL は，メールの送信元 IP アドレスと突き合わせて許可を決める（表3 項番 1）。取引先のメールサーバの IP アドレスが変わると，WL に登録してあった古いアドレスと一致しなくなり，取引先のメールが WL の対象から外れて，ほかのルールや SPF 判定で拒否される可能性が出てくる。メールが急に届かなくなるのはこのときで，登録内容の見直しが必要になる。

講評は，“MX レコードの設定を変更する”のように IP アドレスとは関係のない設定について述べた解答が見られた，と述べている。IP アドレス WL が IP アドレスで一致を見ていることを押さえて，IP アドレスが変わる場合を書く。

25字以内の制限。解答例は“メールサーバのIPアドレスが変更された場合”（21字）。“事象”を聞かれているので，文末は“〜場合”で締める。

採点講評（IPA）

設問3(1)は，正答率が高かった。“MXレコードの設定を変更する”というように，IPアドレスとは関係ない設定について述べた解答が散見された。IPアドレスWLが，IPアドレスをマッチングに使うことについて注意して解答してほしい。

本文の根拠

〔迷惑メール対策装置のユーザ登録ルールの見直し〕

SPF を使えばドメイン名を詐称する迷惑メールの拒否が可能である。しかし，②迷惑メール送信者の行為によっては，迷惑メール対策装置が SPF を使って正しいと判定したサーバから送信された迷惑メールを防ぐことができない

表3

3：ドメイン名 WL，ドメイン名の並び，エンベロープの送信者メールアドレスのドメイン名。

SPF は，エンベロープの送信者メールアドレスのドメインが公開している SPF レコードに，送信してきたサーバが許可されているかを調べる仕組みで，ドメインの詐称は見破れる。しかし，迷惑メールの送信者自身がドメインを正当に取得し，自分のサーバを許可する SPF レコードを公開していれば，そのサーバから送った迷惑メールの SPF 判定は OK となり，図2の流れでは許可される。SPF が確かめるのは“ドメインの持ち主が許可したサーバか”であって，メールの中身の善し悪しではないからである。このような送信者は，ドメイン名 BL に登録しないと防げない。

講評は，“送信元の IP アドレスを詐称したパケットを送り込む”といった解答が目立ったが，SMTP は TCP 上で動作するので事実上 IP アドレスを詐称できない，と述べている。本文の“正しいと判定したサーバから送信された”という前提を読み落とさない。

30字以内の制限。解答例は“迷惑メールの送信者がドメインを正当に取得した場合”（24字）。

採点講評（IPA）

設問3(2)は，正答率が低かった。“送信元のIPアドレスを詐称したパケットを送り込む”といった解答が目立った。しかし，SMTPはTCP上で動作しているので，事実上，IPアドレスを詐称することはできないことを理解してほしい。

本文の根拠

〔迷惑メール対策装置のユーザ登録ルールの見直し〕

③ c に登録する設定を URL BL にも登録することを提案し，効果があることを説明した。

表1

サーバ管理者の URL の登録によって URL フィルタリングを行うことができるプロキシブラックリスト（以下，ブラックリストを BL という）がある。

表3

5：URL BL，URL の並び，ヘッダ及びメール本文中に含まれる URL。

URL を登録して使うブラックリストを持つ機器は，図1・表1の中ではプロキシサーバだけである（プロキシブラックリスト）。c は“プロキシサーバ”。プロキシサーバの BL には，従業員に閲覧させたくない URL が管理者によって登録されている。同じ URL を迷惑メール対策装置の URL BL にも登録すると，ヘッダ及びメール本文中にその URL を含むメール（表3 項番 5）を，届く前に拒否できる。登録の効果は“迷惑メールの拒否率向上”である。

本文の最後で D 部長は“不審なメール中の URL をクリックしない”よう周知させている。これは URL BL が拒否しきれなかったメールへの備えで，URL の登録による拒否と，利用者側の注意は役割が違う。

効果は15字以内の制限。解答例の“迷惑メールの拒否率向上”は11字。c は機器名を図1中から選ぶので，“プロキシサーバ”と図1の表記どおり書く。

本文の根拠

表1

LB：HTTP，SMTP などのサービスの振分け機能及び IP アドレス変換機能がある。送信元 IP アドレスによって，振分け機能及び IP アドレス変換機能を使用しない設定もできる。

〔迷惑メールの増加への対策の検討〕

④図1のネットワーク構成と LB の設定を変更することで，インターネット上のメールサーバからの SMTP 通信を制御することにした。

〔迷惑メールの増加への対策の検討〕

さらに，表2のルール及び図3の設定を LB による制御に対応するように変更することにした。

設問2のとおり，迷惑メールは迷惑メール対策装置を通らず外部メールサーバに直接届いていた。対策は，インターネットから来る SMTP を，LB（SMTP などのサービスの振分け機能がある）で迷惑メール対策装置に振り分け，外部メールサーバへ直接届かないようにすることである。迷惑メール対策装置が正常に稼働している間は，インターネットからのメールは全て迷惑メール対策装置で検査されることになる。

本文は，この変更に合わせて，表2の FW のルールと図3の DNS の設定も LB による制御に対応するよう直すと述べている。外部メールサーバがインターネットから直接受けるのは，表1にあるとおり対策装置の故障に備えた機能なので，対策装置が正常な間はそこへ送らせない。

30字以内の制限。解答例は“SMTP通信を迷惑メール対策装置に振り分ける。”（23字）。“どのように制御すべきか”に対し，“振り分ける”という制御の動作と，振り分け先（迷惑メール対策装置）の二つを書く。

本文の根拠

〔マルウェア対策〕

利用者を①偽 Web サイトに誘導するものではないね。

〔マルウェア対策〕

マルウェア J に感染した PC で，正規の Web サイトにアクセスすると，マルウェア J が，認証情報を盗むために邪魔なメッセージを削除し，偽の乱数表情報入力画面を表示するものだね。

下線①の“偽 Web サイト”は，本物のサイトによく似せて作り，利用者に利用者 ID・パスワードなどを入力させて盗むための Web サイトで，その一般的な総称は“フィッシングサイト”である。G 部長は，マルウェア J の攻撃は，こうした偽サイトに誘導するものではなく，正規のサイトの画面に偽の入力画面を差し込むものだ，と整理している。

本文は，後の会話でも“偽 Web サイトに誘導して行われる中間者攻撃”に触れており，偽サイトへの誘導（フィッシング）と，マルウェア感染による画面の改ざんは別物として使い分けている。

10字以内の制限。解答例は“フィッシングサイト”（9字）。

本文の根拠

図1

＜法人利用者の利用手順＞は，URL 入力，クライアント証明書による TLS 接続，利用者 ID・パスワード入力，ログイン，送金情報入力，送金実行の順（乱数表の情報入力は無い）。

図1

注記 法人利用者の使用するクライアント証明書に対応する秘密鍵は，エクスポートできない状態で PC にインストールされる。

図1の法人利用者の手順では，利用者 ID・パスワードを入力する前に，クライアント証明書による TLS 接続が入る。クライアント証明書に対応する秘密鍵は，エクスポートできない状態で PC に入っているので，攻撃者は秘密鍵を持ち出せず，自分の PC から X ネットサービスに TLS 接続することができない。したがって，マルウェア J に利用者 ID・パスワードを盗まれても，攻撃者はクライアント証明書がないためログインできず，金銭的な被害が出る可能性は低い。

講評は，この設問の正答率は高かったが，乱数表を使用していないことに言及した解答も多く，設問の趣旨を捉えていないものがあった，と述べている。設問は“法人利用者の利用手順に着目し”と指定しているので，個人利用者にある乱数表の有無ではなく，法人利用者の手順にあるクライアント証明書を書く。

35字以内の制限。解答例は“攻撃者はクライアント証明書がなく，ログインできないから”（27字）。

採点講評（IPA）

設問1(2)は，正答率が高かった。法人利用者がクライアント証明書による端末認証を実施していることから，利用者IDとパスワードだけでは，Xネットサービスを利用できないことが，正しく理解されているようであった。しかし，乱数表を使用していないことに言及する解答も多く，設問の趣旨を捉えていない受験者も散見された。落ち着いて問題文を読んで解答してほしい。

本文の根拠

〔新たなマルウェア対策の検討〕

例えば，利用者が使用している DNS サーバを攻撃することで，x-bank.jp へのアクセスを偽 Web サイトに誘導して行われる中間者攻撃であれば，③最新のブラウザを使っている利用者は攻撃に気付くことができる。

〔マルウェア対策〕

HTTP over TLS 用に EV SSL 証明書（以下，サーバ証明書という）を使用している。

偽サイトに誘導する中間者攻撃では，攻撃者は x-bank.jp 用の正規のサーバ証明書（とその秘密鍵）を持っていないので，別の証明書を提示するしかない。TLS では，ブラウザが，接続しようとしているドメイン名と，サーバが示した証明書の内容が一致するかを確かめる（RFC 6125）。一致しない，又は信頼できない証明書だと，最新のブラウザは接続を止め，警告画面を表示する。利用者はこの警告画面を見て攻撃に気付くことができる。

一方，マルウェア K は通信経路に介在せず，ブラウザの動作そのものに介入する（Man-in-the-Browser）。正規のサーバと正規の証明書で通信するので警告は出ず，利用者は気付けない。この違いが，G 部長の“中間者攻撃であれば気付く”と“マルウェア K では気付けない”の対比の中身である。

35字以内の制限。解答例は“利用者のブラウザに表示される警告画面を見て気付くことができる。”（31字）。“どのようにして”に答えるので，“警告画面”という手掛かりを書く。

本文の根拠

図3

送金内容入力画面（URL は https://x-bank.jp/xnet?page=45。“送金先口座番号，送金額を入力してください。”とあり，口座番号 123456，送金額 10000 円が入力され

図3

ブラウザの動作に介入し，攻撃者が意図した送金内容に書き換える。・書き換え後の送金内容 口座番号：999999 送金額：500000

図3

ブラウザの動作に介入し，送金内容確認画面を書き換える。

利用者が送金内容入力画面で入れたのは，口座番号 123456・送金額 10000 円。マルウェア K は，ブラウザの動作に介入して，サーバへ送る内容を口座番号 999999・送金額 500000 に書き換える。その結果，サーバから来る確認画面は書き換え後の内容（999999，500000）になるはずだが，K は確認画面も書き換えて，利用者が最初に入力した内容を表示する。したがって a は 123456，b は 10000 である。

確認画面は，利用者が送金内容を最後に目で確かめる機会である。ここが書き換わっていないと，利用者は口座番号と金額の違いに気付き，送金実行を押さない。確認画面を書き換える目的は，書き換えた事実を利用者に気付かせず，送金を実行させることにある。

目的は35字以内の制限。解答例は“マルウェアKが書き換えた口座番号と送金額を利用者に隠すこと”（29字）。a・b は，図3の入力内容と同じ数字を書く。書き換え後の 999999・500000 と取り違えやすい。

本文の根拠

図2

マルウェア J は，X ネットサービスのログイン画面に通常表示される注意事項などのメッセージを削除する。さらに，入力された利用者 ID，パスワードを攻撃者に送信する。

表1

ワンタイムパスワード認証：認証のたびに，要求するパスワードが変わる方式。入力すべきパスワードは，専用デバイスに表示される。

表1

利用者とネットバンキングの Web サイト間で，利用者ごとの鍵（以下，共通鍵という）を設定した HMAC 計算ツールをあらかじめ共有しておく。

表2

注記 利用者は，マルウェア J，マルウェア K の感染に気付くことができないことを前提とする。

c（ワンタイムパスワード認証・マルウェア J）は“対策になる”。マルウェア J は，利用者が入力した認証情報（利用者 ID，パスワード，乱数表の情報）を攻撃者へ送る。乱数表の情報は同じ表を繰り返し使うので，盗まれると攻撃者が別の機会にそのまま使えるが（項番 3 は“対策にならない”），ワンタイムパスワードは認証のたびに変わり，入力すべき値は専用デバイスに表示されるため，盗まれた値を後から使うことはできない。

d（送金内容認証・マルウェア J）も“対策になる”。送金のとき Web サイトに送る HMAC 値は，利用者と Web サイトが共有する共通鍵を設定した HMAC 計算ツールで作る（RFC 2104 の HMAC は，共有した秘密鍵を使ってメッセージの完全性を確かめる仕組み）。マルウェア J が盗めるのは利用者 ID・パスワードなどの認証情報で，共通鍵を持たない攻撃者は，送金内容に合った正しい HMAC 値を作れないので，Web サイトの検証で止まる。

この設問は“対策になる”又は“対策にならない”を選ぶ。間違えやすいのは，表2の注記が“利用者は感染に気付けないことを前提とする”と置いている点で，利用者の注意で防げるかではなく，認証の仕組みとして効くかで評価する。同じ表の，マルウェア K 向けの評価（c は“対策にならない”，d は“対策になる”）と取り違えない。

本文の根拠

表2

1：利用者 ID・パスワード認証，対策にならない，対策にならない。

表2

4：ワンタイムパスワード認証，c，対策にならない。

〔セキュリティ対策の再検討〕

また，項番 1 と項番 4 の認証を組み合わせた e 認証といわれる認証方式の評価も行ったが，マルウェア K に感染した PC の不正送金対策にはならなかった。

項番 1 の利用者 ID・パスワード認証は“利用者が知っていること”による認証，項番 4 のワンタイムパスワード認証は，専用デバイスに表示される値を使う“利用者が持っているもの”による認証である。種類の異なる二つの要素を組み合わせた認証を“二要素認証”という。

本文は，この二要素認証でも，マルウェア K に感染した PC の不正送金対策にはならなかったと述べる。表2の項番 1・4 がどちらもマルウェア K に“対策にならない”のは，K が認証を破るのではなく，認証が済んだ後の送金内容を書き換えるからである。

5字以内の制限。解答例の“二要素”は3字で，“二要素認証”と書くと6字になり制限を超える（空欄の後ろに“認証”が付いているので書かない）。

本文の根拠

表1

利用者がネットバンキングで送金するときは，HMAC 計算ツールに送金先口座番号及び送金額を送金内容として入力し，HMAC 計算ツールで計算した結果（以下，HMAC 値という）も Web サイトに送信する。

図3

ブラウザの動作に介入し，攻撃者が意図した送金内容に書き換える。

〔新たなマルウェア対策の検討〕

この攻撃は Man-in-the-Browser と呼ばれている攻撃手法だから，利用者は気付くことができないよ。

送金内容認証では，利用者が HMAC 計算ツールに送金先口座番号と送金額を入力し，そのツールが計算した HMAC 値を，送金内容とともに Web サイトへ送る。Web サイトは，送られた送金内容から自分で HMAC 値を計算し，一致するかを確かめる。ツールが PC 上のプログラムだと，マルウェアに感染した PC では，ツールへの入力内容も改ざんできる。入力内容を攻撃者の口座・金額に書き換えると，ツールはその改ざん後の内容に対する正しい HMAC 値を計算するので，Web サイト側の検証は通り，不正送金を防げない。専用デバイスなら，デバイスには利用者が直接入力し，結果も目で見て Web サイトへ入力するので，PC 上のマルウェアは入力内容に手を出せない。

講評は，“入力値の改ざん”ではなく“HMAC 値の改ざん”と誤って答えた受験者が多かった，と述べている。HMAC 値は共通鍵がなければ作れないので，攻撃されるのは HMAC 値の計算に渡す入力のほうである。

55字以内の制限。解答例は“利用者のPCがマルウェアに感染した場合，HMAC計算ツールの入力内容も改ざんされる可能性がある。”（48字）。“感染した場合”という条件と，“入力内容も改ざん”の二つを書く。

採点講評（IPA）

設問3(3)は，正答率が低かった。特に“入力値の改ざん”ではなく，“HMAC値の改ざん”と誤って解答している受験者が多く，送金内容認証及びHMACの仕組みについて正しく理解されていないようであった。マルウェアの攻撃手法について正しく理解してほしい。