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の誤用と考えることができる。
.png)
