@angular/platform-server: Open Redirect über protokollrelative URLs im Server-Side Rendering (SSR)

In @angular/platform-server wurde eine Open-Redirect-Schwachstelle festgestellt, wenn Server-Side Rendering (SSR) aktiviert ist.

Wenn Angular-SSR eine eingehende Anfrage rendert, werden URL-Auflösung und Plattform-Navigation von ServerPlatformLocation mittels resolveUrl (oder parseUrl in v20) verwaltet. Zwar wies resolveUrl protokollrelative URLs ab, deren Roh-String direkt mit // begann, diese Prüfung fand jedoch vor der WHATWG-URL-Normalisierung statt.

Wenn eine Anfrage-URL ein auflösendes Dot-Segment gefolgt von mehreren Schrägstrichen enthält (wie /.//evil.test oder serialisiert aus Router-Routenformen wie /.;/(//evil.test)), umging die Eingabe die anfängliche Prüfung auf urlStr.startsWith('//'). Das anschließende WHATWG-URL-Parsing löste die Dot-Segmente auf und führte zu einem pathname, der mit // (//evil.test) begann.

Folglich speicherte ServerPlatformLocation den Wert pathname = '//evil.test'. Wenn @angular/ssr eine Diskrepanz zwischen der gerenderten URL und dem finalen Location-Zustand des Routers erkannte, wurde der unnormalisierte Pfadname im HTTP-Header Location ausgegeben, was zu einer HTTP-302-Weiterleitung mit Location: //evil.test führte, die Browser als protokollrelative Navigation außerhalb der Origin auflösen.

Auswirkungen

Eine erfolgreiche Ausnutzung ermöglicht es einem nicht authentifizierten Remote-Angreifer, URLs zu konstruieren, die Angular-SSR dazu verleiten, Benutzer auf eine beliebige externe Domäne umzuleiten.

• Umgeht Guards auf Anwendungsebene: Typische Validierungsroutinen auf Anwendungsebene (wie die Überprüfung von !returnUrl.startsWith('//') vor dem Aufruf von router.navigateByUrl) stufen /.//evil.test oder /.;/(//evil.test) als sicheren relativen Pfad ein, wodurch Angreifer Weiterleitungs-Allowlists umgehen können.
• Clientseitige SPAs nicht betroffen: Reine clientseitige Angular-Anwendungen (Single Page Applications ohne SSR) sind nicht verwundbar, da ServerPlatformLocation ausschließlich in serverseitigen Ausführungsumgebungen verwendet wird.

Voraussetzungen für Angriffe & verwundbare Konfigurationen

Eine Anwendung ist betroffen, wenn die folgenden Bedingungen erfüllt sind:

• SSR aktiviert: Die Anwendung läuft in einer Server-Side-Rendering-Umgebung unter Verwendung von @angular/platform-server und @angular/ssr.
• Parameter-Routenformen: Der Router enthält Parameter-Routen mit Wildcard- oder untergeordneten Segmenten (z. B. /:tenant, das auf . passt und sekundäre Outlet-Gruppen (//evil.test) zu /.//evil.test serialisiert), oder übergibt vom Benutzer bereitgestellte Navigationsziele (z. B. returnUrl).
• Weiterleitung durch Reverse-Proxies: Upstream-Reverse-Proxies (Nginx, Cloudflare, ALB) leiten Semikolons (;) oder Dot-Segmente weiter, ohne diese zu entfernen oder zu normalisieren.

Beispiel-Exploit-Payload

Ein Angreifer sendet eine Anfrage an eine Route mit Parametern und untergeordneten Segmenten:

GET /.;/(//evil.test) HTTP/1.1
Host: example.com

Antwort:

HTTP/1.1 302 Found
Location: //evil.test

Der Client-Browser löst //evil.test protokollrelativ auf und leitet den Benutzer von example.com nach evil.test weiter.

Patches

Das Problem wird behoben, indem resolveUrl (und parseUrl in v20) in @angular/platform-server aktualisiert werden, um zu überprüfen, dass der normalisierte URL-Pfadname nicht mit // beginnt, wenn allowProtocolRelative den Wert false hat.

• 22.2.1
• 21.2.25
• 20.3.33

Workarounds & Mitigierungsmaßnahmen

Wenn ein sofortiges Upgrade auf eine gepatchte Version nicht möglich ist, können die folgenden Maßnahmen am Edge-Reverse-Proxy oder an der WAF implementiert werden:

1. Pfade mit Dot-Segmenten gefolgt von Schrägstrichen abweisen: Konfigurieren Sie Ihren Reverse-Proxy (z. B. Nginx, Cloudflare, AWS WAF) so, dass Anfragen blockiert werden, die /.//, /..// oder /.;/ enthalten:
   nginx

   # Nginx example: reject suspicious path normalization sequences
   if ($request_uri ~* "(\n/\.\/|\/\.\;)") {
       return 400;
   }

2. Weiterleitungs-Header bereinigen: Stellen Sie sicher, dass Edge-Proxies oder API-Gateways protokollrelative (//) Location-Antwort-Header, die vom SSR-Upstream stammen, umschreiben oder ablehnen.