Eine kritische Analyse der Aktualisierungstoken-Rotation in Single-Page-Anwendungen

Moderne Webanwendungen werden normalerweise als Single-Page-Anwendungen (SPAs) implementiert. Dabei kommen Technologien wie beispielsweise Angular, React oder Vue zum Einsatz. Eine Single-Page-Anwendung liegt als HTML-, CSS- und JavaScript-Code vor und wird im Browser des Benutzers ausgeführt.

Nach der ursprünglichen OAuth 2.0-Spezifikation war die Verwendung des Implicit Flows eine Voraussetzung für Frontend-Webanwendungen. Der im März 2019 veröffentlichte Internet-Draft OAuth 2.0 Security Best Current Practice sprach sich gegen die Verwendung des Implicit Flows zugunsten des Authorisierungscode-Flows mit PKCE (Proof Key for Code Exchange) aus. Ohne auf weitere Einzelheiten einzugehen, lässt sich sagen, dass Frontend-Webanwendungen seitdem einen Autorisierungscode-Flow verwenden und Aktualisierungstoken erhalten können.

Gar nicht schlecht, oder?
 

Nun ja, es gibt allerdings ein paar Sicherheitsaspekte, die bei der Nutzung von Aktualisierungstoken im Browser zu beachten sind. In diesem Artikel befassen wir uns mit den Sicherheitsmerkmalen von Aktualisierungstoken im Browser. Wir untersuchen, warum für Frontend-Webanwendungen eine Aktualisierungstoken-Rotation nötig ist und welche Vorteile dies bietet. Anschließend betrachten wir konkrete Angriffsszenarien, die Rotation von Aktualisierungstoken umgehen, und befassen uns damit, wie die Token bei sensiblen SPAs mit einem Backend-für-Frontend abgesichert werden sollten.

Als Erstes nehmen wir die Aktualisierungstoken im Browser unter die Lupe.

Bei Verwendung eines Autorisierungscode-Flows mit PKCE kann eine Frontend-Webanwendung Identitäts-, Zugriffs- und Aktualisierungstoken anfordern. Mit einem Aktualisierungstoken kann die Frontend-Anwendung schnell neue Zugriffstoken erhalten. Dadurch kann der Autorisierungsserver die Lebensdauer von Zugriffstoken auf fünf oder zehn Minuten reduzieren. Auf diese Weise wird die Gefahr des Missbrauchs von gestohlenen Zugriffstoken verringert.

Andererseits sind Frontend-Webanwendungen öffentliche Clients und infolgedessen nicht in der Lage, die Anmeldeinformationen von Clients zu verwalten. Diese Clients können sich daher während eines OAuth 2.0-Flows nicht gegenüber dem Autorisierungsserver authentifizieren. Diese Einschränkung wirkt sich auf die Sicherheit des Codeaustauschs aus, bei dem ein Client einen Autorisierungscode gegen Token eintauscht. Ohne Client-Authentifizierung kann nicht für die Legitimität des Clients garantiert werden, der den Autorisierungscode eintauscht.

Hierbei stehen mobile und native Anwendungen vor dem selben Problem. Für diese Clients führen die OAuth 2.0-Spezifikationen ein Konzept ein, das als PKCE (Proof Key for Code Exchange) bekannt ist. Kurz gesagt sorgt PKCE dafür, dass ausschließlich der Client, der einen Autorisierungscode-Flow initialisiert, auch den Autorisierungscode mit dem Autorisierungsserver austauschen kann.

Dieser PKCE-Mechanismus wurde ursprünglich für mobile Anwendungen entwickelt und funktioniert auch bei browserbasierten Anwendungen. Durch die Verwendung von PKCE kann eine browserbasierte Anwendung die Integrität des Code-Austauschs im Autorisierungscode-Flow sicherstellen und andere Angriffe, wie z. B. Code-Injektion, vermeiden.

Was hat das mit dem Aktualisierungstoken-Flow zu tun? Bei der Verwendung eines Aktualisierungstokens müssen sich auch vertrauliche Clients authentifizieren. Öffentliche Clients, wie z. B. browserbasierte Anwendungen, authentifizieren sich nicht während des Aktualisierungstoken-Flows. In einer typischen Frontend-Anwendung sind die an Frontend-Webanwendungen ausgegebenen Aktualisierungstoken daher Inhaber-Token.

In der Praxis bedeutet dies, dass ein Angreifer, dem es gelingt, einen Aktualisierungstoken von einer Frontend-Anwendung zu stehlen, diesen Token in einem Aktualisierungstoken-Flow verwenden kann. Um solche Angriffe abzuwehren, schreiben die OAuth 2.0-Spezifikationen vor, dass browserbasierte Anwendungen eine Sicherheitsmaßnahme anwenden, die Aktualisierungstoken-Rotation.

Bevor wir die Aktualisierungstoken-Rotation ausführlicher erklären, wollen wir auf die häufigste Bedrohung für Frontend-Webanwendungen eingehen.

Frontend-Webanwendungen werden mit HTML und JavaScript erstellt und im Browser des Benutzers ausgeführt. Diese Frontend-Anwendung arbeitet als autonome OAuth 2.0-Client-Anwendung und ist nicht auf eine Backend-Komponente angewiesen. Dank dieses Musters erhalten Frontend-Anwendungen mit Zugriffstoken direkt Zugang zu APIs. Dies bedeutet leider auch, dass die Speicherung und Verwaltung von Zugriffs- und Aktualisierungstoken allein von der Frontend-Anwendung übernommen wird.

Eine der größten Herausforderungen bei der Absicherung von Frontend-Webanwendungen besteht darin, die Ausführung von bösartigem JavaScript-Code zu verhindern. Das Ausführen von bösartigem Code im Kontext einer Frontend-Anwendung ermöglicht dem Angreifer das Manipulieren der Anwendung. Eine häufige Folge eines solchen Angriffs ist der Diebstahl von Token vom Kunden. Da es sich sowohl bei den Zugriffstoken als auch bei den Aktualisierungstoken um Inhaber-Token handelt, kann nichts den Angreifer daran hindern, diese gestohlenen Token zu missbrauchen.

Wie gelangt bösartiger JavaScript-Code in eine Frontend-Anwendung?

Leider gibt es zahlreiche Angriffsvektoren, die zur Ausführung von bösartigem Code in einer Frontend-Anwendung führen können. Ein Angriff ist als Cross-Site-Scripting (XSS) bekannt. Bei einem solchen Angriff kann der Angreifer die Anwendung mit schädlichen Daten versehen, die dann im Browser des Benutzers angezeigt werden (z. B. eine Restaurantbewertung eines anderen Benutzers). Wenn die Anwendung die Daten auf unsichere Weise wiedergibt, kann eine in böser Absicht erstellte Restaurantbewertung zur Ausführung von JavaScript-Code führen. Über diese Sicherheitslücke kann der Angreifer einen Code einschleusen, der Token aus dem Browser des Benutzers extrahiert.

Ein anderer Angriffsvektor basiert auf dem Einbinden von Inhalts- oder Codedateien über eine Remote-Verbindung. Viele moderne Anwendungen laden JavaScript-Bibliotheken aus Content Delivery Networks (CDNs), Dienste von Drittanbietern (durch das Einbinden einer JavaScript-Datei) und Anzeigen von Werbeanbietern. Wenn der Angreifer diese aus der Ferne eingebundenen Inhalte kompromittiert, wird schädlicher Code in der Anwendung des Opfers ausgeführt. Durch diese Kompromittierung aus der Ferne verschafft sich der Angreifer Zutritt zur Anwendung. Diese Art von Angriffen findet häufig Anwendung beim Einschleusen von Malware zum Abschöpfen von Kreditkartendaten.

Ein dritter Angriffsvektor basiert auf der Art und Weise, wie moderne Anwendungen entwickelt werden. Nahezu jede Webanwendung ist auf Module und Bibliotheken von Drittanbietern angewiesen, die aus Verzeichnissen wie beispielsweise der NPM Registry geladen werden. Wenn eine dieser Abhängigkeiten Schadcode enthält, wird dieser in das Anwendungsbündel aufgenommen. Es gibt beängstigende Berichte von gezielten Angriffen auf Anwendungen durch spezifische NPM-Module.

Abgesehen von den spezifischen Einzelheiten haben alle diese Angriffsvektoren eines gemeinsam: Ein erfolgreicher Angriff führt zur Ausführung von einem bösartigen Code im Browser des Benutzers. Schlimmer noch – er wird im Ausführungskontext der Anwendung ausgeführt. Der Browser kann keinen Unterschied zwischen dem Schadcode und dem legitimen Anwendungscode erkennen. Infolgedessen hat er den gleichen Handlungsspielraum wie auch die legitime Anwendung.

Im Hinblick auf OAuth 2.0 und die Aktualisierungstoken wird dabei eine Schwäche beleuchtet: Sobald ein Schadcode in eine Anwendung eingeschleust wurde, kann dieser die Token einer Anwendung lesen und extrahieren. Da es sich bei Aktualisierungstoken um Inhaber-Token handelt, ist das Vorhandensein von einem Schadcode äußerst problematisch.

Der Diebstahl von Token ist eine bekannte Bedrohung in der OAuth-Welt. Folglich berücksichtigen die OAuth 2.0-Spezifikationen die Gefahr von Inhaber-Aktualisierungstoken in Frontend-Webanwendungen. Diese OAuth 2.0-Spezifikationen fordern zusätzliche Sicherheitsmaßnahmen für Aktualisierungstoken in öffentlichen Clients, um dieses Problem zu entschärfen.

Eine Möglichkeit ist die Verwendung von Sender-Constrained-Token. Diese Token sind an ein Geheimnis geknüpft, das nur dem Client bekannt ist. Bei Verwendung von einem Token dieser Art muss der Absender den Besitz des Geheimnisses nachweisen. Ohne einen solchen Nachweis wird der Empfänger den Token ablehnen. Als Beispiel kann ein öffentlicher Client dienen, der auf einem mobilen Gerät läuft. Ein solcher Client kann eine mTLS-Authentifizierung verwenden, bei der das Geheimnis sicher auf dem Gerät gespeichert ist. Ein zweites Beispiel ist die Verwendung von DPoP bzw. Demonstration of Proof-of-Possession. DPoP ist ein Mechanismus auf Anwendungsebene und befindet sich noch im Versuchsstadium.

Die zweite Möglichkeit ist die Verwendung der „Aktualisierungstoken-Rotation“. Da Frontend-Webanwendungen nicht ohne Weiteres Sender-Constrained-Token verwenden können, wird für Frontend-Anwendungen eine Aktualisierungstoken-Rotation empfohlen. Wenn für einen Client die Rotation der Aktualisierungstoken aktiviert ist, können diese nur einmal verwendet werden. Jedes Mal, wenn der Client ein Aktualisierungstoken einsetzt, stellt der Autorisierungsserver einen neuen Zugriffstoken und einen neuen Aktualisierungstoken aus. Wenn der Client einen weiteren Aktualisierungstoken-Flow ausführen möchte, verwendet er das zuletzt ausgestellte Aktualisierungstoken. Das nachstehende Ablaufschema veranschaulicht dieses Konzept:

Wenn ein Client einen Aktualisierungstoken verwendet, erhält er immer ein neues für das nächste Mal. Folglich werden die Aktualisierungstoken nur ein einziges Mal verwendet.

Wenn ein Angreifer jedoch schädlichen JavaScript-Code verwendet, um den Aktualisierungstoken eines Clients zu stehlen, passiert etwas Interessantes. Die Client-Anwendung bemerkt den Diebstahl des Aktualisierungstokens nicht und verwendet ihn daher weiterhin, um neue Zugriffstoken (und Aktualisierungstoken) zu erhalten. Der Angreifer, der einen Aktualisierungstoken gestohlen hat, ist auch auf einen neuen Zugriffstoken (mit Aktualisierungstoken) aus. Infolgedessen verwendet entweder der Angreifer oder die Client-Anwendung den Aktualisierungstoken ein zweites Mal, wie in den folgenden Ablaufschemata dargestellt:

In diesen Szenarien löst die Wiederverwendung eines Aktualisierungstokens beim Autorisierungsserver alle möglichen Alarme aus. Die Wiederverwendung von Aktualisierungstoken ist ein Hinweis auf die wahrscheinliche Nutzung eines gestohlenen Aktualisierungstokens durch eine zweite Partei. Als Reaktion auf diese Wiederverwendung widerruft der Autorisierungsserver sofort den wiederverwendeten Aktualisierungstoken gemeinsam mit allen abhängigen Token. Kurz gesagt werden damit alle Aktualisierungstoken ungültig, die jemals von dem wiederverwendeten Aktualisierungstoken abgeleitet wurden.

Diese Maßnahme erscheint drastisch, verhindert aber wirkungsvoll den weiteren Missbrauch gestohlener Token. Die Rotation von Aktualisierungstoken in Kombination mit der Erkennung der Wiederverwendung erhöht die Sicherheit von Inhaber-Aktualisierungstoken erheblich.

Ist dies ausreichend für die Absicherung von Token im Browser?

Bevor wir auf konkrete Angriffsszenarien eingehen, sollten wir uns noch einmal mit den Möglichkeiten befassen, die den Angreifern zur Verfügung stehen. Wenn der Angreifer schädlichen JavaScript-Code in eine Anwendung einschleust, wird dieser Code im Browser des Benutzers ausgeführt. Dieser Code ist nicht von legitimem Anwendungscode zu unterscheiden und hat die gleichen Berechtigungen wie die legitime Anwendung.

Ein einfaches Angriffsszenario wäre der Diebstahl vorhandener Token direkt aus der Anwendung. Das deckt sich mit dem Szenario, das wir oben besprochen haben und das durch die Rotation der Aktualisierungstoken behoben werden soll. Welche weiteren Optionen haben Angreifer?

Im Folgenden werden drei konkrete Angriffsszenarien erörtert, mit denen die Rotation der Aktualisierungstoken ausgehebelt oder umgangen werden kann. Die nachstehenden Szenarien können von jedem Angreifer provoziert werden, der in der Lage ist, schädlichen JavaScript-Code im Ausführungskontext einer Anwendung auszuführen.
 

Szenario 1: Diebstahl von Zugriffstoken

Es wird häufig fälschlicherweise angenommen, ein schädlicher JavaScript-Code könne nur eine einzige Operation ausführen. Nichts hindert den Angreifer daran, einen permanenten Listener zu installieren, um den Client dabei zu überwachen, wenn er einen neuen Zugriffstoken erhält. Ein solcher Listener kann problemlos jeden Zugriffstoken extrahieren, den die Anwendung erhält. Dieses Szenario ist in der nachstehenden Abbildung dargestellt:

Bei diesem Szenario handelt es sich um einen Online-Angriff, bei dem der Zugriff des Angreifers mit dem Schließen der Client-Anwendung durch den Benutzer verschwindet.
 

Szenario 2: Umgehen der Aktualisierungstoken-Rotation

Wie im vorherigen Szenario kann der Angreifer einen Listener installieren, um Aktualisierungstoken aus der Anwendung zu extrahieren. Solange der Angreifer die gestohlenen Aktualisierungstoken nicht verwendet, wird der Erkennungsmechanismus des Autorisierungsservers nicht ausgelöst. Der Angreifer extrahiert nicht nur Aktualisierungstoken, sondern überwacht auch die Aktivitäten der Client-Anwendungen.

Sobald der Angreifer feststellt, dass der Client inaktiv geworden ist, verwendet er den letzten Aktualisierungstoken, um neue Token zu erhalten. Auf diese Weise wird eine Entdeckung durch den Autorisierungsserver vermieden, da der legitime Client nicht mehr aktiv ist. Aus der Sicht des Autorisierungsservers ist kein bösartiges Verhalten zu erkennen. Die nachstehende Abbildung veranschaulicht dieses Szenario:

Beachten Sie bei diesem Szenario, dass der Angreifer so lange Zugriff im Namen des Benutzers erhält, bis die Lebensdauer der Aktualisierungstoken-Kette abgelaufen ist. Dies dauert je nach Anwendung nicht selten bis zu 8 oder 12 Stunden.
 

Szenario 3: Vortäuschen des legitimen Clients

Anstatt etwas von der legitimen Anwendung zu stehlen, kann sich der Angreifer einfach als die Anwendung selbst ausgeben. Der Schadcode kann jeden Vorgang ausführen, zu der auch die legitime Anwendung fähig ist. Dementsprechend kann er auch auf die gleiche Weise Anfragen an eine API senden. Diese Anfragen übermitteln, ebenso wie die Anfragen der legitimen Anwendung, gültige Zugriffstoken. Im Grunde genommen kann der Angreifer beliebige API-Aufrufe über die legitime Anwendung tätigen.

Diese Methode ist kein neuartiger Angriffsvektor. Traditionelle sitzungsbasierte Webanwendungen leiden unter einem ähnlichen Problem, dem so genannten „Session Riding“ (Einklinken in eine bestehende Sitzung).
 

Szenario 4: Unbemerktes Anfordern neuer Token

Das letzte Szenario ist das gefährlichste. Anstatt die Token der Anwendung zu extrahieren oder sich als die legitime Client-Anwendung auszugeben, kann der Angreifer einen neuen OAuth 2.0-Flow ausführen. Der neue Flow wird in einem versteckten Iframe ausgeführt und bleibt für den Benutzer völlig unsichtbar. So verschleiert, wird der Flow in dem Iframe folgendermaßen konfiguriert:

• Die Client-Kennung bezieht sich auf die berechtigte Client-Anwendung.

• Der Prompt-Parameter ist auf "none" gesetzt, um eine Interaktion mit dem Benutzer zu vermeiden.

• Der Parameter "response_mode" wird auf "web_message" gesetzt, damit das Iframe-Element den Autorisierungscode an den Haupt-Browserkontext sendet.

Ein Flow dieser Art kann dann erfolgreich ausgeführt werden, wenn sich der Benutzer in einer authentifizierten Sitzung mit dem Autorisierungsserver befindet. Da Frontend-Clients in der Regel verlangen, dass sich ein Benutzer beim Starten der Anwendung anmeldet, ist es sehr wahrscheinlich, dass eine solche Sitzung aktiv ist.

Durch die Ausführung eines derartig verschleierten Flows in einem Iframe gelangt der Angreifer an einen Satz von Token. Diese wiederum sind unabhängig von den Token, die der legitime Client bereits verwendet. Demzufolge wird auch kein Aktualisierungstoken jemals wiederverwendet und der Angriff bleibt für den Autorisierungsserver nicht feststellbar. Die nachstehende Abbildung veranschaulicht dieses Szenario:

Beachten Sie, dass ein Angreifer in diesem Szenario sogar die fortschrittlichsten Sicherheitsmechanismen umgehen kann, z.B. die Demonstration des Proof-of-Possession (DPoP) auf der Anwendungsebene. Denken Sie auch daran, dass in diesem Szenario der Angreifer im Namen des Benutzers vollen Zugriff erhält, solange der Aktualisierungstoken gültig ist. Dies dauert je nach Anwendung nicht selten bis zu 8 oder 12 Stunden.

Leider hat sich gezeigt, dass Frontend-Webanwendungen schwer abzusichern sind. Das Cross-Site-Scripting (XSS; dt.: Webseitenübergreifendes Skripting) ist jetzt schon seit fast zwei Jahrzehnten eine Plage für Webanwendungen. Mit den aktuellen JavaScript-Frameworks ist es zwar ein bisschen besser geworden, aber es gibt immer noch viele potenzielle XSS-Angriffsvektoren in modernen Anwendungen. Auf dieser Checkliste finden Sie weitere Informationen über die Sicherung von React- und Angular-Anwendungen.

War das dann alles? Nun, ja und nein! 

Vom Sicherheitsstandpunkt aus gesehen, ist es praktisch unmöglich, Token in einer Frontend-Webanwendung abzusichern. Ein schädlicher JavaScript-Code hat die gleiche Handhabe wie auch die Anwendung selbst. Wenn also die Anwendung auf Token zugreifen kann, kann der Schadcode das ebenfalls. Sicherheitsmuster, wie das Verstecken von Aktualisierungstoken in einem Web Worker, können hilfreich sein, sind aber auf Dauer keine Lösung für die zuvor diskutierten Szenarien.

Nicht sensible Frontend-Anwendungen können sich konkret auf Aktualisierungstoken mit einer Aktualisierungstoken-Rotation verlassen. Eine Anwendung für Restaurantbewertungen kann als nicht sensibel gelten, was die Wirkung eines erfolgreichen XSS-Angriffs verringert. Bei sensiblen Anwendungen ist dies nicht zu empfehlen. Äußerst sensibel sind beispielsweise Anwendungen, die personenbezogene Informationen, Daten aus dem Gesundheitswesen oder Finanzvorgänge verarbeiten. Bei solchen Anwendungen hat ein erfolgreicher XSS-Angriff erhebliche Auswirkungen.

Deshalb sollten sensible Frontend-Anwendungen nicht mit Token im Browser arbeiten. Sie können stattdessen auf ein BFF-Muster (Backend für Frontend) zurückgreifen, bei dem die Verarbeitung von Token auf eine minimalistische serverseitige Komponente verlagert wird. Die nachstehende Abbildung veranschaulicht das Konzept eines BFF-Musters:

BFFs werden traditionell dazu verwendet, verschiedene APIs zu einer einzigen kohärenten API zusammenzufassen, um eine Client-Anwendung zu bedienen. In unserem Szenario übernimmt das BFF-Muster außerdem eine geringe Sicherheitsfunktion. Es nimmt Anfragen von der Client-Anwendung entgegen, ergänzt sie mit OAuth 2.0-Zugriffstoken und leitet die Anfrage an die API weiter. Ebenso wird jede Antwort von der API an die Client-Anwendung weitergeleitet.

Wie funktioniert ein BFF-Muster in der Praxis? 
 

Einzelheiten zum BFF-Muster

In diesem Szenario wird das BFF-Muster zu einer OAuth 2.0-Client-Anwendung. Da das BFF-Muster auf einem Backend-System läuft, kann es als vertraulicher Client konfiguriert werden. Das BFF ist der Client, d. h. es initialisiert den OAuth 2.0-Flow, der im Browser des Benutzers läuft. Nach dem ersten Schritt des Flows erhält das BFF einen Autorisierungscode, den es im Rahmen einer Client-Authentifizierung mit dem Autorisierungsserver gegen Token eintauscht. Mit dem Zugriffstoken kann das BFF-Muster die API-Anfragen weiterleiten. Bei Bedarf kann das BFF mit dem Aktualisierungstoken einen neuen Zugriffstoken erhalten. Beachten Sie, dass für die Verwendung des Aktualisierungstokens eine Authentifizierung des BFF-Musters gegenüber dem Autorisierungsserver erforderlich ist.

Das BFF-Muster wird von Hunderten oder sogar Tausenden von Client-Instanzen gemeinsam genutzt, von denen jede im Namen eines anderen Benutzers agiert. Das BFF behält mit einer Cookie-basierten Sitzung den Überblick über diese Nutzer. Das BFF kann diese Sitzung auf dem Server behalten (z. B. in einem einfachen Datenspeicher), kann sie aber auch an den Client weitergeben (z. B. in einem verschlüsselten Sitzungsobjekt). Ersteres führt zu einem zustandsabhängigen BFF-Muster, während bei letzterem das BFF zustandslos wird. Beide Ansätze sind machbar.

Beachten Sie, dass das BFF-Muster die Best Practices der Cookie-Sicherheit befolgen muss, um die Sicherheit des Cookies zu gewährleisten. Konkret bedeutet dies, dass zum Setzen eines Cookies mit dem Namen „MyBFFCookie“ der folgende Header verwendet werden muss: Set-Cookie: __Host-MyBFFCookie=…; Secure; HttpOnly; SameSite. Weitere Informationen über die Cookie-Sicherheit.

Wenn der Client eine Anfrage sendet, verwendet das BFF-Muster die Sitzungsinformationen in der Anfrage, um die Token des Benutzers abzurufen. Wenn der Zugriffstoken noch gültig ist, kann das BFF die Anfrage direkt weiterleiten. Sollte der Zugriffstoken abgelaufen sein, verwendet das BFF den Aktualisierungstoken des Benutzers, um einen neuen Zugriffstoken zu erhalten, bevor es die Anfrage weiterleitet.

Es sollte noch erwähnt werden, dass sich aus Sicht des Nutzers nichts ändert. Die Benutzererfahrungen einer Frontend-Client-Anwendung und einer Frontend-Anwendung, die von einer BFF unterstützt wird, sind identisch.
 

Die Vorteile des BFF-Musters

Ein Backend-für-Frontend-Muster bietet erhebliche Sicherheitsvorteile gegenüber browserbasierten Anwendungen. Es fungiert als OAuth 2.0-Client und kann somit bewährte Sicherheitsverfahren für vertrauliche Clients zum Einsatz bringen. Dies bedeutet konkret Folgendes:

• Das BFF-Muster muss sich gegenüber dem Autorisierungsserver authentifizieren, wenn ein Autorisierungscode oder ein Aktualisierungstoken eingetauscht wird.

• Das BFF kann sich auf solide schlüsselbasierte Authentifizierungsmechanismen stützen (z. B. mutual TLS).

• Das BFF kann Sender-Constrained-Zugriffstoken und Sender-Constrained-Aktualisierungstoken verwenden.

• Zugriffstoken und Aktualisierungstoken werden im Browser niemals offenbart.

Aber was wäre mit einem potenziell schädlichen JavaScript Code, der in der Frontend-Anwendung läuft? In diesem Szenario kann der Schadcode nicht mehr auf die Token zugreifen, da sie nur für die BFF verfügbar sind. Durch Cookie-Sicherheitsmaßnahmen (d. h. das HttpOnly-Attribut) wird verhindert, dass der Schadcode die Sitzung mit dem BFF-Muster stiehlt.

Der Schadcode kann jedoch das Verhalten der Client-Anwendung verändern. Konkret kann der Angreifer einen Session-Riding-Angriff durchführen, indem er bösartige API-Aufrufe über die BFF sendet. Solche API-Aufrufe können nicht von legitimen Anfragen des Clients unterschieden werden.

Allerdings hat das BFF hier die volle Kontrolle. Daraus folgt, dass ein BFF-Muster die API-Fläche beschränken kann, indem es den Client daran hindert, auf bestimmte Endpunkte zuzugreifen. Darüber hinaus kann das BFF mit Mustern zur Verkehrsanalyse arbeiten, um verdächtiges Verhalten aufzudecken. Beispiele hierfür sind unter anderem das Erkennen einer verdächtig großen Anzahl von Vorgängen oder das Beobachten einer unerwarteten Reihenfolge sensibler Vorgänge.

Schließlich bleibt zu bedenken, dass ein BFF nichts unternimmt, um eine Ausführung des Schadcodes zu verhindern. Der Angreifer kann nach wie vor sensible Daten auslesen oder Social-Engineering-Angriffe auf den Benutzer durchführen. Die einzige Möglichkeit, derartige Angriffe zu verhindern, ist die Einhaltung strenger Richtlinien zur sicheren Programmierung der Frontend-Anwendung.
 

Kurz gesagt: Schädlicher JavaScript-Code ist eine signifikante Bedrohung für browserbasierte Anwendungen. Mit erweiterten JavaScript-Nutzlasten können vorhandene Sicherheitsmechanismen umgangen werden, um Token zu stehlen, selbst wenn die Aktualisierungstoken rotieren und isoliert sind.

In Anbetracht all dessen besteht die einzige Lösung zur Sicherung einer sensiblen Einzelseitenanwendung (SPA) in der Verwendung eines Backend-für-Frontend-Musters, das die bewährten OAuth 2.0-Sicherheitspraktiken für vertrauliche Clients einhält.

Nicht sensible SPAs können die OAuth 2.0-Richtlinien für browserbasierte Anwendungen befolgen. Solche SPAs verarbeiten Token direkt und stützen sich auf die Aktualisierungstoken-Rotation zur Erkennung einer Wiederverwendung.

Am wichtigsten ist es jedoch, dass die Richtlinien zur sicheren Programmierung befolgt werden, um zu verhindern, dass sich schädliches JavaScript in der Anwendung einnistet.  

Weitere Informationen über die Sicherheit von OAuth 2.0 und OpenID Connect in Single-Page-Anwendungen finden Sie in Philippe's Online-Kursen oder Sie wenden sich direkt an Philippe, um Unterstützung für Ihre Anwendungen zu erhalten.