PKCEにおいて、Code VerifierやCode Challenge Methodを不適切な場所に保管すると、認可を乗っ取られるリスクが高まります。具体的に、以下のような場所にこれらの値を保管するとリスクが高くなります。
1. ローカルストレージやセッションストレージ
- リスク: ブラウザのローカルストレージやセッションストレージは、同じオリジン内のJavaScriptによって容易にアクセスされるため、悪意のあるスクリプトによってCode Verifierが盗まれる可能性があります。
- XSSの脅威: もしアプリケーションがクロスサイトスクリプティング（XSS）攻撃の脆弱性を持っている場合、攻撃者は悪意のあるスクリプトを挿入してこれらのストレージにアクセスし、Code Verifierを盗むことができます。
2. クッキー
-
リスク: Code Verifierをクッキーに保管することも、適切なオプションではありません。クッキーは
HttpOnly属性がないとJavaScriptからアクセスできるため、XSS攻撃で盗まれるリスクがあります。 -
セキュリティ属性:
HttpOnlyを付与しても、Code Verifierをクッキーに保管することは一般的ではありません。PKCEはクライアントサイドで生成されるため、クッキーでの保存は意味が薄いです。
3. JavaScriptコード内のグローバル変数
- リスク: Code VerifierをJavaScriptのグローバル変数やクライアントサイドのコード内に直接保管するのも危険です。クライアント側のコードはユーザーや攻撃者によって簡単に検査・読み取りされるため、Code Verifierを含む変数が露出しやすくなります。
- 開発者ツールへのアクセス: ブラウザの開発者ツールを使用して、攻撃者が変数を読み取ることが可能です。
なぜこれらの場所はリスクが高いのか？
- XSS攻撃: XSS攻撃により、悪意のあるスクリプトがアプリケーション内に挿入され、Code Verifierやその他の機密情報を読み取ることができます。
- JavaScriptの脆弱性: クライアントサイドのコードは、ブラウザ環境ではユーザーによって読み取りや改ざんが可能であるため、セキュリティの観点からは保護されていません。
安全な保管方法
- Code Verifierはクライアントサイドのメモリに保管し、使用後は速やかに破棄するのが望ましいです。以下の点に留意してください：
- 一時変数: Code Verifierを使用する際には、JavaScriptの一時変数として格納し、リクエスト後は速やかに削除します。
- 不要なログやデバッグ情報の排除: Code Verifierや関連情報を含むデバッグ情報が誤ってコンソールに出力されないように注意します。
追加の防御策
- CSP（Content Security Policy）の導入: XSS攻撃を防ぐため、適切なCSPを設定して、信頼できないスクリプトが実行されないようにします。
- セキュアコーディングの実践: アプリケーション全体でXSS対策（例えば、出力エスケープや入力バリデーション）を徹底し、攻撃者が悪意のあるコードを注入できないようにします。
Code Verifierは認可フローの一部として重要な役割を担っているため、適切に扱い、不必要に保管しないことがセキュリティを保つ上で不可欠です。