応用情報技術者 2011年 秋期 午後 問09
Webアプリケーションのセキュリティ対策に関する次の記述を読んで、設問1~4に答えよ。
W社は、インターネット上で日用雑貨品の会員制通信販売システムを運営する会社である。この通信販売システム(以下、本システムという)は、商品検索、注文、会員管理、会員掲示板などの機能を提供する。
本システムの機能を利用するには、あらかじめ会員管理機能を使って、会員登録しなければならない。
図1は、会員掲示板機能を使った会員掲示板画面の例である。

ある日、会員情報が知らぬ間に書き換わっていたり、覚えの無い商品が届いたりしたとのクレームが複数の会員から寄せられた。情報システム部門で本システムを調べたところ、クレームに該当する登録情報の変更処理や商品の注文処理が確認された。
情報システム部門の責任者であるA部長は、セキュリティ事故が発生したと判断して、本システムの利用を直ちに停止し、外部のセキュリティ専門会社の支援を受けながら対策をとることを指示した。
後日、外部のセキュリティ専門会社から、今回のセキュリティ事故に関する調査報告書が届けられた。調査報告書に記載された内容は、次のとおりである。
〔セキュリティ事故の経過〕
(1) 会員Xは、本システムのトップ画面から、会員ログインページへのボタンを押した。
(2) 本システムは、ログイン画面を表示した。
(3) 会員Xは、ログイン画面で、自身のアカウント名とパスワードを入力した。
(4) 本システムは、アカウント名とパスワードを確認して、セッションIDを発行し、cookieを利用して会員のブラウザに戻した。
(5) 会員Xは、会員メニュー画面で、会員掲示板機能を選択した。
(6) 本システムは、会員掲示板画面を表示した。
(7) 会員Xが、特定の会員掲示板ページを参照したときに、悪意のあるコードが自動的に実行され、会員Xの登録情報を書き換える処理と、注文処理が行われた。
〔想定される原因〕
(1) 会員掲示板ページを出力する処理に問題があり、この問題を悪用したメソッドの代わりにbメソッドでアクセスすると、秘密情報を URL に付加して送信することになるので、ここでは利用を避けるべきである。また、HTML フォームで<form>タグを用いる場合、メソッド属性の指定を省略するとbメソッドと解釈されるので、適切に指定する必要がある。
今回のように、ログインした会員だけが、予期しない処理を実行させられてしまうセキュリティ攻撃は、クロスサイトリクエストフォージェリ―と呼ばれている。
この攻撃が成功する主たる要因は、会員の正しい要求と悪意のあるコードの要求を区別できないことである。
この後、A 部長は、外部のセキュリティ専門会社の提言に従い、今回のセキュリティ攻撃の根本的な原因を解消すべく、本システムの改善を行うことにした。
提言された対策(1)を本システムの全てのプログラムに適用し、その上で重要な処理を行う注文機能と会員管理機能に対して、提言された対策(2)を適用した。会員登録時における本システムと会員のブラウザとの間の情報の流れは、図2のとおりである。

設問1:
本文中のa、bに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:GET
イ:HEAD
ウ:OPTION
エ:POST
オ:PUT
カ:RESET
模範解答
a:エ
b:ア
解説
解答の論理構成
-
重要処理ページに求められる性質の確認
問題文には
“特に、会員情報の登録処理や注文処理のような重要な処理を実行するページにはaメソッドでアクセスするように”
とあります。更新系処理では、パラメータをリクエストボディに含めて URL に残さない方法が推奨されます。 -
URL に付加されるメソッドの特定
続けて
“もしaメソッドの代わりにbメソッドでアクセスすると、秘密情報を URL に付加して送信することになる”
と説明されています。HTTP でパラメータが URL(クエリ文字列)に含まれる代表的なメソッドは “GET” です。 -
既定値となるメソッドの確認
さらに
“HTML フォームで -
消去法による確定
解答群で、URL 末尾にパラメータが付くメソッドは “ア:GET”。
重要処理に用いるメソッドとして一般的に推奨され、URL にパラメータが出ないメソッドは “エ:POST”。 -
結論
よって
a=“エ:POST”
b=“ア:GET”
誤りやすいポイント
- 「PUT も更新系だから安全だろう」と誤選択する
⇒ 問題文は明示的に “URL に付加” という挙動をキーにしており、PUT の説明には該当しません。 - デフォルトメソッドを「POST」と勘違いする
⇒ の既定は GET です。HTML の仕様知識が必須です。 - CSRF=GET だけが危険と思い込み、POST を使えば自動的に安全と考える
⇒ POST でもトークン検証がなければ CSRF を完全には防げません。
FAQ
Q: GET でもクエリ文字列を暗号化すれば良いのでは?
A: HTTPS を用いても URL 自体はブラウザ履歴やログに残る恐れがあるため、不適切です。
A: HTTPS を用いても URL 自体はブラウザ履歴やログに残る恐れがあるため、不適切です。
Q: POST にすれば CSRF は起きない?
A: “今回のように、ログインした会員だけが、予期しない処理を実行させられてしまうセキュリティ攻撃は、クロスサイトリクエストフォージェリ―” とあるとおり、POST でもトークン検証が必須です。
A: “今回のように、ログインした会員だけが、予期しない処理を実行させられてしまうセキュリティ攻撃は、クロスサイトリクエストフォージェリ―” とあるとおり、POST でもトークン検証が必須です。
Q: hidden パラメータのページトークンは毎回変えるべき?
A: はい。毎リクエストで一意にし、サーバ側で整合性を確認することでリプレイ攻撃を防ぎます。
A: はい。毎リクエストで一意にし、サーバ側で整合性を確認することでリプレイ攻撃を防ぎます。
関連キーワード: HTTPメソッド、GET, POST, CSRF, ページトークン
設問2:
〔対策の提言〕(1)について、今回の場合、<script>タグを用いたコードにエスケープ処理を適切に施す目的は何か。20字以内で述べよ。
模範解答
「scriptタグを無効にする。」
または
「悪意のあるコードを実行させない。」
解説
解答の論理構成
- 調査報告書は、会員掲示板ページに「
- 悪意のあるコードが実行されると、登録情報の改ざんや不正注文が発生することも明記されています。
引用︓「そのコードが自動的に実行され、会員の登録情報を書き換える処理や特定の商品の注文処理が行われるようになっていた。」 - これを防ぐため、提言(1)では HTML 特殊文字を他の文字列に置き換える「エスケープ処理」を行うよう求めています。
引用︓「入力された文字列は、そのままではなく、エスケープ処理を適切に施してからブラウザに表示する。」 - 具体例として、< や > を「<」「>」に置き換えることで、「<script>」が文字列のまま表示され、ブラウザはタグとして解釈しなくなります。
引用︓「これによって、タグの文字列“<script>”は、文字列“<script>”に置き換わる。」 - 以上より、エスケープ処理の目的は「<script>タグをブラウザで実行させず、単なる文字列として扱わせる」こと、すなわち「悪意のあるコードを無効化する」ことになります。
誤りやすいポイント
- CSRF と XSS を混同し、「ページトークンにより防ぐ」と答えてしまう。
- 「HTMLタグを削除する」と誤解し、置き換え(エスケープ)である点を見落とす。
- 単に「特殊文字を変換する」と書き、タグを無効化する狙いまで言及しない。
- 「< と > を文字参照に変換する例」を答えと勘違いし、本来の目的を示さない。
FAQ
Q: エスケープ処理とサニタイズ処理の違いは何ですか?
A: エスケープ処理は「表示時にタグとして解釈させない」ために文字を置き換えること、サニタイズ処理は「入力値から不要・危険な文字列を除去・変換する」ことを指し、目的やタイミングが異なります。
A: エスケープ処理は「表示時にタグとして解釈させない」ために文字を置き換えること、サニタイズ処理は「入力値から不要・危険な文字列を除去・変換する」ことを指し、目的やタイミングが異なります。
Q: JavaScript のみを対象にすれば十分ですか?
A: いいえ。HTML コメント、CSS、イベントハンドラ属性などでもコードが実行される場合があるため、汎用的に「<」「>」「&」など全ての特殊文字をエスケープする必要があります。
A: いいえ。HTML コメント、CSS、イベントハンドラ属性などでもコードが実行される場合があるため、汎用的に「<」「>」「&」など全ての特殊文字をエスケープする必要があります。
Q: WAF(Web Application Firewall)で同様の攻撃は防げますか?
A: WAF は一定の防御効果がありますが、完全ではありません。アプリケーション側で正しいエスケープ処理を実装することが根本対策です。
A: WAF は一定の防御効果がありますが、完全ではありません。アプリケーション側で正しいエスケープ処理を実装することが根本対策です。
関連キーワード: クロスサイトスクリプティング、エスケープ処理、HTML特殊文字、文字参照、サニタイズ
設問3:
図2において、秘密情報(ページトークン)を送受信する適切な箇所の組合せを解答群の中から選び、記号で答えよ。
解答群
ア:①、②、③
イ:②、③、④
ウ:③、④
エ:④、⑤
オ:⑤
カ:⑤、⑥
模範解答
エ
解説
解答の論理構成
-
対策(2)の要点
- 【問題文】には「特に、会員情報の登録処理や注文処理のような重要な処理を実行するページにはaメソッドでアクセスするようにし、その hidden パラメタに秘密情報(ページトークン)が挿入されるように、前のページを自動生成する。実行ページでは、その値が正しい場合だけ処理を行う。」とあります。
- つまり「前のページ」でトークンを HTML に埋め込み、「実行ページ」で受信して照合する、という 2 点が必須です。
-
図2の流れと“重要な処理”
- 図2では「⑤───→ 実行 ────→│」がデータベースへ登録更新を行う“重要な処理”に相当します。
- したがって、トークンが埋め込まれる「前のページ」は「④ 確認画面」、トークンを受信して検証する「実行ページ」は「⑤ 実行」に該当します。
-
解答選択
- 秘密情報を送る(HTML に埋め込む)④と、受信して照合する⑤の 2 箇所が含まれる選択肢は【解答群】「エ:④、⑤」のみです。
- よって正解は「エ」となります。
誤りやすいポイント
- 「③ 登録情報」も入力フォームなのでトークンを入れたくなる
→ 対策(2)は“重要な処理を呼び出す直前のページ”と“実行ページ”の組で機能します。 - トークンは 1 回限りと覚えておらず、「⑥ 完了画面」にも載せると考えてしまう
→ 完了画面は結果表示のみであり、サーバ側更新は行われないため不要です。 - POST/GET だけに意識が向き「hidden パラメタ」のタイミングを見落とす
→ 対策(2)では POST(a)を使うだけでなく hidden フィールドの生成・検証も必須です。
FAQ
Q: トークンはセッション ID と何が違うのですか?
A: セッション ID はログイン状態を示す汎用識別子、ページトークンは特定のフォーム送信と 1 対 1 に対応させた“使い捨て”識別子です。CSRF では“正規セッション”を悪用されるため、追加のワンタイム値が必要になります。
A: セッション ID はログイン状態を示す汎用識別子、ページトークンは特定のフォーム送信と 1 対 1 に対応させた“使い捨て”識別子です。CSRF では“正規セッション”を悪用されるため、追加のワンタイム値が必要になります。
Q: 「② 会員管理画面」でもトークンを入れてはいけませんか?
A: 必ずしも禁止ではありませんが、更新系処理を行わない一覧表示ページなので必須ではありません。実務ではページ単位でリスク評価し、必要に応じて埋め込みます。
A: 必ずしも禁止ではありませんが、更新系処理を行わない一覧表示ページなので必須ではありません。実務ではページ単位でリスク評価し、必要に応じて埋め込みます。
Q: トークンを cookie に入れても同じ効果がありますか?
A: cookie に格納すると攻撃者が同じ cookie を送るだけで通過できるため CSRF 防御にはなりません。リクエスト毎にフォームの hidden フィールドへ埋め込み、Referer などと組み合わせて検証する方法が推奨されます。
A: cookie に格納すると攻撃者が同じ cookie を送るだけで通過できるため CSRF 防御にはなりません。リクエスト毎にフォームの hidden フィールドへ埋め込み、Referer などと組み合わせて検証する方法が推奨されます。
関連キーワード: クロスサイトリクエストフォージェリ、ページトークン、POSTメソッド、hiddenパラメタ、エスケープ処理
設問4:
今回のセキュリティ攻撃を防ぐ対策として〔対策の提言〕(1)、(2)を実施した上で、この攻撃を検出する対策をとることにした。この攻撃を検出するために有効な対策として適切なものを解答群の中から選び、記号で答えよ。
解答群
ア:悪意のあるコードを埋め込まれた特定の会員掲示板ページを直ちに削除する。
イ:会員情報の登録や変更、注文処理などの重要な処理を行うページでは、HTTPSによって、途中経路を暗号化する。
ウ:会員情報の登録や変更、注文処理などの重要な処理については、必ずログを記録する。
エ:本システムで利用するセッションIDとして会員ごとに一意の固定値を割りて、常にそれを利用する。
模範解答
ウ
解説
解答の論理構成
-
問題の前提
【問題文】では、予防策として「〔対策の提言〕(1)、(2)」を既に実装したと明記されています。したがって設問は「この攻撃を検出する対策」を追加で求めています。 -
検出の必要条件
攻撃を検出するには、“いつ・誰が・どのようなリクエストを送ったか” を後から確認できる仕組みが不可欠です。 -
解答群の分析
- ア:「特定の会員掲示板ページを直ちに削除」
→ 予防措置であり検出を目的としません。 - イ:「HTTPSによって、途中経路を暗号化」
→ 通信経路を保護する予防策です。 - ウ:「必ずログを記録する」
→ 実際に行われた「登録情報を書き換える処理や特定の商品の注文処理」を後から確認でき、攻撃の“検出”に直結します。 - エ:「会員ごとに一意の固定値のセッションIDを常に利用」
→ セッション固定化の危険を高め、検出・予防のどちらにも適しません。
- ア:「特定の会員掲示板ページを直ちに削除」
-
結論
検出機構を構築できるのは「ウ:会員情報の登録や変更、注文処理などの重要な処理については、必ずログを記録する。」です。よって解答は ウ となります。
誤りやすいポイント
- 「HTTPSを使えば安全=検出も可能」と思い込み「イ」を選ぶ。暗号化は盗聴防止であり、攻撃が発生したかどうかを後から判定できません。
- 「ページを削除すれば痕跡が残せる」と考え「ア」を選ぶ。削除は証拠保全や検出の前に行うと、かえって原因分析を困難にします。
- 「固定セッションID=追跡しやすい」と勘違いし「エ」を選ぶ。固定化はセキュリティ低下を招き、検出にも寄与しません。
FAQ
Q: ログにはどの程度の情報を残せば検出に役立ちますか?
A: 「アカウント名」「タイムスタンプ」「アクセス元IP」「リクエスト内容(パラメタ)」を最低限残すことで、異常なパターンや不自然な連続操作を追跡しやすくなります。
A: 「アカウント名」「タイムスタンプ」「アクセス元IP」「リクエスト内容(パラメタ)」を最低限残すことで、異常なパターンや不自然な連続操作を追跡しやすくなります。
Q: ログを残すだけで十分ですか?
A: いいえ。集中管理・改ざん防止・リアルタイム監視を組み合わせて初めて“検出”が機能します。
A: いいえ。集中管理・改ざん防止・リアルタイム監視を組み合わせて初めて“検出”が機能します。
Q: 保存期間はどのくらいが望ましいですか?
A: 事故発覚が遅れるケースを想定し、業界ガイドラインや社内ポリシーに従って複数ヶ月~数年保持するのが一般的です。
A: 事故発覚が遅れるケースを想定し、業界ガイドラインや社内ポリシーに従って複数ヶ月~数年保持するのが一般的です。
関連キーワード: ログ管理、監査証跡、攻撃検出、CSRF, セキュリティモニタリング


