午前I問題

モバイルアプリケーションにおけるURLスキーム（カスタムスキーム、例：myapp://callback）を用いたリダイレクト処理に関する記述のうち、適切なものはどれか。

ア）カスタムURLスキームは、OSによって単一のアプリケーションのみが登録できることが保証されているため、悪意あるアプリによる横取りは発生し得ない　イ）カスタムURLスキームは複数のアプリが同一のスキームを登録できるプラットフォームがあり、悪意あるアプリが同じスキームを登録することでリダイレクトを横取りされる可能性がある　ウ）カスタムURLスキームを用いたリダイレクトは常にHTTPS通信と同等の暗号化が施されるため、通信内容の盗聴リスクはない　エ）Androidの App Links やiOSの Universal Links は、カスタムURLスキームよりもセキュリティ上劣るため、OAuth2のリダイレクトには非推奨とされている

午前I の解答・解説を見る

正解： イ

解説：

  • ア）不正解。カスタムURLスキーム（myapp://のような形式）は、OSやバージョンによっては複数のアプリケーションが同一のスキームを登録できてしまう場合があり、単一アプリへの登録保証はプラットフォームやバージョンに依存します。
  • イ）正解。特にAndroidの一部バージョンでは、悪意あるアプリが正規アプリと同じカスタムURLスキームを登録し、OSがリダイレクト先を一意に決定できない場合に、悪意あるアプリへリダイレクトが渡ってしまうリスクがあります。これが認可コード横取り攻撃の入口の一つです。
  • ウ）不正解。カスタムURLスキームによるリダイレクト自体はOSのIntent機構やURLハンドリングの仕組みであり、通信路の暗号化を保証するものではありません。暗号化の有無は別途HTTPS通信の設計に依存します。
  • エ）不正解。Android App LinksやiOS Universal Linksは、ドメイン所有権の検証（assetlinks.jsonやapple-app-site-associationファイルの配置）を伴うため、カスタムURLスキームより横取りされにくく、OAuth2のリダイレクトURIとしてより安全とされ推奨されています。

午前II問題

OAuth2の認可コードフローにおける認可コード横取り攻撃（Authorization Code Interception Attack）とPKCE（Proof Key for Code Exchange）に関する記述のうち、最も適切なものはどれか。

ア）認可コード横取り攻撃は、Webサーバ型のconfidentialクライアント（クライアントシークレットを安全に保持できるサーバサイドアプリ）において特に深刻なリスクとなる　イ）PKCEは、認可リクエスト時にクライアントが生成したcode_verifierのハッシュ値（code_challenge）を送信し、トークン交換時に元のcode_verifierを提示させることで、認可コードを横取りした攻撃者がトークンを取得できないようにする仕組みである　ウ）PKCEはconfidentialクライアントを対象とした仕様であり、モバイルアプリやSPAのようなpublicクライアントには適用できない　エ）PKCEを利用すれば、リダイレクトURIの検証や状態パラメータ（state）によるCSRF対策は不要になる

午前II の解答・解説を見る

正解： イ

解説：

  • ア）不正解。認可コード横取り攻撃は、クライアントシークレットを安全に保持できないpublicクライアント（ネイティブアプリ、SPA等）で特に深刻です。confidentialクライアントはトークン交換時にクライアントシークレットによる認証が可能なため、横取りされた認可コードだけではトークンを取得できません。
  • イ）正解。PKCEでは、クライアントがランダムなcode_verifierを生成し、そのハッシュ値code_challengeを認可リクエストに含めて送信します。トークン交換時には元のcode_verifierを提示する必要があり、認可コードを横取りした攻撃者はcode_verifierを知らないためトークンを取得できません。
  • ウ）不正解。PKCEはむしろpublicクライアント（クライアントシークレットを安全に保持できないモバイルアプリ・SPA）のセキュリティを補強するために策定された仕様（RFC 7636）です。現在ではconfidentialクライアントを含む全てのクライアントタイプへの適用が推奨されています。
  • エ）不正解。PKCEは認可コード横取り攻撃への対策であり、CSRF対策（stateパラメータ）やリダイレクトURIの厳密な検証とは目的が異なります。これらは併用すべきものであり、PKCEの導入によって他の対策が不要になるわけではありません。

午後問題

モバイルバンキングアプリを提供するI社は、OAuth2の認可コードフローを用いて外部の本人確認サービスと連携する機能を実装している。アプリはネイティブのpublicクライアントとして、カスタムURLスキームibank://oauth/callbackをリダイレクトURIに使用していた。

セキュリティ診断の結果、以下の指摘を受けた。

  • 現在の実装ではPKCEが未実装であり、認可コード横取り攻撃に対して脆弱である
  • Android端末において、悪意あるアプリが同一のカスタムURLスキームibank://oauth/callbackを登録可能であり、OSのバージョンや設定によっては認可レスポンス（認可コードを含むリダイレクト）が悪意あるアプリに渡る可能性がある
  • 現在の実装ではリダイレクトURIの完全一致検証が認可サーバ側で行われているが、クライアントシークレットは埋め込まれておらず、認可コードのみでトークン交換が可能な状態であった

設問1

本事例において、悪意あるアプリが認可コードを横取りした場合に、PKCEが実装されていないとどのような被害が発生し得るか、攻撃の流れに沿って説明しなさい。（200字程度）

設問1の解答・解説を見る

正解例： 悪意あるアプリが正規アプリと同一のカスタムURLスキームを登録していると、OSが認可レスポンスを悪意あるアプリへ渡してしまう場合がある。この場合、悪意あるアプリは正規の利用者に代わって認可コードを取得できる。PKCE未実装かつクライアントシークレットも不要な構成では、横取りした認可コードのみをトークンエンドポイントに送信すればアクセストークンを取得でき、悪意あるアプリが利用者になりすまして本人確認サービスの情報を不正取得できてしまう。

解説・採点基準（計15点）：

採点項目キーワード配点
認可コードが悪意あるアプリに渡る経緯同一URLスキーム登録・OSによる誤配送6点
PKCE未実装によるトークン取得成立の説明code_verifier検証なしでトークン交換成立6点
被害の帰結なりすまし・情報不正取得3点

部分点： 攻撃の流れの一部（横取りまたはトークン取得）のみ説明→9点まで。

設問2

セキュリティ診断の指摘を踏まえ、I社が実装すべき対策を2つ述べなさい。（150字程度）

設問2の解答・解説を見る

正解例： 1つ目は、PKCEを実装し、認可リクエスト時にcode_challengeを送信、トークン交換時にcode_verifierの提示を必須化することで、横取りされた認可コード単体ではトークンを取得できないようにする。2つ目は、リダイレクトURIをカスタムURLスキームからAndroid App Links／iOS Universal Linksへ変更し、ドメイン所有権の検証を伴う形式にすることで、悪意あるアプリへの認可レスポンス誤配送のリスク自体を低減する。

解説・採点基準（計15点）：

採点項目キーワード配点
PKCEの実装code_challenge/code_verifier6点
App Links/Universal Linksへの変更ドメイン検証によるリダイレクト保護6点
両対策の関係性・網羅性横取り自体の防止と横取り後の被害防止の両輪3点

部分点： 対策を1つのみ述べた場合は8点まで。

重要キーワード

用語説明
OAuth2 / OIDC認可コードフローを含む認可・認証の標準プロトコル。publicクライアントでの安全性確保が課題となる
認可コード横取り攻撃（Authorization Code Interception）悪意あるアプリやネットワーク経路で認可コードを窃取し、正規クライアントになりすましてトークンを取得する攻撃
PKCE（Proof Key for Code Exchange）RFC 7636で規定される拡張仕様。code_verifierとcode_challengeのペアにより、横取りされた認可コード単体でのトークン取得を防ぐ
publicクライアントクライアントシークレットを安全に保持できないクライアント種別（ネイティブアプリ、SPA等）。PKCEの主要な適用対象
Android App Links / iOS Universal Linksドメイン所有権の検証を伴うディープリンク機構。カスタムURLスキームより横取りされにくくOAuth2のリダイレクトURIとして推奨される
stateパラメータOAuth2の認可リクエストに含めるランダム値。CSRF対策として用いられ、PKCEとは目的の異なる別の対策

まとめ

  • 午前I視点： カスタムURLスキームは複数アプリからの登録が可能な場合があり、横取りリスクの温床になる点、App Links/Universal Linksがより安全な代替である点が基礎知識。
  • 午前II視点： PKCEはpublicクライアント（特にネイティブアプリ・SPA）を主対象とした対策であり、code_verifierとcode_challengeの照合により横取りされた認可コード単体でのトークン取得を防ぐ仕組みが核心。
  • 午後視点： 横取りの「発生経路（URLスキームの重複登録）」と「横取り後の被害成立条件（PKCE未実装）」を分けて説明し、両方に対応する対策（App Links化とPKCE実装）を提示できるかが採点ポイント。