午前I問題
Webアプリケーションにおける CSRF(Cross-Site Request Forgery)攻撃に関する記述のうち、最も適切なものはどれか。
ア)CSRF攻撃は、攻撃者が被害者のブラウザに悪意のあるスクリプトを注入し、被害者のブラウザ上で任意のJavaScriptを実行させる攻撃である イ)CSRF攻撃は、被害者が認証済みのセッションを持つサイトに対して、被害者の意図しないリクエストを別サイト経由で送信させる攻撃であり、対策としてトークンによる検証が有効である ウ)CSRF攻撃はHTTPSを利用することで完全に防止できる エ)CSRF攻撃はサーバー側の入力値検証不備によりSQL文が不正に実行される攻撃である
午前I の解答・解説を見る
正解: イ
解説:
- ア)不正解。これはXSS(クロスサイトスクリプティング)の説明である。CSRFとXSSは混同されやすいが別の脆弱性であり、CSRFはスクリプト注入ではなく「意図しないリクエストの送信」が本質。
- イ)正解。CSRFは被害者が認証済み(ログイン済み)のセッションを悪用し、攻撃者が用意した罠サイトやメールのリンクを通じて、被害者が意図しないリクエスト(送金、パスワード変更等)を送信させる攻撃。CSRFトークンによる検証が代表的な対策。
- ウ)不正解。HTTPSは通信経路の暗号化・改ざん防止には有効だが、認証済みセッションを悪用したリクエスト偽造自体は防げない。CSRF対策には別途トークン検証やSameSite Cookie属性の設定が必要。
- エ)不正解。これはSQLインジェクションの説明である。CSRFとは全く異なる脆弱性カテゴリ。
午前II問題
OpenID Connect(OIDC)の認可コードフローにおけるstateパラメータとnonceパラメータに関する記述のうち、適切なものはどれか。
ア)stateパラメータはCSRF対策として認可リクエスト時にRP(Relying Party)が生成しIdPに送信、コールバック時に値が一致するか検証するものであり、nonceパラメータはIDトークンのリプレイ攻撃対策としてIDトークン内に埋め込まれ検証されるものである イ)stateパラメータとnonceパラメータは同一の目的(CSRF対策)を持つため、どちらか一方のみを実装すればよい ウ)nonceパラメータの検証を省略しても、認可コードフローではIDトークンの署名検証だけで十分安全である エ)stateパラメータはアクセストークンに埋め込まれ、認可サーバーがアクセストークンの正当性を検証する際に使用される
午前II の解答・解説を見る
正解: ア
解説:
- ア)正解。stateパラメータはRPが認可リクエスト時にランダム値を生成しセッションに保存、コールバック時にIdPから返却された値と照合することでCSRF攻撃(攻撃者が用意した認可コードを被害者のセッションに紐付けさせる攻撃)を防ぐ。nonceパラメータはIDトークン内に埋め込まれ、RPが検証することでIDトークンのリプレイ攻撃を防ぐ。両者は目的が異なる別々のパラメータ。
- イ)不正解。stateはCSRF対策、nonceはIDトークンのリプレイ対策であり、目的が異なるため両方の実装が必要。片方のみでは対応する攻撃を防げない。
- ウ)不正解。署名検証はIDトークンの改ざん検知には有効だが、正規に発行された古いIDトークンの使い回し(リプレイ)は防げない。nonce検証を省略すると、盗聴・ログ等から入手した古いIDトークンを再利用される攻撃を許してしまう。
- エ)不正解。stateパラメータはアクセストークンではなく、認可リクエストとコールバックの間でRP側のセッションに紐づけて検証されるものであり、アクセストークンの検証には使用されない。
午後問題
旅行予約サイトF社は、自社サービスへのログインにOpenID Connect(Authorization Code Flow)を用いた「Googleでログイン」機能を実装した。開発チームが実装したコールバック処理は以下の通りであった。
1. RP(F社サイト)がGoogleへ認可リクエストを送信(redirect_uri, client_id, scope=openid emailを指定)
2. 利用者がGoogleでログイン・同意
3. GoogleがF社のredirect_uriへ認可コードを含めてリダイレクト
4. F社サーバーが認可コードをGoogleのトークンエンドポイントに送信し、IDトークン・アクセストークンを取得
5. IDトークンのペイロードからemailクレームを取り出し、そのメールアドレスでログインセッションを開始
セキュリティ診断の結果、以下の指摘を受けた。
- 指摘1:認可リクエストにstateパラメータが含まれておらず、コールバック時の検証も実装されていない
- 指摘2:IDトークンのnonceクレームの検証が実装されていない
- 指摘3:IDトークンの署名検証・発行者(iss)検証・有効期限(exp)検証は正しく実装されている
設問1
指摘1(stateパラメータ未実装)が放置された場合、どのような攻撃が成立するか、攻撃シナリオを具体的に説明しなさい。また、対策を述べなさい。(200字程度)
設問1の解答・解説を見る
正解例: 攻撃者は自身のGoogleアカウントで認可リクエストを開始し、取得した自分名義の認可コードを含むコールバックURLを被害者に踏ませる(ログインCSRF)。stateの検証がないため、F社サーバーはこの認可コードを正規のフローとして処理し、被害者のブラウザセッションに攻撃者のアカウントで紐づけたログイン状態を作り出す。これにより被害者が入力した予約情報や決済情報が攻撃者のアカウントに記録され、情報窃取や誤った取引に利用される可能性がある。対策は、認可リクエスト時にランダムなstateを生成しセッションに保存、コールバック時に一致を検証することである。
解説・採点基準(計15点):
| 採点項目 | キーワード | 配点 |
|---|---|---|
| ログインCSRFの攻撃シナリオ説明 | 攻撃者自身の認可コード・被害者への強制ログイン・アカウント混同 | 8点 |
| 被害の具体化 | 予約/決済情報の誤紐付け・情報窃取 | 3点 |
| 対策(state生成・照合)の説明 | ランダムstate生成・セッション保存・コールバック照合 | 4点 |
部分点: 攻撃シナリオの説明が不完全(「なりすまし」とのみ記載等)→4点。
設問2
指摘2(nonce検証未実装)が放置された場合、指摘3(署名検証等が正しく実装済み)であってもなお残るリスクを説明しなさい。また、nonceパラメータをどのように実装・検証すべきか述べなさい。(150字程度)
設問2の解答・解説を見る
正解例: 署名・発行者・有効期限の検証だけでは、有効期限内に正規発行されたIDトークンが盗聴やログ流出などにより第三者に取得された場合、そのIDトークンをそのまま再送信するリプレイ攻撃を防げない。対策として、認可リクエスト時にRPがランダムなnonce値を生成してセッションに保存し送信、コールバックで受け取ったIDトークンのnonceクレームがセッションに保存した値と一致するか検証することで、同一のIDトークンの再利用を検知・拒否する。
解説・採点基準(計15点):
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 残存リスク(リプレイ攻撃)の説明 | 有効期限内トークンの再送・盗聴/ログ流出 | 6点 |
| nonce実装方法の説明 | ランダム値生成・セッション保存・送信 | 4点 |
| nonce検証方法の説明 | クレームとセッション値の一致確認 | 5点 |
部分点: 「リプレイ攻撃」という語のみで具体的説明がない場合→3点。
重要キーワード
| 用語 | 説明 |
|---|---|
| OpenID Connect(OIDC) | OAuth 2.0を拡張し、認可に加えて認証(Identity層)を提供するプロトコル。IDトークン(JWT)により利用者の認証結果を伝達する |
| stateパラメータ | 認可リクエスト時にRPが生成しIdPを経由してコールバックに返却させる値。コールバック時に照合することでログインCSRF攻撃を防ぐ |
| nonceパラメータ | 認可リクエスト時にRPが生成しIDトークンに埋め込ませる値。IDトークン検証時に照合することでIDトークンのリプレイ攻撃を防ぐ |
| ログインCSRF | 攻撃者が自分自身の認証結果(認可コード等)を被害者のセッションに注入し、被害者を攻撃者のアカウントでログインさせる攻撃。state未検証時に成立する |
| JWT(JSON Web Token) | IDトークンやアクセストークンの表現形式として広く使われる、署名付きの自己完結型トークン。ヘッダー・ペイロード・署名で構成される |
| 認可コードフロー(Authorization Code Flow) | OIDC/OAuth2.0の主要なフロー。認可コードを一旦発行しトークンエンドポイントでIDトークン・アクセストークンに交換する、フロントチャネルへのトークン露出を避ける設計 |
まとめ
- 午前I視点: CSRFはXSSやSQLインジェクションと混同されやすい。「認証済みセッションの悪用による意図しないリクエスト送信」という本質を押さえる。
- 午前II視点: stateはCSRF対策、nonceはリプレイ対策と目的が異なる。両者を混同させる選択肢が頻出するため、対応する攻撃と対策をペアで暗記する。
- 午後視点: 「署名検証をしているから安全」という思い込みへの反証(リプレイ攻撃はnonceでしか防げない)や、ログインCSRFの具体的な攻撃シナリオを記述できることが採点ポイント。