mvcRequestMatcher Springの脆弱性を詳しく見てみる
2023年3月20日、Spring Security Advisoriesは、内部で発見された脆弱性「CVE-2023-20860」に言及するブログ記事を公開しました。mvcMatchersの使用に関するアクセス制御の問題であることを除いて、詳細な情報は開示されていません。Springの開発者はこの問題を修正し、バージョンアップを勧めています。
実際に体験してみませんか？こちらのミッションを試してみてください。
において、セキュリティに重点を置いているため Secure Code Warriorそこで、このmvcRequestMatchersの脆弱性をより深く掘り下げ、問題の核心がどこにあるのかを突き止めることにしました。
Spring は RequestMatcher インターフェースを提供し、リクエストがパスパターンに一致するかどうかを判断します。以下のコードを見てください。mvcMatchersヘルパーメソッドを使用して、エンドポイントとその認証・認可要件を登録しています。たとえば、ADMIN ロールのユーザーだけが/logs/audit エンドポイントにアクセスできることがわかります。
MvcMisMatchers？
Springでは、 **は、URL内の任意の数のディレクトリとサブディレクトリにマッチするパターンです。例えば、/bankaccount/**は、/bankaccount/で始まるすべてのURLにマッチし、/bankaccount/dashboard/settingsのようなサブディレクトリを含む。
パターンは、任意のURLにマッチするパターンであり、サブディレクトリのレベルがちょうど1つである。例えば、/bankaccount/*は 、bankaccount/dashboardにマッチします。
マッチャーを*で構成する際、Springは「Spring SecurityとSpring MVCの間のパターンマッチの不一致」が起こり、脆弱性が発生したとしています。
基本的に、ダブルワイルドカードの前にセパレータがないため、すべての受信リクエストの先頭にスラッシュが付くため、パスは受信リクエストにマッチしません。つまり、アクセス制御ルールが適用されず、認証されていないユーザーでもリソースにアクセスできてしまうのです。
この問題を修正したコミットを見てみましょう。
最も顕著で重要な変更は、315行目の追加で、認可および認証ルールの迂回を修正するものです。これにより、送信されたパスパターンの前にフォワードスラッシュ（/）が付くようになります。
404 マッチが見つかりません
bankaccounts/viewに Webリクエストを送信すると、matchメソッドはセキュリティフィルターで定義されたパターンを解析し、リクエストされたパスと比較します。パーサーは、与えられたパターンをパス要素のツリーに変換します。
パーサーは、最初の文字をSeparatorPathElementとして読み取ります。そして、次のセパレーターまで文字列の読み込みを続け、新しいLiteralPathElementを 作成します。
では、**をパターンとして使用する場合、どこで失敗するのでしょうか？
パス要素の種類はたくさんありますが、ここで最も興味深いのはWildcardPathElementと WildcardTheRestPathElementであり、それぞれの文字列表現があります：* と/**です。
WildcardPathElementは、1つのパスセグメント内の0個以上の文字にマッチし、WildcardTheRestPathElementは、それ自体で0個以上のパスセグメントにマッチします（セパレータも含む）。
後者は、**をパターンとして送信する際に何が間違っているのかを知る手がかりになります。解析中にパターンを探しますが、**は期待された前方スラッシュで始まらないのです。そのため、WildcardTheRestPathElementになるのではなく、2つの連続したWildcardPathElementになります。
次に、解析されたパターンを使って、要求されたURLと照合します。パスはフォワードスラッシュで始まることが期待されますが、ワイルドカードはセパレータにマッチしません。
これは、RequestMatchResultの代わりにNULLが返されることを意味します。その結果、このマッチャーに設定されたアクセス制御ルールは、要求されたURLには適用されません。
Springでは、スラッシュを前置することでこの問題を修正しました。つまり、どんな**パターンも/**になり、WildcardTheRestPathElementとして解析され、要求されたURLにマッチするようになったのでRequestMatchResultが返されます。
脆弱性か、APIの悪用か。
このコードが意図したとおりに動作するため、これを脆弱性とみなすべきかどうかは議論の余地があります。この問題は、基本的にSpringのドキュメントに、パスがセパレータで始まるべきだという明示的な記述がないことにあります。したがって、バグや脆弱性ではなく、APIの誤用と考えることができる。
2023年3月20日、Spring Security Advisoriesは、内部で発見された脆弱性「CVE-2023-20860」に言及するブログ記事を公開しました。詳細な情報は公開されておらず、`mvcMatchers`の使用に関するアクセス制御の問題であることが判明しています。Springの開発者はこの問題を修正し、バージョンアップを推奨しています。Secure Code Warrior では、セキュリティに主眼を置いているため、この mvcRequestMatchers の脆弱性を深く掘り下げ、問題の核心がどこにあるのかを突き止めることにしました。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Brysenは、Secure Code Warrior 、安全なコードを書くことに重点を置いたソフトウェア開発者です。
2023年3月20日、Spring Security Advisoriesは、内部で発見された脆弱性「CVE-2023-20860」に言及するブログ記事を公開しました。mvcMatchersの使用に関するアクセス制御の問題であることを除いて、詳細な情報は開示されていません。Springの開発者はこの問題を修正し、バージョンアップを勧めています。
実際に体験してみませんか？こちらのミッションを試してみてください。
において、セキュリティに重点を置いているため Secure Code Warriorそこで、このmvcRequestMatchersの脆弱性をより深く掘り下げ、問題の核心がどこにあるのかを突き止めることにしました。
Spring は RequestMatcher インターフェースを提供し、リクエストがパスパターンに一致するかどうかを判断します。以下のコードを見てください。mvcMatchersヘルパーメソッドを使用して、エンドポイントとその認証・認可要件を登録しています。たとえば、ADMIN ロールのユーザーだけが/logs/audit エンドポイントにアクセスできることがわかります。
MvcMisMatchers？
Springでは、 **は、URL内の任意の数のディレクトリとサブディレクトリにマッチするパターンです。例えば、/bankaccount/**は、/bankaccount/で始まるすべてのURLにマッチし、/bankaccount/dashboard/settingsのようなサブディレクトリを含む。
パターンは、任意のURLにマッチするパターンであり、サブディレクトリのレベルがちょうど1つである。例えば、/bankaccount/*は 、bankaccount/dashboardにマッチします。
マッチャーを*で構成する際、Springは「Spring SecurityとSpring MVCの間のパターンマッチの不一致」が起こり、脆弱性が発生したとしています。
基本的に、ダブルワイルドカードの前にセパレータがないため、すべての受信リクエストの先頭にスラッシュが付くため、パスは受信リクエストにマッチしません。つまり、アクセス制御ルールが適用されず、認証されていないユーザーでもリソースにアクセスできてしまうのです。
この問題を修正したコミットを見てみましょう。
最も顕著で重要な変更は、315行目の追加で、認可および認証ルールの迂回を修正するものです。これにより、送信されたパスパターンの前にフォワードスラッシュ（/）が付くようになります。
404 マッチが見つかりません
bankaccounts/viewに Webリクエストを送信すると、matchメソッドはセキュリティフィルターで定義されたパターンを解析し、リクエストされたパスと比較します。パーサーは、与えられたパターンをパス要素のツリーに変換します。
パーサーは、最初の文字をSeparatorPathElementとして読み取ります。そして、次のセパレーターまで文字列の読み込みを続け、新しいLiteralPathElementを 作成します。
では、**をパターンとして使用する場合、どこで失敗するのでしょうか？
パス要素の種類はたくさんありますが、ここで最も興味深いのはWildcardPathElementと WildcardTheRestPathElementであり、それぞれの文字列表現があります：* と/**です。
WildcardPathElementは、1つのパスセグメント内の0個以上の文字にマッチし、WildcardTheRestPathElementは、それ自体で0個以上のパスセグメントにマッチします（セパレータも含む）。
後者は、**をパターンとして送信する際に何が間違っているのかを知る手がかりになります。解析中にパターンを探しますが、**は期待された前方スラッシュで始まらないのです。そのため、WildcardTheRestPathElementになるのではなく、2つの連続したWildcardPathElementになります。
次に、解析されたパターンを使って、要求されたURLと照合します。パスはフォワードスラッシュで始まることが期待されますが、ワイルドカードはセパレータにマッチしません。
これは、RequestMatchResultの代わりにNULLが返されることを意味します。その結果、このマッチャーに設定されたアクセス制御ルールは、要求されたURLには適用されません。
Springでは、スラッシュを前置することでこの問題を修正しました。つまり、どんな**パターンも/**になり、WildcardTheRestPathElementとして解析され、要求されたURLにマッチするようになったのでRequestMatchResultが返されます。
脆弱性か、APIの悪用か。
このコードが意図したとおりに動作するため、これを脆弱性とみなすべきかどうかは議論の余地があります。この問題は、基本的にSpringのドキュメントに、パスがセパレータで始まるべきだという明示的な記述がないことにあります。したがって、バグや脆弱性ではなく、APIの誤用と考えることができる。
2023年3月20日、Spring Security Advisoriesは、内部で発見された脆弱性「CVE-2023-20860」に言及するブログ記事を公開しました。mvcMatchersの使用に関するアクセス制御の問題であることを除いて、詳細な情報は開示されていません。Springの開発者はこの問題を修正し、バージョンアップを勧めています。
実際に体験してみませんか？こちらのミッションを試してみてください。
において、セキュリティに重点を置いているため Secure Code Warriorそこで、このmvcRequestMatchersの脆弱性をより深く掘り下げ、問題の核心がどこにあるのかを突き止めることにしました。
Spring は RequestMatcher インターフェースを提供し、リクエストがパスパターンに一致するかどうかを判断します。以下のコードを見てください。mvcMatchersヘルパーメソッドを使用して、エンドポイントとその認証・認可要件を登録しています。たとえば、ADMIN ロールのユーザーだけが/logs/audit エンドポイントにアクセスできることがわかります。
MvcMisMatchers？
Springでは、 **は、URL内の任意の数のディレクトリとサブディレクトリにマッチするパターンです。例えば、/bankaccount/**は、/bankaccount/で始まるすべてのURLにマッチし、/bankaccount/dashboard/settingsのようなサブディレクトリを含む。
パターンは、任意のURLにマッチするパターンであり、サブディレクトリのレベルがちょうど1つである。例えば、/bankaccount/*は 、bankaccount/dashboardにマッチします。
マッチャーを*で構成する際、Springは「Spring SecurityとSpring MVCの間のパターンマッチの不一致」が起こり、脆弱性が発生したとしています。
基本的に、ダブルワイルドカードの前にセパレータがないため、すべての受信リクエストの先頭にスラッシュが付くため、パスは受信リクエストにマッチしません。つまり、アクセス制御ルールが適用されず、認証されていないユーザーでもリソースにアクセスできてしまうのです。
この問題を修正したコミットを見てみましょう。
最も顕著で重要な変更は、315行目の追加で、認可および認証ルールの迂回を修正するものです。これにより、送信されたパスパターンの前にフォワードスラッシュ（/）が付くようになります。
404 マッチが見つかりません
bankaccounts/viewに Webリクエストを送信すると、matchメソッドはセキュリティフィルターで定義されたパターンを解析し、リクエストされたパスと比較します。パーサーは、与えられたパターンをパス要素のツリーに変換します。
パーサーは、最初の文字をSeparatorPathElementとして読み取ります。そして、次のセパレーターまで文字列の読み込みを続け、新しいLiteralPathElementを 作成します。
では、**をパターンとして使用する場合、どこで失敗するのでしょうか？
パス要素の種類はたくさんありますが、ここで最も興味深いのはWildcardPathElementと WildcardTheRestPathElementであり、それぞれの文字列表現があります：* と/**です。
WildcardPathElementは、1つのパスセグメント内の0個以上の文字にマッチし、WildcardTheRestPathElementは、それ自体で0個以上のパスセグメントにマッチします（セパレータも含む）。
後者は、**をパターンとして送信する際に何が間違っているのかを知る手がかりになります。解析中にパターンを探しますが、**は期待された前方スラッシュで始まらないのです。そのため、WildcardTheRestPathElementになるのではなく、2つの連続したWildcardPathElementになります。
次に、解析されたパターンを使って、要求されたURLと照合します。パスはフォワードスラッシュで始まることが期待されますが、ワイルドカードはセパレータにマッチしません。
これは、RequestMatchResultの代わりにNULLが返されることを意味します。その結果、このマッチャーに設定されたアクセス制御ルールは、要求されたURLには適用されません。
Springでは、スラッシュを前置することでこの問題を修正しました。つまり、どんな**パターンも/**になり、WildcardTheRestPathElementとして解析され、要求されたURLにマッチするようになったのでRequestMatchResultが返されます。
脆弱性か、APIの悪用か。
このコードが意図したとおりに動作するため、これを脆弱性とみなすべきかどうかは議論の余地があります。この問題は、基本的にSpringのドキュメントに、パスがセパレータで始まるべきだという明示的な記述がないことにあります。したがって、バグや脆弱性ではなく、APIの誤用と考えることができる。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Brysenは、Secure Code Warrior 、安全なコードを書くことに重点を置いたソフトウェア開発者です。
2023年3月20日、Spring Security Advisoriesは、内部で発見された脆弱性「CVE-2023-20860」に言及するブログ記事を公開しました。mvcMatchersの使用に関するアクセス制御の問題であることを除いて、詳細な情報は開示されていません。Springの開発者はこの問題を修正し、バージョンアップを勧めています。
実際に体験してみませんか？こちらのミッションを試してみてください。
において、セキュリティに重点を置いているため Secure Code Warriorそこで、このmvcRequestMatchersの脆弱性をより深く掘り下げ、問題の核心がどこにあるのかを突き止めることにしました。
Spring は RequestMatcher インターフェースを提供し、リクエストがパスパターンに一致するかどうかを判断します。以下のコードを見てください。mvcMatchersヘルパーメソッドを使用して、エンドポイントとその認証・認可要件を登録しています。たとえば、ADMIN ロールのユーザーだけが/logs/audit エンドポイントにアクセスできることがわかります。
MvcMisMatchers？
Springでは、 **は、URL内の任意の数のディレクトリとサブディレクトリにマッチするパターンです。例えば、/bankaccount/**は、/bankaccount/で始まるすべてのURLにマッチし、/bankaccount/dashboard/settingsのようなサブディレクトリを含む。
パターンは、任意のURLにマッチするパターンであり、サブディレクトリのレベルがちょうど1つである。例えば、/bankaccount/*は 、bankaccount/dashboardにマッチします。
マッチャーを*で構成する際、Springは「Spring SecurityとSpring MVCの間のパターンマッチの不一致」が起こり、脆弱性が発生したとしています。
基本的に、ダブルワイルドカードの前にセパレータがないため、すべての受信リクエストの先頭にスラッシュが付くため、パスは受信リクエストにマッチしません。つまり、アクセス制御ルールが適用されず、認証されていないユーザーでもリソースにアクセスできてしまうのです。
この問題を修正したコミットを見てみましょう。
最も顕著で重要な変更は、315行目の追加で、認可および認証ルールの迂回を修正するものです。これにより、送信されたパスパターンの前にフォワードスラッシュ（/）が付くようになります。
404 マッチが見つかりません
bankaccounts/viewに Webリクエストを送信すると、matchメソッドはセキュリティフィルターで定義されたパターンを解析し、リクエストされたパスと比較します。パーサーは、与えられたパターンをパス要素のツリーに変換します。
パーサーは、最初の文字をSeparatorPathElementとして読み取ります。そして、次のセパレーターまで文字列の読み込みを続け、新しいLiteralPathElementを 作成します。
では、**をパターンとして使用する場合、どこで失敗するのでしょうか？
パス要素の種類はたくさんありますが、ここで最も興味深いのはWildcardPathElementと WildcardTheRestPathElementであり、それぞれの文字列表現があります：* と/**です。
WildcardPathElementは、1つのパスセグメント内の0個以上の文字にマッチし、WildcardTheRestPathElementは、それ自体で0個以上のパスセグメントにマッチします（セパレータも含む）。
後者は、**をパターンとして送信する際に何が間違っているのかを知る手がかりになります。解析中にパターンを探しますが、**は期待された前方スラッシュで始まらないのです。そのため、WildcardTheRestPathElementになるのではなく、2つの連続したWildcardPathElementになります。
次に、解析されたパターンを使って、要求されたURLと照合します。パスはフォワードスラッシュで始まることが期待されますが、ワイルドカードはセパレータにマッチしません。
これは、RequestMatchResultの代わりにNULLが返されることを意味します。その結果、このマッチャーに設定されたアクセス制御ルールは、要求されたURLには適用されません。
Springでは、スラッシュを前置することでこの問題を修正しました。つまり、どんな**パターンも/**になり、WildcardTheRestPathElementとして解析され、要求されたURLにマッチするようになったのでRequestMatchResultが返されます。
脆弱性か、APIの悪用か。
このコードが意図したとおりに動作するため、これを脆弱性とみなすべきかどうかは議論の余地があります。この問題は、基本的にSpringのドキュメントに、パスがセパレータで始まるべきだという明示的な記述がないことにあります。したがって、バグや脆弱性ではなく、APIの誤用と考えることができる。
始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
