仔细研究 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の誤用と考えることができる。
%20(1).avif)
.avif)
