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の誤用と考えることができる。
ブライセン・アックス
Brysenは、Secure Code Warrior 、安全なコードを書くことに重点を置いたソフトウェア開発者です。
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
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の誤用と考えることができる。
