Tokens aus dem Browser entfernen mit dem BFF-Pattern

Bei der Handhabung von OAuth in einer Single-Page-Anwendung (SPA) stellt sich seit Langem die Frage, wo Access- und Refresh-Tokens gespeichert werden sollen. localStorage, sessionStorage und In-Memory-Variablen sind alle unzureichend gegenüber XSS. Das BFF-Muster (Backend for Frontend) ist ein Design, bei dem Tokens serverseitig gehalten werden, anstatt an den Browser weitergegeben zu werden. Dieser Artikel erläutert den Mechanismus und die wichtigsten Implementierungspunkte.

Voraussetzungen

Dieser Artikel setzt folgende Umgebung voraus:

• Entwicklung einer browserbasierten App unter Verwendung von OAuth 2.0 und OpenID Connect.
• Existenz einer SPA, der von ihr aufgerufenen APIs und eines Autorisierungsservers.
• Die SPA und ihre unterstützenden serverseitigen Komponenten können auf derselben übergeordneten Domain platziert werden.
• HTTPS ist eine Voraussetzung (erforderlich für die Ausstellung von Secure Cookies).

XSS-Risiken in browserbasierten Apps

Anwendungscode, der im Browser ausgeführt wird, ist anfällig für alles, was in der Ausführungsumgebung des Browsers geschieht. XSS hat weitreichende Auswirkungen, und da der Angriffscode im selben Kontext wie die App läuft, sind folgende Operationen möglich:

• Auslesen von Werten, die in localStorage oder sessionStorage gespeichert sind.
• Auslesen von In-Memory-Variablen, auf die von JavaScript aus zugegriffen werden kann.
• Ausführen aller API-Aufrufe, die die App durchführen kann.
• Ändern des Verhaltens durch Überschreiben von eingebauten Funktionen (Prototype Pollution).

Es gibt mehrere Einstiegspunkte für XSS, wie z. B. Schwachstellen in abhängigen Bibliotheken, Fehler in der Ein-/Ausgabeverarbeitung des eigenen Codes oder die Kompromittierung von Drittanbieter-Skripten. Da es schwierig ist, XSS vollständig zu verhindern, ist eine realistische Strategie, „die Auswirkungen im Falle eines Eindringens zu begrenzen".

Solange Tokens im Browser platziert sind, bleibt die Möglichkeit bestehen, dass Tokens über XSS gestohlen werden. Wenn ein Angreifer ein gestohlenes Refresh-Token in seiner eigenen Umgebung verwendet, kann er über einen langen Zeitraum APIs aufrufen, selbst nachdem der Benutzer die Website geschlossen hat. Token-Rotation und Leerlauf-Timeouts können die Auswirkungen zwar abmildern, sind aber keine grundlegenden Lösungen.

Design, das keine Tokens im Browser platziert

Das BFF-Muster stellt eine serverseitige Komponente bereit, die speziell für die SPA zuständig ist, und zentralisiert dort die OAuth-Client-Verantwortlichkeiten. Die SPA führt die OAuth-Verarbeitung nicht direkt durch, sondern führt Authentifizierung und API-Aufrufe über das BFF durch.

Die Aufteilung der Rollen ist wie folgt:

• OAuth-Protokollkommunikation mit dem Autorisierungsserver: Wird vom BFF übernommen.
• Halten von Access- und Refresh-Tokens: Nur das BFF.
• Aufrechterhalten des Authentifizierungsstatus zwischen SPA und BFF: HttpOnly Cookie.
• API-Aufrufe: Die SPA sendet Anfragen an das BFF, und das BFF wandelt das Cookie in ein Token um und leitet es an die API weiter.

In dieser Konfiguration zirkulieren Tokens nur zwischen dem BFF und den von ihm aufgerufenen APIs und sind für das JavaScript des Browsers unsichtbar. Selbst wenn XSS auftritt, kann ein Angreifer das Token nicht extrahieren und von anderer Stelle verwenden. Ein Angreifer kann lediglich Anfragen an das BFF im Rahmen der aktuell vom Benutzer geöffneten Sitzung senden. Diese Auswirkungen sind zwar nicht vernachlässigbar, aber die Dauer und der Umfang der Auswirkungen sind im Vergleich zum Token-Diebstahl erheblich eingeschränkt.

Das BFF fungiert als das, was die OAuth-Terminologie als „vertraulichen Client" bezeichnet. Es besitzt ein Client-Secret und führt den Austausch von Autorisierungscodes gegen Tokens sowie die Aktualisierungsverarbeitung vollständig serverseitig durch.

Authentifizierungsablauf

Ein typischer Authentifizierungsablauf sieht wie folgt aus:

1. Wenn die SPA eine Anmeldung startet, sendet sie eine Anmeldeanfrage an das BFF.
2. Das BFF startet einen Autorisierungscode-Ablauf mit PKCE, generiert eine Weiterleitungs-URL zum Autorisierungsserver und gibt sie an die SPA zurück.
3. Die SPA leitet den Browser zu dieser URL weiter, und der Benutzer authentifiziert sich am Autorisierungsserver.
4. Der Autorisierungsserver gibt einen Autorisierungscode an die Weiterleitungs-URI des BFF zurück.
5. Das BFF tauscht den Autorisierungscode gegen Tokens ein und erhält ein Access-Token und ein Refresh-Token.
6. Das BFF speichert die Tokens in seinem eigenen sicheren Bereich (verschlüsseltes Cookie, serverseitiger Sitzungsspeicher usw.) und gibt nur eine Sitzungskennung über ein HttpOnly Cookie an die SPA zurück.
7. Wenn die SPA eine API aufruft, sendet sie die Anfrage über das BFF. Das Cookie wird gleichzeitig gesendet, und das BFF wandelt es in ein Access-Token um und leitet es an die vorgelagerte API weiter.
8. Wenn das Access-Token abläuft, aktualisiert das BFF es stillschweigend mit dem Refresh-Token.

Aus Sicht der SPA wird der Anmeldestatus durch das Cookie aufrechterhalten, und API-Anfragen werden mit normalen fetch-Aufrufen abgeschlossen. Code, der direkt OAuth-Tokens oder Autorisierungscodes verarbeitet, existiert in der SPA nicht.

Erforderliche Sicherheitseinstellungen

Für das vom BFF ausgestellte Cookie müssen die folgenden Attribute gesetzt werden:

• HttpOnly: Verhindert den Zugriff von JavaScript aus. Selbst bei XSS können die Cookie-Inhalte nicht gelesen werden.
• Secure: Wird nur über HTTPS gesendet.
• SameSite=Strict: Stellt sicher, dass das Cookie nicht mit Anfragen von anderen Websites gesendet wird. Dies hilft, die meisten CSRF-Angriffspfade zu blockieren, aber der CSRF-Schutz ist damit allein nicht abgeschlossen.
• __Host-Präfix: Durch das Hinzufügen des __Host-Präfix zum Cookie-Namen wird sichergestellt, dass der Browser das Cookie auf die ausstellende Domain beschränkt und es nicht mit Subdomains teilt.

Wenn Tokens in einem verschlüsselten Cookie (clientseitige Sitzung) gespeichert werden, werden die Cookie-Inhalte verschlüsselt. Wenn Tokens in einem serverseitigen Sitzungsspeicher (serverseitige Sitzung) abgelegt werden, enthält das Cookie nur eine Sitzungskennung, sodass eine Verschlüsselung nicht erforderlich ist.

CSRF-Schutz sollte sich nicht allein auf SameSite verlassen

Da es sich um eine Cookie-basierte Authentifizierung handelt, muss das BFF einen Schutz gegen CSRF implementieren. SameSite=Strict ist ein sinnvoller Schritt, aber nicht die gesamte Lösung. Besondere Vorsicht ist bei Konfigurationen geboten, bei denen die SPA auf www.example.com und das BFF auf api.example.com platziert ist. Da die SameSite-Bestimmung pro Website und nicht pro Herkunft erfolgt, werden Anfragen von anderen Subdomains unter example.com als „Same-Site" betrachtet, und Cookies werden auch mit SameSite=Strict gesendet.

Verstärken Sie daher die CSRF-Abwehr mit einer der folgenden Methoden:

• Wenn sich BFF und SPA auf unterschiedlichen Ursprüngen befinden, verwenden Sie CORS und Origin-Header-Validierung zur Abwehr.
• Überprüfen Sie bei zustandsändernden Anfragen CSRF-Tokens mit der Anti-Forgery / Double-Submit-Cookie-Methode.

CORS auf exakte Ursprünge beschränken

CORS sollte nur für den exakten Ursprung der SPA zugelassen werden. Bei Berechtigungsanfragen mit Cookies erlauben Browser keine Platzhalter (*) in Access-Control-Allow-Origin. Daher muss das BFF den exakten Ursprung der SPA in der Antwort widerspiegeln. Diese strikte Beschränkung der erlaubten Ursprünge fungiert als Teil der CSRF-Abwehr.

Für die vom BFF gehaltenen Sitzungsdaten, insbesondere die in verschlüsselten Cookies gespeicherten Token-Informationen, ist ein Schlüsselmanagement erforderlich. Integrieren Sie Vorgänge, um Schlüssel sicher als BFF-Einstellungen zu injizieren und sie regelmäßig zu rotieren.

Beachten Sie, dass die Platzierung von SPA und BFF auf derselben übergeordneten Domain dazu dient, die Bedingung zu erfüllen, dass Same-Site-Cookies als First-Party-Cookies funktionieren.

Weiterentwicklung: API-gesteuertes BFF

Wenn ein BFF wie eine traditionelle Web-App aufgebaut ist, wird das serverseitige Rendern des BFF in die Seitenübergänge der SPA einbezogen. Ein API-gesteuertes BFF minimiert diese Auswirkungen.

Die Rollen werden in zwei Bereiche unterteilt:

• OAuth Agent: Eine API, die für die OAuth-Protokollverarbeitung verantwortlich ist. Sie wird von der SPA über JSON aufgerufen.
• OAuth Proxy: Funktioniert als API-Gateway-Plugin, extrahiert das Token aus dem Cookie und leitet es an die vorgelagerte API weiter.

In dieser Konfiguration ruft die SPA den OAuth Agent einfach als normale REST-API auf. Die Frontend-Entwicklungserfahrung der SPA kann nahezu identisch zu der vor der Einführung des BFF gehalten werden.

Überlegungen zur Einführung

Bei der Einführung des BFF-Musters sind folgende Punkte zu beachten:

• Zusätzliche Architekturkomponenten erhöhen die Entwicklungs- und Betriebskosten.
• Die SPA und das BFF müssen auf derselben übergeordneten Domain platziert werden.
• Eine Konfiguration, die lediglich den Authorization-Header über einen Reverse-Proxy weiterleitet, ist kein BFF. Das Wesen eines BFF besteht darin, das Token als vertraulicher Client zu halten.
• PKCE und BFF werden zusammen verwendet, nicht als Alternativen.
• Das BFF muss den Zielhost vor der Weiterleitung überprüfen, um eine Offenlegung des Tokens gegenüber unbeabsichtigten Hosts zu verhindern.
• Das Logout-Design wird komplex, da SPA-Sitzungen, BFF-Cookies und Autorisierungsserver-Sitzungen alle miteinander verknüpft werden müssen.

Zusammenfassung

Eine praktische Möglichkeit, Tokens in browserbasierten Apps sicher zu handhaben, besteht darin, sie nicht im Browser zu platzieren. Das BFF-Muster verlagert die OAuth-Client-Verantwortlichkeiten auf die Serverseite und gibt nur HttpOnly-Cookies an den Browser weiter. Dies verhindert Token-Diebstahl, selbst wenn XSS auftritt. Durch die Aufteilung der Rollen in OAuth Agent und OAuth Proxy kann die Sicherheit gestärkt werden, während die SPA-Entwicklungserfahrung erhalten bleibt.