正解：ア
各選択肢の解説
ア変更画面のフォームに推測できない秘密の値を埋め込み、受けた要求の値と照合する。
正解。罠サイトは、会員サイトが画面ごとに発行する秘密の値を知り得ません。値が一致しない 要求を処理しなければ、本人の画面操作から来た要求だけを受け付けられます。 クロスサイトリクエストフォージェリ（CSRF）の根本的な対策です。
イ画面に出力する文字列のうち、HTMLとして特別な意味を持つ記号をエスケープする。
誤り。出力時のエスケープは、クロスサイトスクリプティングの根本的な対策です。 どちらも利用者のブラウザが使われるので混同しやすいですが、この場面では会員サイトの 画面にスクリプトは埋め込まれていません。要求が外から届いた点に原因があります。
ウ自社サイトのページを、他のサイトの枠（フレーム）の中に表示させない設定にする。
誤り。これはクリックジャッキングへの対策です。透明にした自社のページを罠サイトに重ね、 利用者にクリックさせる手口を防ぎます。この場面の会員は何もクリックしておらず、 要求は自動で送られています。利用者の操作を誘うかどうかで区別します。
エログインに成功した時点で、それまでのセッションIDを破棄して新しく発行し直す。
誤り。これは攻撃者が用意したセッションIDを使わせる、セッション固定攻撃への対策です。 この場面ではセッションIDは奪われておらず、会員本人の正規のセッションのまま 要求が送られています。セッションが盗まれたのか、正規のセッションが利用されたのかで切ります。
理解を深めるために
本人の名前で届いた、本人の知らない依頼
会社の受付が「社員証を見せた人の依頼なら何でも受ける」というルールだったとします。 誰かが社員に封筒を渡し、中身を知らせないまま受付へ持っていかせれば、 その依頼は社員本人のものとして処理されてしまいます。会員サイトが 「ログイン中のブラウザから来た要求なら本人の操作」と見なしていると、同じことが起きます。 これが**クロスサイトリクエストフォージェリ（CSRF）**です。
なぜ秘密の値の照合が根本的な対策なのか
IPAの「安全なウェブサイトの作り方」は、CSRFの原因を、ログインの仕組みを持つサイトが 「その要求が利用者の意図したものか」を確かめていないことに置いています。
- ブラウザの既定やCookieのSameSite属性の設定によっては、罠サイトから送られた要求にも 会員サイトのCookie（セッションID）が付く（ブラウザ側の既定に頼らず、サイト側で確かめる必要がある）
- Cookieが付いた要求は、会員サイトから見ると正規のセッションで届く
- 変更画面に推測できない秘密の値を埋め込み、処理の前に照合すれば、自社の画面を 経由した要求かどうかを確かめられる
IPAは根本的解決として、ほかに「処理の直前にパスワードを再入力させる」ことなども挙げています。
混同しやすいものとの違い
| 攻撃 | 何が起きるか | 代表的な対策 |
|---|---|---|
| CSRF | 正規のセッションで意図しない処理が送られる | 秘密の値の照合、パスワード再入力 |
| クロスサイトスクリプティング | サイトの画面にスクリプトが埋め込まれ、閲覧者のブラウザで動く | 出力時のエスケープ |
| クリックジャッキング | 透明なページを重ねて利用者にクリックさせる | 他サイトの枠内での表示を禁止 |
| セッション固定攻撃 | 攻撃者が用意したセッションIDを使わせ、後から乗っ取る | ログイン時のセッションIDの再発行 |
場面を読むときは、要求がどこから来たか、利用者がクリックしたか、 セッションIDが奪われたかの3点を確かめると、攻撃と対策が対応づけられます。