Ein genauerer Blick auf die mvcRequestMatcher Spring-Schwachstelle

Veröffentlicht Apr 19, 2023
von Brysen Ackx
FALLSTUDIE

Ein genauerer Blick auf die mvcRequestMatcher Spring-Schwachstelle

Veröffentlicht Apr 19, 2023
von Brysen Ackx
Ressource anzeigen
Ressource anzeigen
Schädel-Symbol über einem gelben geometrischen abstrakten Hintergrund
Schädel-Symbol über einem gelben geometrischen abstrakten Hintergrund

Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, der sich auf eine intern entdeckte Sicherheitslücke CVE-2023-20860 bezog. Es wurden keine detaillierten Informationen bekannt gegeben, außer dass es sich um ein Problem der Zugriffskontrolle bei der Verwendung von mvcMatchers handelt. Die Spring-Entwickler haben das Problem behoben, und es wird ein Versionsupdate empfohlen.

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

Da Sicherheit unser Hauptaugenmerk bei Secure Code Warriorist, haben wir uns entschlossen, diese mvcRequestMatchers-Schwachstelle genauer zu untersuchen und herauszufinden, wo das Kernproblem liegt.

Spring bietet die RequestMatcher-Schnittstelle, um festzustellen, ob eine Anfrage mit einem Pfadmuster übereinstimmt. Schauen Sie sich den folgenden Codeausschnitt an, in dem die Hilfsmethode mvcMatchers verwendet wird, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Zum Beispiel können wir sehen, dass nur Benutzer mit der Rolle ADMIN auf den Endpunkt /logs/audit zugreifen können. 

MvcMisMatchers?

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

Das *-Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel würde /bankaccount/* auf bankaccount/dashboard passen .

Bei der Konfiguration der Matcher mit * stellt Spring fest, dass "eine Fehlanpassung beim Pattern-Matching zwischen Spring Security und Spr ing MVC" stattgefunden hat, wodurch die Schwachstelle entstand.

Da dem doppelten Platzhalter kein Trennzeichen vorangestellt ist, passt der Pfad nicht zu einer eingehenden Anfrage, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. 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 auffälligste und wichtigste Änderung ist die Hinzufügung von Zeile 315, mit der die Umgehung der Autorisierungs- und Authentifizierungsregeln behoben wird. Sie stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird. 

404 Treffer nicht gefunden

PathPatternMatchableHandlerMapping-Klasse (Quelle : spring-framework)

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

Der Parser liest das erste Zeichen als SeparatorPathElement. Er setzt dann das Lesen der Zeichenfolgen bis zum nächsten Trennzeichen fort und erstellt ein neues LiteralPathElement.

Was läuft also schief, wenn ** als Muster verwendet wird? 

Es gibt zwar eine Vielzahl von Pfadelementtypen, aber die interessantesten sind das WildcardPathElementund das WildcardTheRestPathElement mit ihren jeweiligen Zeichenkettendarstellungen: * und /**. 

Ein WildcardPathElement stimmt mit null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments überein, während ein WildcardTheRestPathElement mit null oder mehr Pfadsegmenten allein übereinstimmt (einschließlich der Trennzeichen).

Letzteres gibt uns einen Hinweis darauf, was falsch läuft, wenn ** als Muster eingegeben wird. Beim Parsen wird nach Mustern gesucht, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Anstatt also ein WildcardTheRestPathElement zu werden, wird es zu zwei aufeinanderfolgenden WildcardPathElementen.

Anschließend wird das geparste Muster zum Abgleich mit der angeforderten URL verwendet. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht auf Trennzeichen.

Auszug aus WildCardPathElement.java

Dies bedeutet, dass anstelle eines RequestMatchResult ein Nullwert zurückgegeben wird. Folglich werden die Zugriffskontrollregeln, die diesem Abgleicher zugewiesen wurden, nicht auf die angeforderte URL angewendet.

Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten: Jedes **-Muster wird zu /**, d. h. es kann als WildcardTheRestPathElement geparst werden, und es wird ein RequestMatchResult zurückgegeben, da das Muster nun mit der angeforderten URL übereinstimmt.

Schwachstelle oder API-Missbrauch?

Es ist fraglich, ob dies als Schwachstelle betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen darin, dass in der Spring-Dokumentation nicht ausdrücklich erwähnt wird, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es eher als ein Fall von API-Missbrauch und nicht als ein Fehler oder eine Schwachstelle angesehen werden.

Ressource anzeigen
Ressource anzeigen

CVE-2023-20860 Auftrag

Probieren Sie unsere Mission aus, um die Auswirkungen selbst zu erleben und zu lernen, wie Sie ähnliche Fehler vermeiden können.

Jetzt ausprobieren
Autor

Brysen Ackx

Brysen ist Softwareentwickler bei Secure Code Warrior mit Schwerpunkt auf dem Schreiben von sicherem Code.

Sie wollen mehr?

Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.

Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.

Blog ansehen
Sie wollen mehr?

Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit

Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.

Ressourcendrehscheibe

Ein genauerer Blick auf die mvcRequestMatcher Spring-Schwachstelle

Veröffentlicht Apr 19, 2023
Von Brysen Ackx

Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, der sich auf eine intern entdeckte Sicherheitslücke CVE-2023-20860 bezog. Es wurden keine detaillierten Informationen bekannt gegeben, außer dass es sich um ein Problem der Zugriffskontrolle bei der Verwendung von mvcMatchers handelt. Die Spring-Entwickler haben das Problem behoben, und es wird ein Versionsupdate empfohlen.

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

Da Sicherheit unser Hauptaugenmerk bei Secure Code Warriorist, haben wir uns entschlossen, diese mvcRequestMatchers-Schwachstelle genauer zu untersuchen und herauszufinden, wo das Kernproblem liegt.

Spring bietet die RequestMatcher-Schnittstelle, um festzustellen, ob eine Anfrage mit einem Pfadmuster übereinstimmt. Schauen Sie sich den folgenden Codeausschnitt an, in dem die Hilfsmethode mvcMatchers verwendet wird, um die Endpunkte zusammen mit ihren Authentifizierungs- und Autorisierungsanforderungen zu registrieren. Zum Beispiel können wir sehen, dass nur Benutzer mit der Rolle ADMIN auf den Endpunkt /logs/audit zugreifen können. 

MvcMisMatchers?

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

Das *-Muster ist ein Muster, das mit jeder URL übereinstimmt und genau eine Ebene eines Unterverzeichnisses hat. Zum Beispiel würde /bankaccount/* auf bankaccount/dashboard passen .

Bei der Konfiguration der Matcher mit * stellt Spring fest, dass "eine Fehlanpassung beim Pattern-Matching zwischen Spring Security und Spr ing MVC" stattgefunden hat, wodurch die Schwachstelle entstand.

Da dem doppelten Platzhalter kein Trennzeichen vorangestellt ist, passt der Pfad nicht zu einer eingehenden Anfrage, da allen eingehenden Anfragen ein Schrägstrich vorangestellt wird. 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 auffälligste und wichtigste Änderung ist die Hinzufügung von Zeile 315, mit der die Umgehung der Autorisierungs- und Authentifizierungsregeln behoben wird. Sie stellt sicher, dass jedem Pfadmuster, das übermittelt wird, ein Schrägstrich (/) vorangestellt wird. 

404 Treffer nicht gefunden

PathPatternMatchableHandlerMapping-Klasse (Quelle : spring-framework)

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

Der Parser liest das erste Zeichen als SeparatorPathElement. Er setzt dann das Lesen der Zeichenfolgen bis zum nächsten Trennzeichen fort und erstellt ein neues LiteralPathElement.

Was läuft also schief, wenn ** als Muster verwendet wird? 

Es gibt zwar eine Vielzahl von Pfadelementtypen, aber die interessantesten sind das WildcardPathElementund das WildcardTheRestPathElement mit ihren jeweiligen Zeichenkettendarstellungen: * und /**. 

Ein WildcardPathElement stimmt mit null oder mehr Zeichen innerhalb eines einzelnen Pfadsegments überein, während ein WildcardTheRestPathElement mit null oder mehr Pfadsegmenten allein übereinstimmt (einschließlich der Trennzeichen).

Letzteres gibt uns einen Hinweis darauf, was falsch läuft, wenn ** als Muster eingegeben wird. Beim Parsen wird nach Mustern gesucht, aber ** beginnt nicht mit dem erwarteten Schrägstrich. Anstatt also ein WildcardTheRestPathElement zu werden, wird es zu zwei aufeinanderfolgenden WildcardPathElementen.

Anschließend wird das geparste Muster zum Abgleich mit der angeforderten URL verwendet. Es wird erwartet, dass Pfade mit einem Schrägstrich beginnen, aber ein Platzhalter passt nicht auf Trennzeichen.

Auszug aus WildCardPathElement.java

Dies bedeutet, dass anstelle eines RequestMatchResult ein Nullwert zurückgegeben wird. Folglich werden die Zugriffskontrollregeln, die diesem Abgleicher zugewiesen wurden, nicht auf die angeforderte URL angewendet.

Spring hat das Problem behoben, indem ein Schrägstrich vorangestellt wurde. Mit anderen Worten: Jedes **-Muster wird zu /**, d. h. es kann als WildcardTheRestPathElement geparst werden, und es wird ein RequestMatchResult zurückgegeben, da das Muster nun mit der angeforderten URL übereinstimmt.

Schwachstelle oder API-Missbrauch?

Es ist fraglich, ob dies als Schwachstelle betrachtet werden sollte, da der Code wie vorgesehen funktioniert. Das Problem liegt im Wesentlichen darin, dass in der Spring-Dokumentation nicht ausdrücklich erwähnt wird, dass Pfade mit einem Trennzeichen beginnen sollten. Daher könnte es eher als ein Fall von API-Missbrauch und nicht als ein Fehler oder eine Schwachstelle angesehen werden.

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Senden
Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.