目次 概要 対応 脆弱性 タイムライン このブログはこちらの英語ブログ（2024年4月24日公開）の翻訳、南野要によるレビューです。 概要 Oktaは、報告されたOkta Verifyの脆弱性を確認し、修復しました。お客様による対応は必要ありません。また、当初の概念実証以外にこの脆弱性が悪用された痕跡は見つかっておりません。先般のOkta Secure Identity Commitmentの一環として、Oktaは透明性の精神に基づき、この修復についてお客様にお知らせしています。 対応 4月5日、Oktaは、Persistent Securityの研究員から、フィッシング耐性チェックの回避に関するOkta Verifyの潜在的な脆弱性について報告を受けました。この報告を受け、Oktaは脆弱性の開示プロセスを開始し、さらに調査を進めた結果、特定のパラメータを指定するとOkta VerifyのFastPassのフィッシング耐性を回避できることが判明しました。 4月8日、Oktaのエンジニアリングチームは、Oktaのバックエンドコード内の根本原因の特定に成功し、緩和策を作成しました。この根本原因は、Okta Verifyのアプリケーション内には存在しなかったということが重要な点です。 脆弱性 この脆弱性に関する詳細情報は以下のとおりです。 CUSTOM_URIとSSO Extensionを含むフィッシング耐性のあるチャレンジにおいて： ユーザーが、ユーザー検証または同意プロンプトへの承認のみを提供し、さらに オリジンヘッダーが欠落している場合、その判定ロジックは「true」を返します。これはユーザーが承認済みの同意プロンプトが、その欠落したオリジンヘッダーに付随している場合のみ、トランザクションを承認するという認可の意図があったためです。 しかし、当社では、オリジンヘッダーの欠落と承認済みのユーザー検証（または承認済み同意プロンプト）の存在が、フィッシング耐性があることが確認されたことと同等であると誤って想定していました。これを修正するため、フィッシング耐性を確認する前に、有効なオリジンヘッダーが存在することを確認する追加の検証ステップを実装しました。今後、この対策により、トランザクションの有効性および安全性を保証します。 4月9日、この修正は開発環境に適用され、有効であることが確認されました。その後、本番環境に修正プログラムを適用し、さらなる検証を成功させた後、4月10日には残りのすべての本番環境に、4月11日にはプレビュー環境に同じ修正を適用しました。この修正プログラムによって脆弱性は修正され、お客様による追加の対応は必要ありませんでした。 しかし、今回報告された脆弱性は、包括的な脅威モデルの重要性と、安全なコンポーネントを開発する上で手動テストが果たす役割の重要性を浮き彫りにしています。Oktaは、PSI（Persistent Security Industries）チームのNikos LaleasとGiuseppe Trottaが、この脆弱性を当社に知らせてくれたこと、そして責任ある情報開示に尽力してくれたことを心から感謝しております。 タイムライン 2024年4月5日 - Persistent SecurityがOktaにレポートを提出 2024年4月6日 - Okta Securityが調査結果を検証 2024年4月8日 - Oktaが根本原因を発見 2024 年4月9日 - Okta が開発環境に修正をデプロイ 2024年4月9日 - Oktaが修正を検証 2024 年4月10日 - 本番環境に修正プログラムを適用 2024 年4月11日 - プレビュー環境に修正プログラムを適用 以上の内容は、原文（英語）の参考和訳であり、原文と内容に差異がある場合は、原文が優先されます。