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.
Am 20. März 2023 veröffentlichte Spring Security Advisories einen Blogbeitrag, in dem auf eine intern entdeckte Sicherheitslücke, CVE-2023-20860, verwiesen wurde. Es wurden keine detaillierten Informationen veröffentlicht, außer dass es sich um ein Problem mit der Zugriffskontrolle im Zusammenhang mit der Verwendung von `MVCMatchers` handelte. Die Spring-Entwickler haben das Problem behoben, und ein Versionsupdate wird empfohlen. Da Sicherheit unser Hauptaugenmerk bei Secure Code Warrior ist, haben wir uns entschlossen, uns eingehender mit dieser MVCRequestMatchers-Schwachstelle zu befassen und herauszufinden, wo das Kernproblem liegt.
Secure Code Warrior 소프트웨어 개발 주기 전반에 걸쳐 코드를 보호하고 사이버 보안을 최우선으로 하는 문화를 조성하도록 귀사를 Secure Code Warrior . 앱 보안 관리자, 개발자, 최고정보보안책임자(CISO) 또는 보안 관련 업무를 담당하는 분이라면 누구든, 저희는 귀사가 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기
Brysen ist Softwareentwickler bei Secure Code Warrior mit Schwerpunkt auf dem Schreiben von sicherem Code.
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.
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.
아래 링크를 클릭하여 이 자료의 PDF를 다운로드하십시오.
Secure Code Warrior 소프트웨어 개발 주기 전반에 걸쳐 코드를 보호하고 사이버 보안을 최우선으로 하는 문화를 조성하도록 귀사를 Secure Code Warrior . 앱 보안 관리자, 개발자, 최고정보보안책임자(CISO) 또는 보안 관련 업무를 담당하는 분이라면 누구든, 저희는 귀사가 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
보고서 보기데모 예약하기
Testing our mission, experience the effects own, and learn you can avoid to make a like error.
Probiere es jetzt ausBrysen ist Softwareentwickler bei Secure Code Warrior mit Schwerpunkt auf dem Schreiben von sicherem Code.
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.
%20(1).avif)
.avif)
