SpringのmvcRequestMatcherにおける脆弱性の詳細な調査

2023年3月20日、Spring Security Advisoriesは、ブログ記事を公開し、内部で発見された脆弱性CVE-2023-20860について言及しました。詳細な情報は開示されていませんでしたが、これはmvcMatchersの使用に関するアクセス制御の問題でした。Springの開発チームはこの問題を修正済みであり、バージョンアップが推奨されています。

実際に体験してみませんか？こちらのミッションをお試しください。

Secure Code Warriorではセキュリティを最優先事項としているため、Secure Code Warrior、私たちはこのmvcRequestMatchersの脆弱性を深く掘り下げ、根本的な問題がどこにあるのかを調査することにしました。

Springは、リクエストがパスパターンと一致するかどうかを判断するためのRequestMatcherインターフェースを提供しています。以下のコードスニペットでは、mvcMatchersヘルパーメソッドを使用して、エンドポイントとそれに対する認証および認可の要件を登録しています。例えば、ADMINロールを持つユーザーのみが/logs/auditエンドポイントにアクセスできることがわかります。

MvcMisMatchers？

Springにおいて、 **はURL内の任意の数のディレクトリやサブディレクトリに一致させるためのパターンです。例えば、/bankaccount/**は、/bankaccount/で始まるすべてのURLに一致し、/bankaccount/dashboard/settingsのようなサブディレクトリも含まれます。

*パターンは、任意のURLに一致し、かつサブディレクトリの階層がちょうど1つである場合に一致するパターンです。例えば、/bankaccount/*はに一致します。

matchersを*で設定する際、Springは「Spring SecurityとSpring MVCの間でパターンマッチングの不一致」が発生し、それが脆弱性を生み出したと述べています。

本質的に、ダブルワイルドカードの前にセパレーターがないため、すべての受信リクエストの先頭にはスラッシュが付加されるにもかかわらず、パスが受信リクエストと一致しません。これは、アクセス制御ルールが適用されず、認証されていないユーザーがリソースにアクセスできてしまうことを意味します。

問題を修正したコミットを見てみましょう。

最も顕著で重要な変更は、315行目の追加です。これにより、認可および認証ルールのバイパスが修正されました。送信されたパスパターンの先頭に必ずスラッシュ（/）が付加されるようになっています。

404 一致するものが見つかりません

/bankaccounts/viewへのWebリクエストを送信すると、matchメソッドがセキュリティフィルターで定義されたパターンとリクエストされたパスを解析・比較します。パーサーは、指定されたパターンをパス要素のツリーに変換します。

The parser reads the first character as a SeparatorPathElement. It then continues reading the string characters until the next separator, creating a new LiteralPathElement. 

では、パターンとして**を使用した場合、どこで問題が発生するのでしょうか？

パス要素の型は数多く存在しますが、ここで特に興味深いのは WildcardPathElement と WildcardTheRestPathElement であり、それぞれの文字列表現は * と /** です。

WildcardPathElement は単一のパスセグメント内の0文字以上の文字列に一致し、WildcardTheRestPathElement は（セパレーターを含め）0個以上のパスセグメント自体に一致します。

後者は、** をパターンとして送信した際に何が問題となるのかを示唆しています。解析中、システムはパターンを検索しますが、** は期待されるスラッシュで始まっていません。そのため、WildcardTheRestPathElement になる代わりに、2つの連続した WildcardPathElement として扱われてしまいます。

次に、解析されたパターンを使用してリクエストされたURLとの照合が行われます。パスはスラッシュで始まることが想定されていますが、ワイルドカードはセパレーターには一致しません。

これは、RequestMatchResult ではなく null が返されることを意味します。その結果、このマッチャーに設定されたアクセス制御ルールが、リクエストされたURLに適用されなくなります。

Springはこの問題を、先頭にスラッシュを付加することで修正しました。つまり、どのような ** パターンも /** となり、WildcardTheRestPathElement として解析可能になります。その結果、パターンがリクエストされたURLと一致するようになり、RequestMatchResult が返されるようになります。

脆弱性か、それともAPIの誤用か？

コードは意図した通りに動作しているため、これを脆弱性と見なすべきかどうかは議論の余地があります。根本的な問題は、Springのドキュメント に、パスはセパレーターで始まるべきであるという明示的な記述が欠けている点にあります。したがって、これはバグや脆弱性というよりも、APIの誤用の一例と見なすことができるでしょう。