Ein genauerer Blick auf die mvcRequestMatcher-Schwachstelle in Spring

Am 20. März 2023 veröffentlichten die Spring Security Advisories einen Blogbeitrag über eine intern entdeckte Schwachstelle, CVE-2023-20860. Es wurden keine detaillierten Informationen bekannt gegeben, außer dass es sich um ein Zugriffskontrollproblem bei der Verwendung von mvcMatchers handelte. Die Spring-Entwickler haben das Problem behoben und ein Versions-Update wird empfohlen.

Möchten Sie das aus erster Hand erleben? Probieren Sie die Mission hier aus.

Da Sicherheit bei Secure Code Warrior unser Hauptfokus ist, haben wir uns diese mvcRequestMatchers-Schwachstelle genauer angesehen, um den Kern des Problems zu finden.

Spring stellt das RequestMatcher-Interface bereit, um festzustellen, ob eine Anfrage einem Pfadmuster entspricht. Werfen Sie einen Blick auf den folgenden Code-Ausschnitt, in dem die mvcMatchers-Hilfsmethode verwendet wird, um Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Wir sehen zum Beispiel, dass nur Benutzer mit der Rolle ADMIN auf den /logs/audit -Endpunkt zugreifen können.

MvcMisMatchers?

In Spring ist ** ein Muster, das einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL entspricht. Zum Beispiel würde /bankaccount/** auf alle URLs passen, die mit /bankaccount/ beginnen, einschließlich Unterverzeichnissen wie /bankaccount/dashboard/settings.

Das *-Muster entspricht jeder URL und umfasst genau eine Ebene eines Unterverzeichnisses. Zum Beispiel würde /bankaccount/* auf bankaccount/dashboard passen.

Bei der Konfiguration der Matcher mit * stellt Spring fest, dass "eine Diskrepanz beim Pattern Matching zwischen Spring Security und Spring MVC" auftrat, was die Schwachstelle verursachte.

Im Wesentlichen führt das Fehlen eines Trennzeichens vor dem doppelten Platzhalter dazu, dass der Pfad nicht mit einer eingehenden Anfrage übereinstimmt, da allen eingehenden Anfragen ein Schrägstrich vorangestellt ist. Dies bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.

Werfen wir einen Blick auf den Commit, der das Problem behoben hat.

Die prominenteste und wichtigste Änderung ist das Hinzufügen von Zeile 315, die das Umgehen der Autorisierungs- und Authentifizierungsregeln behebt. Sie stellt sicher, dass jedem übermittelten Pfadmuster ein Schrägstrich (/) vorangestellt wird.

404 Übereinstimmung nicht gefunden

Beim Senden einer Webanfrage an /bankaccounts/view wird die match-Methode die im Sicherheitsfilter definierten Muster analysieren und mit dem angeforderten Pfad vergleichen. Der Parser wandelt das gegebene Muster in einen Baum von Pfadelementen um.

Der Parser liest das erste Zeichen als SeparatorPathElement. Anschließend liest er die Zeichen der Zeichenfolge weiter, bis das nächste Trennzeichen erreicht ist, und erstellt ein neues LiteralPathElement.

Wo liegt also der Fehler bei der Verwendung von ** als Muster?

Es gibt zwar zahlreiche Pfadelementtypen, aber die interessantesten sind hier das WildcardPathElement und das WildcardTheRestPathElement mit ihren jeweiligen String-Repräsentationen: * und /**. 

Ein WildcardPathElement entspricht null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments, während ein WildcardTheRestPathElement null oder mehr Pfadsegmente eigenständig abdeckt (einschließlich der Trennzeichen).

Letzteres gibt uns einen Hinweis darauf, was bei der Übermittlung von ** als Muster schiefgeht. Beim Parsen wird nach Mustern gesucht, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Anstatt also zu einem WildcardTheRestPathElement zu werden, entstehen zwei aufeinanderfolgende WildcardPathElements.

Anschließend wird das geparste Muster verwendet, um es mit der angeforderten URL abzugleichen. Pfade müssen mit einem Schrägstrich beginnen, aber ein Platzhalter entspricht keinen Trennzeichen.

Dies bedeutet, dass anstelle eines RequestMatchResult ein Nullwert zurückgegeben wird. Folglich werden die für diesen Matcher festgelegten Zugriffskontrollregeln nicht auf die angeforderte URL angewendet.

Spring hat das Problem durch das Voranstellen eines Schrägstrichs behoben. Mit anderen Worten: Jedes **-Muster wird zu /**, wodurch es als WildcardTheRestPathElement geparst werden kann und ein RequestMatchResult zurückgegeben wird, da das Muster nun mit der angeforderten URL übereinstimmt.

Schwachstelle oder API-Fehlgebrauch?

Es ist umstritten, ob dies als Schwachstelle betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Grunde darin, dass in der Spring-Dokumentation nicht explizit erwähnt wird, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte man eher von einem API-Fehlgebrauch als von einem Fehler oder einer Schwachstelle sprechen.