Ein genauerer Blick auf die MVCRequestMatcher Spring-Sicherheitslücke

Am 20. März 2023 veröffentlichte Spring Security Advisories eine Blogbeitrag Verweis auf eine intern entdeckte Sicherheitslücke, CVE-2023-20860. Es wurden keine detaillierten Informationen veröffentlicht, außer dass es sich um ein Problem mit der Zugangskontrolle im Zusammenhang mit der Verwendung von handelte MVC-Matcher. Die Spring-Entwickler haben das Problem behoben, und ein Versionsupdate wird empfohlen.

Möchten Sie eine Erfahrung aus erster Hand? Probiere die Mission hier aus.

Da Sicherheit unser Hauptaugenmerk ist bei Sicherer Codekrieger, haben wir beschlossen, uns eingehender mit dieser MVCRequestMatchers-Sicherheitslücke zu befassen und herauszufinden, wo das Kernproblem liegt.

Spring stellt die RequestMatcher-Schnittstelle bereit, um festzustellen, ob eine Anfrage einem Pfadmuster entspricht. Schauen Sie sich das Code-Snippet unten an, wo MVC-Matcher Die Hilfsmethode wird verwendet, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Wir können zum Beispiel sehen, dass nur Benutzer in der ADMIN-Rolle auf das zugreifen können /logs/audit Endpunkt.

MvcMisMatcher?

Im Frühling ** ist ein Muster, das einer beliebigen Anzahl von Verzeichnissen und Unterverzeichnissen in einer URL entspricht. Zum Beispiel/Bankkonto/** würde allen URLs entsprechen, die mit beginnen /bankkonto/, einschließlich Unterverzeichnissen wie /bankkonto/dashboard/einstellungen.

Das * Ein Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel /bankkonto/ * würde passen Bankkonto/Dashboard.

Bei der Konfiguration der Matcher mit *, Spring gibt an, dass „eine Diskrepanz beim Musterabgleich zwischen Spring Security und Spring MVC“ stattgefunden hat und die Sicherheitslücke geschaffen hat.

Im Wesentlichen stimmt der Pfad aufgrund des Fehlens eines Trennzeichens vor dem doppelten Platzhalter nicht mit einer eingehenden Anfrage überein, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. Das bedeutet, dass die Zugriffskontrollregeln nicht angewendet werden und jeder nicht authentifizierte Benutzer auf die Ressourcen zugreifen kann.

Schauen wir uns das an verpflichten das hat das Problem behoben.

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

404-Match wurde nicht gefunden

Beim Senden einer Webanfrage an /bankkonten/anzeigen die Spiel Die Methode analysiert und vergleicht die im Sicherheitsfilter definierten Muster mit dem angeforderten Pfad. Der Parser wandelt das angegebene Muster in einen Baum von Pfadelementen um.

Der Parser liest das erste Zeichen als SeparatorPath-Element. Dann liest es die Zeichenkettenzeichen bis zum nächsten Trennzeichen weiter und erstellt ein neues LiteralPath-Element.

Also, wo geht es schief bei der Verwendung ** als das Muster?

Es gibt zwar viele Pfadelementtypen, aber die interessantesten hier sind die Wildcard Path-Elementt und die Platzhalter für das RestPath-Element, mit ihren jeweiligen Zeichenkettendarstellungen: * und /**. 

EIN Platzhalter-Path-Element entspricht null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments, während ein Platzhalter für das RestPath-Element entspricht für sich genommen null oder mehr Pfadsegmente (einschließlich der Trennzeichen).

Letzteres gibt uns einen Hinweis darauf, was beim Einreichen schief geht. ** als Muster. Beim Parsen sucht es nach Mustern, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Also anstatt ein zu werden Platzhalter für das RestPath-Element, es werden zwei aufeinanderfolgende Wildcard-Path-Elemente.

Als Nächstes wird das analysierte Muster verwendet, um es mit der angeforderten URL abzugleichen. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht zu den Trennzeichen.

Das bedeutet, dass anstelle eines Spielergebnis anfordern, eine Null wird zurückgegeben. Folglich werden die für diesen Matcher festgelegten Zugriffskontrollregeln nicht auf die angeforderte URL angewendet.

Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten, irgendein ** Muster wird /**, was bedeutet, dass es als analysiert werden kann Platzhalter für das RestPath-Element, und ein Spielergebnis anfordern wird zurückgegeben, da das Muster jetzt mit der angeforderten URL übereinstimmt.

Sicherheitslücke oder API-Missbrauch?

Es ist fraglich, ob dies als Sicherheitslücke betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen in der Tatsache, dass Frühlings-Dokumentation fehlt eine ausdrückliche Erwähnung, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es sich eher um einen API-Missbrauch als um einen Bug oder eine Sicherheitslücke handeln.