Spring-Security-Autorisierungsumgehung (CVE-2022-31692) im Fokus
16. Dezember 2022
0 Min. LesezeitAnfang November wurde eine neue Schwachstelle zur Umgehung der Autorisierung in Spring Security 5 entdeckt. Doch bevor wir in Panik geraten, sehen wir uns das Problem genauer an und prüfen, ob Sie betroffen sind. Obwohl die Schwachstelle als hoch eingestuft ist, sind nur bestimmte Anwendungsfälle betroffen. Das bedeutet, dass nicht alle gefährdet sind. Das zeige ich gleich. Unabhängig davon lautet die Empfehlung, auf eine neuere Version von Spring Security zu aktualisieren: Version 5.6.9 oder höher beziehungsweise 5.7.5 oder höher.
Was ist eine Autorisierungsumgehung?
Der Name sagt es eigentlich schon: Angenommen, es gibt eine Webseite in unserer Spring-Boot-Anwendung, auf die nur Benutzer zugreifen dürfen, denen die Admin-Rolle zugewiesen wurde. Bei einer Autorisierungsumgehung kann ein Benutzer ohne Admin-Rolle in bestimmten Fällen auf diese Seite zugreifen. Das ist natürlich unerwünscht und kann unter anderem zu Datenlecks sowie zum unbefugten Ändern, Erstellen oder Löschen von Daten führen.
Wie funktioniert diese Spring-Security-Autorisierungsumgehung?
Mit Spring Security lässt sich eine SecurityFilterChain erstellen, um Berechtigungen für bestimmte Endpunkte festzulegen. In neueren Spring-Versionen sieht das etwa so aus:
Im obigen Beispiel habe ich antMatchers verwendet, um Berechtigungen für URL-Muster unabhängig von der HTTP-Methode festzulegen. Alle haben Zugriff auf / und /forward. Nur Benutzer mit der Admin-Rolle dürfen auf die URL /admin zugreifen.
Bis hierhin ist alles gut. Nichts Besonderes, und es funktioniert einwandfrei. Sehen wir uns nun die Implementierung des Forward-Endpunkts in meinem Controller an.
In der obigen Implementierung leitet der Endpunkt forward die Anfrage an den Endpunkt admin weiter. Außerdem habe ich meiner Spring-Security-Konfiguration alle Dispatcher-Typen hinzugefügt, da standardmäßig nur request, async und error abgedeckt sind. Dazu habe ich die folgende Zeile in der Datei application.properties meiner Spring-Boot-Anwendung ergänzt.
Vielleicht nehmen Sie an, dass alles in Ordnung ist und der Endpunkt admin durch die Filter abgedeckt wird. Tatsächlich kann ich nun aber über /forward auf den Endpunkt admin zugreifen, ohne die Admin-Rolle zu haben oder mich überhaupt anzumelden. Obwohl wir forward ausdrücklich zu unserer Konfiguration hinzugefügt und shouldFilterAllDispatcherTypes() aktiviert haben, können wir weiterhin auf die Admin-Seite zugreifen. Durch die Verwendung von Forward und die Einbeziehung aller Dispatch-Typen lässt sich die Autorisierung umgehen und auf einen durch höhere Berechtigungen geschützten Endpunkt zugreifen.

Der Grund dafür: In Spring Security 5 werden Filter standardmäßig nicht mehrmals auf dieselbe Anfrage angewendet. Daher müssen Benutzer Spring Security ausdrücklich so konfigurieren. Außerdem ist der FilterChainProxy nicht dafür konfiguriert, bei den Dispatcher-Typen Forward und Include aufgerufen zu werden.
Das Problem tritt auch in älteren Versionen von Spring Security 5 auf.
Wenn Sie eine ältere Version einer Spring-Anwendung nutzen, haben Sie höchstwahrscheinlich auch eine ältere Version von Spring Security. Eine ältere Spring-Boot-Anwendung, die ich für Workshops betreue, basiert auf Version 2.2.0-RELEASE und enthält Spring Security 5.2.0-RELEASE. In diesen älteren Versionen musste die Sicherheit etwas anders konfiguriert werden. Dazu mussten wir eine Konfigurationsklasse erstellen, die das Interface WebSecurityConfigurerAdapter erweitert, und die Methode configure() überschreiben, um ähnliche Filter wie zuvor beschrieben zu implementieren.
Im obigen Beispiel haben wir eine ähnliche Schwachstelle wie zuvor nachgebildet. Im Grunde verwenden wir dieselbe Filterkette, in der das Problem auftritt.
Wie problematisch ist dieses Problem in Spring Security?
Wie immer kommt es darauf an, wie Sie es verwenden. Obwohl CVE-2022-31692 laut der National Vulnerability Database (NVD) einen Wert von 9,8 (kritisch) hat, stufen wir die Schwachstelle bei Snyk mit 7,4 etwas niedriger ein. Damit gilt sie als Schwachstelle mit hohem Schweregrad.
Obwohl sich die Schwachstelle relativ leicht ausnutzen lässt und weit verbreitet ist, sind nur bestimmte Anwendungsfälle tatsächlich betroffen. Wenn Sie auf die Dispatcher-Typen forward und include angewiesen sind und wie in den obigen Beispielen die AuthorizationFilters verwenden, könnten Sie betroffen sein. Wenn Sie bei diesen Dispatcher-Typen einen Endpunkt mit höherem Berechtigungsniveau aufrufen und den AuthorizationFilter zur Festlegung von Berechtigungen verwenden, kann es tatsächlich zu einer Autorisierungsumgehung kommen.
Das bedeutet, dass zahlreiche Voraussetzungen erfüllt sein müssen, bevor Sie von dieser Schwachstelle betroffen sind. Eine vollständige Liste finden Sie in unserem Advisory zu diesem Sicherheitsproblem in der Snyk Vulnerability Database.
So können Sie dieses Sicherheitsproblem abmildern
Am besten und einfachsten lässt sich das Problem beheben, indem Sie Ihre Spring-Security-Version auf 5.7.5 oder höher aktualisieren. Wenn Sie noch den Zweig 5.6.x verwenden, ist das Problem in 5.6.9 behoben. Wenn Sie mit einer Spring-Boot-Anwendung arbeiten, sollten Sie am besten auf Spring Boot Version 2.7.6 oder höher aktualisieren. Dadurch wird automatisch die richtige Spring-Security-Version eingebunden, sofern Sie Spring Security verwenden.
Wenn Sie nicht aktualisieren können, ändern Sie Ihre Filterdefinition von authorizeHttpRequests().shouldFilterAllDispatcherTypes(true) zu .authorizeRequests().filterSecurityInterceptorOncePerRequest(false). So wird sichergestellt, dass der Dispatcher-Typ Forward wie erwartet gefiltert wird.
Bei der Überarbeitung des ersten Beispiels in diesem Blogbeitrag sieht die Lösung so aus:
Auf ähnliche Weise können wir .filterSecurityInterceptorOncePerRequest(false) zur älteren Methode der Filterdefinition hinzufügen, bei der wir WebSecurityConfigurerAdapter erweitern mussten.
Halten Sie Ihre Abhängigkeiten auf dem neuesten Stand, um sicher zu bleiben
Dies zeigt einmal mehr, wie wichtig es ist, Ihre Abhängigkeiten auf dem neuesten Stand zu halten. Wenn eine Sicherheitslücke wie diese Ihre Anwendung betrifft und Ihre Abhängigkeiten veraltet sind, erfordert die Behebung der Situation deutlich mehr Aufwand. Mit SCA-Scans, etwa von Snyk Open Source, erhalten Sie diese Informationen und Empfehlungen zur Behebung, sobald sie verfügbar sind. Sie können Snyk kostenlos nutzen. Speziell für die Java-Entwicklung habe ich einen leicht verständlichen Artikel dazu geschrieben, wie Sie loslegen.
Starten Sie mit Capture-the-Flag
Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Challenges lösen.
