Nl-portal-backend-libraries: Server-Side-Request-Forgery (SSRF) (CVE-2026-55414)

Zusammenfassung

Die öffentlichen GraphQL-Resolver getFormDefinitionByObjectenApiUrl(url) und der veraltete getFormDefinitionById(id) holen eine vom Aufrufer bereitgestellte URL mit dem privilegierten Objecten-API-Token ab. Da das /graphql-Endpunkt permitAll() ist und diese Resolver keinen CommonGroundAuthentication-Parameter deklarieren, kann ein unauthentifizierter Aufrufer den Backend dazu bringen, eine ausgehende Anfrage mit der Autorisierung Authorization: Token <objecten-api-token> an eine vom Aufrufer beeinflusste URL auf dem konfigurierten Objecten-API-Host zu senden. Dies ist ein eingeschränkter (gleicher Host) serverseitiger Anfragebetrug kombiniert mit fehlender Autorisierung.

Verantwortungsvoll gemeldet und in einer lokalen Laboreinrichtung gegen die eigene WebFlux-Sicherheitsstapel des Projekts bestätigt. Kein Produktions-System wurde zugänglich gemacht.

Betroffen

• nl.nl-portal:form (der öffentliche Resolver / Einstiegspunkt) zusammen mit nl.nl-portal:objectenapi (wo der Host-Schutz lebt).
• Erstmals in 1.1.0.RELEASE (2023-10-31) ausgeliefert; der anfällige Code wurde am 2023-08-12 (Commit b2f87ca) eingeführt und ist seitdem in jeder Version vorhanden (1.1.x, 1.2.5, 1.3.0, die 3.0.x-Linie und 3.1.0 / next-minor, HEAD 45abcd2). In der Version 3.0.4.RELEASE behoben (siehe Behebung unten).

Datenfluss (bestätigt im Quellcode)

1. form/.../graphql/FormDefinitionQuery.kt — @QueryMapping getFormDefinitionByObjectenApiUrl(@Argument url), kein CommonGroundAuthentication-Parameter (gleiches gilt für getFormDefinitionById).
2. → form/.../service/ObjectsApiFormDefinitionService.kt — die URL wird unvalidiert weitergegeben.
3. → zgw/objectenapi/.../service/ObjectenApiService.kt getObjectByUrl(url) — der einzige Schutz ist die Host-Gleichheit (URI.create(url).host == objectsApiClientConfig.url.host); keine Schemen-/Port-/Pfadprüfung.
4. → zgw/objectenapi/.../client/ObjectsApiClient.kt getObjectByUrl(url) über webClientWithoutBaseUrl(), das die Standardkopfzeile Authorization: Token <token> zur vollständig vom Aufrufer bereitgestellten URL anhängt.

Erreichbarkeit: /graphql ist permitAll() (core/.../security/OauthSecurityAutoConfiguration.kt). Die Authentifizierung wird nur auf Resolvers durchgesetzt, die einen CommonGroundAuthentication-Parameter deklarieren; diese tun es nicht, und es gibt kein @PreAuthorize/Instrumentationssicherheitsnetz. Die eigene GraphQLEndpointAuthorizationIT des Projekts listet getFormDefinitionByObjectenApiUrl als eine absichtlich öffentliche Operation auf — die unauthentifizierte Erreichbarkeit ist also beabsichtigt; der Defekt besteht darin, dass ein absichtlich-öffentlicher Resolver ein privilegiertes Token an eine vom Aufrufer beeinflusste URL weiterleitet.

Sekundär (Verteidigung in Tiefe): zgw/zaken-api/.../service/ZakenApiService.kt getZaakDetails ruft objectsApiClient.getObjectByUrl direkt auf, um den Dienst-Level-Host-Schutz zu umgehen. Es ist derzeit nur über das authentifizierte Feldresolver ZaakQuery.zaakdetails mit serverseitig abgeleiteten URLs erreichbar — also kein unauthentifizierter Vektor heute — zeigt aber, warum der Schutz im Client gehört.

Proof of Concept (Lab, gegen den realen WebFlux-Stapel)

• Ein unauthentifizierter POST /graphql Aufruf von getFormDefinitionByObjectenApiUrl(url: ...) wird ohne Authentifizierung ausgeführt.
• Mit dem konfigurierten Objecten-API-Host auf einem Mockserver, wurde eine ausgehende Anfrage an einen vom Aufrufer gewählten Port/Pfad dieses Hosts mit Authorization: Token <konfiguriertes-Token> gesendet — bestätigt, dass das Token zu vom Aufrufer beeinflussten URLs hinzugefügt wird.

Auswirkung und Schweregrad — wichtige Einschränkungen

Als Mittel bewertet wegen zweier Code-Level-Fakten, die den praktischen Einfluss einschränken:

1. Keine cross-host SSRF / Token-Exfiltration in Standardbereitstellungen. Das Token reist nur zum konfigurierten Objecten-API-Host. Die Exfiltration erfordert einen von Angreifern kontrollierten Listener an diesem Host (ein anderer Port/Pfad, der anderswo weitergeleitet wird) — generell nicht der Fall in verwalteten Bereitstellungen. Eine Reihe von URL-Parser-Ausweichlasten wurde getestet (Benutzerinfo @, %2f/%00/%09, Backslash, #/?, doppelter-Host, trailing-dot, IDN/Unicode full-stop, fraction-slash, IPv6); keine Parser-Differential wurde zwischen dem auf java.net.URI basierenden Schutz und dem Spring/Netty URI-Bauer von WebClient gefunden — jede Last entweder hielt die Anfrage am konfigurierten Host oder wurde abgelehnt (fail-closed). Das Lab-Token-Leak PoC funktioniert nur, weil der konfigurierte Host dort localhost ist; dies lässt sich nicht auf Produktion verallgemeinern.

2. Zufällige PII-Objekt-Lesung durch typisierte Deserialisierung blockiert. Die Antwort wird in ObjectsApiObject<ObjectsApiFormIoFormDefinition> deserialisiert, dessen Umschlagfelder und data.formDefinition alle nicht-null Kotlin-Eigenschaften sind (Jackson KotlinModule registriert). Ein Objekt ohne ein Top-Level data.formDefinition (z.B. taken/berichten/zaakdetails) kann nicht deserialisiert werden (DecodingException) und gibt keine Daten zurück. Der Resolver kann daher nur Objekte zurückgeben, die wie eine Form-Definition geformt sind — und Form-Definitionen sind absichtlich öffentlich (vor dem Login geladen).

Erhöhungskonditionen, die den Schweregrad in Richtung Hoch erhöhen würden:

• der Objecten-API-Host teilt sich Infrastruktur mit einem von Angreifern kontrollierbaren Endpunkt (anderer Port/Pfad), um das privilegierte Token abzufangen; oder
• ein URL-Parser-Differential wird später gefunden, das den Host-Schutz umgeht.

Behebung

• Den Host-Validierung aus ObjectenApiService.getObjectByUrl herausnehmen und in ObjectsApiClient.getObjectByUrl hineinlegen, damit auch der direkte Aufrufer ZakenApiService.getZaakDetails abgedeckt ist, und es von host-only auf Schemen + Host + Port + Pfadpräfix verschärfen. Am besten, kein vollständiger URL akzeptieren: UUID des Objekts validieren/ausziehen und die URL aus der fest konfigurierten Basis neu aufbauen (das bestehende Muster von ObjectsApiClient.getObjectById wiederverwenden, /api/v2/objects/{uuid}).
• Getrennt entscheiden, ob getFormDefinitionByObjectenApiUrl / getFormDefinitionById unauthentifiziert bleiben sollten. Sie sind derzeit absichtlich öffentlich (Formulare laden vor dem Login); für eine strengere Haltung einen CommonGroundAuthentication-Parameter wie in den anderen Resolvers hinzufügen — dabei beachten, dass dies das Vorab-Login-Formular-Laden unterbricht.

Anerkennung

Verantwortungsvoll gemeldet von Ray Sabee (https://whitehatsecurity.nl), unabhängiger Sicherheitsforscher — GitHub @raysabee.

Behebung

In der Version 3.0.4.RELEASE behoben (Commit 39ad80f, PR #700, "rework form module"):

• Die unauthentifizierten Resolvers getFormDefinitionByObjectenApiUrl und der veraltete `getFormDefinition