StatusTypeRelevance

1. Kurzbeschreibung

Im OrganizationManager waren Methoden zur Erstellung und Löschung von Organisationen mit @PreAuthorize abgesichert, jedoch wurde hasRole(...) verwendet, während die über JWT bereitgestellten Berechtigungen als Authorities und nicht als Spring Security Roles vorliegen.
Da hasRole() intern den Präfix ROLE_ erwartet, führte dies zu einer fehlerhaften Berechtigungsprüfung. Die erwarteten Berechtigungen (org_create_permission, superuser etc.) wurden dadurch nicht korrekt ausgewertet.
Zusätzlich war Method Security in der Anwendung nicht explizit aktiviert. Dadurch wurden die @PreAuthorize Annotationen nicht zuverlässig durchgesetzt.
Die Kombination aus beiden Problemen führte zu einer defekten Zugriffskontrolle auf Organization CRUD Operationen.

2. Bewertung

  • Risiko:
    Mittel bis Hoch (abhängig von der tatsächlichen Durchsetzung der Security-Konfiguration zur Laufzeit)

  • Angriffsvektor:
    Authentifizierter Benutzer sendet Requests auf geschützte Organization-CRUD-Endpunkte ohne die eigentlich erforderliche Berechtigung.

  • Auswirkung:
    Potenziell unautorisierte Operationen auf Organisationsressourcen:

    • Erstellung von Organisationen
    • Löschen von Organisationen
    • Manipulation von Organisationskontexten
  • Realistische Bedrohung im Kontext unserer Architektur:

    Die Anwendung nutzt JWT-basierte Authentifizierung mit Authority-Mapping. Da hasRole() intern ROLE_ erwartet, während unsere Tokens nur Authorities enthalten, konnte die Zugriffskontrolle fehlschlagen.

    Ohne aktivierte Method Security wurden @PreAuthorize Annotationen teilweise nicht angewendet.

    Ein authentifizierter Nutzer hätte dadurch unter Umständen Operationen ausführen können, für die er keine Berechtigung besitzt.

    Die tatsächliche Ausnutzbarkeit hängt davon ab:

    • ob Security global korrekt aktiviert war
    • ob zusätzliche Gateway/Service-Schutzmechanismen existieren
    • ob Tokens Authorities korrekt enthalten

    Insgesamt handelt es sich um eine Broken Access Control durch Fehlkonfiguration von Spring Security Method Authorization.

3. Lösung

1. Aktivierung von Method Security

@EnableMethodSecurity

in der Hauptanwendung:

OrganizationManagerApplication

Dadurch werden @PreAuthorize Annotationen zuverlässig durch Spring Security ausgewertet.

2. Korrekte Verwendung von Authorities

Die Annotationen wurden angepasst:

@PreAuthorize("hasAuthority('" + AuthHelper.ORG_CREATE_PERMISSION_ROLE + "')")

statt:

@PreAuthorize("hasRole(...)")

Dadurch entspricht die Berechtigungsprüfung nun dem Authority-Modell der
JWT-Tokens.

3. Erweiterung der Tests

Neue Tests prüfen explizit:

  • Zugriff ohne Authority → Forbidden
  • Zugriff mit korrekter Authority → OK

Beispiel:

.with(jwt().authorities(() -> AuthHelper.ORG_CREATE_PERMISSION_ROLE))

Dadurch wird sichergestellt, dass die Zugriffskontrolle korrekt funktioniert.

4. Notizen

  • Der Fehler entstand durch eine Mismatch zwischen Spring Role-Modell und JWT Authority-Modell.
  • hasRole() ist nur korrekt, wenn Authorities mit ROLE_ Präfix geliefert werden.
  • Unsere Tokens liefern jedoch Authorities ohne ROLE-Präfix, daher muss hasAuthority() verwendet werden.

Folgeabhängigkeiten:

  • Andere Services sollten überprüft werden, ob ebenfalls hasRole() statt hasAuthority() verwendet wird.
  • Gateway / API-Security sollte konsistent dieselben Authority-Namen verwenden.