@angular/common: XSRF-Token-Offenlegung durch URL-Parsing-Diskrepanz im Angular HTTP-Client (Unvollständiger Fix für CVE-2025-66035)

Ein unvollständiger Fix für GHSA-58c5-g7wp-6w37 (CVE-2025-66035) im HTTP-Client von @angular/common (HttpClient) ermöglicht es, dass Cross-Site-Request-Forgery-Tokens (XSRF) an vom Angreifer kontrollierte Cross-Origin-Domains übertragen werden, wenn Anfragen URLs verwenden, die Parsing-Diskrepanzen zwischen regulären Ausdrücken und dem WHATWG-URL-Parser des Browsers ausnutzen.

Technische Beschreibung

Zur Behebung von CVE-2025-66035 führte xsrfInterceptorFn einen regulären Ausdruck (const ABSOLUTE_URL_REGEX = /^(?:https?:)?\/\//i) ein, um absolute und protokollrelative URLs zu erkennen und zu überspringen, bevor der X-XSRF-TOKEN-Header angehängt wird.

Browser lösen an fetch() und XMLHttpRequest.open() übergebene Request-URLs jedoch mithilfe des WHATWG-URL-Parsers auf. Für die Schemata http: und https: führt der WHATWG-URL-Standard vor der Auflösung von Authority/Origin mehrere Normalisierungen durch:

• Backslashes (\) werden wie Schrägstriche behandelt (/) — z. B. /\evil.example/x, \\evil.example/x, \/evil.example/x, https:\\evil.example/x, https:/\evil.example/x.
• Führende und nachfolgende C0-Steuerzeichen und Leerzeichen (<= 0x20) werden entfernt — z. B. ' //evil.example/x', '\0//evil.example/x', '\x1f//evil.example/x'.
• ASCII-Tabulator- (\t), Zeilenumbruch- (\n) und Wagenrücklaufzeichen (\r) werden überall in der Eingabe entfernt — z. B. '/\t/evil.example/x', '/\n/evil.example/x', 'htt\tps://evil.example/x'.

Da diese URLs nicht auf /^(?:https?:)?\/\//i matchen, behandelt xsrfInterceptorFn sie als relative Same-Origin-URLs und fügt den X-XSRF-TOKEN-Header an, während der Browser die Anfrage an den Cross-Origin-Host (evil.example) auflöst und versendet.

Hinweis: In Angular 21.0.3+ und 22.x wurde der reguläre Ausdruck in #65683 durch einen WHATWG-new URL(req.url, locationOrigin)-Origin-Vergleich ersetzt; diese waren bereits nicht betroffen. Der LTS-Zweig 20.3.x behielt den regulären Ausdruck jedoch bis 20.3.34 bei.

Auswirkungen

Das Abfließen des Tokens umgeht den integrierten XSRF-Schutz von Angular auf betroffenen Versionen, wodurch ein Angreifer den gültigen X-XSRF-TOKEN-Header des Nutzers abfangen kann, sofern sein Server die Anfrage und den benutzerdefinierten Header über CORS zulässt. Sobald das Token erlangt wurde, kann der Angreifer Cross-Site Request Forgery (CSRF)-Angriffe gegen die Sitzung des Opfers durchführen.

Angriffsvoraussetzungen

1. In der Angular-Anwendung des Opfers muss der XSRF-Schutz aktiviert sein (standardmäßig in HttpClient aktiviert).
2. Der Angreifer muss in der Lage sein, die Anwendung dazu zu bringen, eine zustandsverändernde HTTP-Anfrage (z. B. POST, PUT, DELETE, PATCH) an eine von ihm kontrollierte URL (wie /\attacker.example/api oder //attacker.example/api) zu senden.

Patches

Das Problem wird behoben, indem der Origin der Anfrage-URL mit dem Standardkonstruktor URL (new URL(req.url, locationOrigin)) geparst und mit dem aktuellen Origin der Anwendung verglichen wird.

• 21.0.3 (und alle 22.x-Releases)
• 20.3.34

Workarounds

Falls ein sofortiges Upgrade auf eine gepatchte Version nicht möglich ist:

• Validieren und normalisieren Sie ausgehende Anfrage-URLs mit new URL(url, window.location.origin) und verifizieren Sie parsedUrl.origin === window.location.origin, bevor dynamische URLs an verändernde HttpClient-Anfragen übergeben werden.
• Vermeiden Sie die Übergabe von nicht vertrauenswürdigen oder benutzergesteuerten URLs an verändernde HttpClient-Methoden.