Die Sicherheit von Single-Page-Anwendungen (SPAs) funktioniert nicht wie bei Websites

Single-Page-Anwendungen (SPAs) gewinnen als einfach zu entwickelnde Schnittstelle für die Bereitstellung digitaler Daten und die Kundenbindung immer mehr an Bedeutung.

Single-Page-Anwendungen (SPAs) erfreuen sich aufgrund ihrer einfachen Entwicklung und der Fähigkeit, ein ansprechendes Benutzererlebnis zu bieten, immer größerer Beliebtheit. Allerdings bringen SPAs auch besondere Sicherheitsherausforderungen mit sich. In diesem Artikel werden wir die Schwierigkeiten bei der Sicherung von SPAs untersuchen und eine vielversprechende Lösung diskutieren, die als Token-Handler-Muster bekannt ist.

Traditionelle Websites haben ein einziges Backend, das HTML und Daten bereitstellt. Die Benutzerauthentifizierung erfolgt normalerweise auf diesem Backend-Server, der durch eine Netzwerk-Firewall geschützt ist. Allerdings sind SPAs über APIs mit mehreren Microservices verbunden, wodurch eine dezentralere Architektur entsteht. Dieser Aufbau verschafft SPAs zwar den leichten Vorteil, birgt aber auch erhebliche Sicherheitsrisiken.

Eine der größten Herausforderungen besteht darin, dass die Benutzerauthentifizierung häufig im Browser erfolgen muss und nicht auf einem geschützten Server hinter einer Netzwerk-Firewall. Dies macht SPAs anfällig für eine Vielzahl von Arten von Cyberangriffen, beispielsweise den Diebstahl von Anmeldeinformationen durch Cross-Site-Scripting (XSS). Bei dieser Angriffsmethode können böswillige Akteure Code in den Browser einschleusen, der in der Lage ist, Zugriffstoken und Benutzeranmeldeinformationen zu stehlen und ihnen letztendlich unbefugten Zugriff auf wertvolle Daten und Systeme zu gewähren.

Eine weitere Herausforderung ergibt sich aus der Vielzahl von Abhängigkeiten zu Daten Dritter, die typischerweise mit APIs mit der Anwendung verbunden sind. Ein hohes Volumen an Verbindungen Dritter kann ein zweifaches Problem verursachen.

Erstens haben Entwickler keine Kontrolle über die Sicherheit, die in APIs integriert ist, die von anderen Praktikern und Organisationen erstellt wurden. Dies kann dazu führen, dass ohne Wissen des Entwicklers Schwachstellen in die Anwendung eingeführt werden.

Zweitens kann das Programmieren in dieser komplexen und vielfältigen Umgebung mühsam sein, da eine große Menge an detailliertem, benutzerdefiniertem Code und Eingabeeinstellungen erforderlich ist. Es kann leicht passieren, dass ein wichtiger Schritt übersehen wird und unwissentlich eine Sicherheitslücke entsteht. Darüber hinaus können versteckte Sicherheitsrisiken entstehen, wenn die Umgebung wächst und sich im Laufe der Zeit an veränderte Geschäftsanforderungen anpasst.

Um die Herausforderungen weiter zu veranschaulichen, vergleichen wir das Setup für die Sicherung von Websites und SPAs.

Beim Sichern von Websites können Entwickler Cookie-basierte Sitzungen verwenden, um Benutzern Zugriff auf die Webanwendung zu gewähren. Der Frontend-Website-Client speichert Cookies im Browser, die bei jeder Benutzerzugriffsanfrage an einen einzelnen Backend-Datenserver gesendet werden. Die Autorisierungsentscheidungen können auf den im Speicher gehaltenen Sitzungsdaten basieren, sodass der Benutzerzugriff hinter der Netzwerk-Firewall geschützt bleibt.

Diese Einrichtung ist für SPAs nicht möglich, da eine Single-Page-Anwendung kein dediziertes Backend hat. Ein Content Delivery Network (CDN) stellt dem SPA häufig den Code über statische Dateien bereit. Diese Dateien werden über API-Aufrufe an die Anwendung zurückgegeben. In einer SPA-Konfiguration kann die Sitzung des Benutzers nicht in einem Cookie gespeichert werden, da kein Backend-Datenspeicher vorhanden ist. Stattdessen können Zugriffstoken verwendet werden, um APIs im Namen des authentifizierten Benutzers aufzurufen.

SPA-Sicherheitslücken

SPA-Sicherheitsherausforderungen hängen von der Tatsache ab, dass die browserbasierte Authentifizierung anfällig für eine Vielzahl von Cyberangriffstypen ist. Eine Bedrohungsart ist der Diebstahl von Anmeldeinformationen durch Cross-Site-Scripting (XSS). Bei dieser Angriffsmethode injizieren böswillige Akteure Code, der Zugriffstoken und Benutzeranmeldeinformationen stehlen kann, in den Browser, um sich unbefugten Zugriff auf wertvolle Daten und Systeme zu verschaffen.

Während XSS eine häufige Schwachstelle ist, ist es nicht die einzige, gegen die sich Entwickler verteidigen müssen. Erschwerend kommt hinzu, dass durch die Behebung einer Schwachstelle oft neue Schwachstellen entstehen, was die Sicherung von SPAs zu einem endlosen Spiel mit wechselnden Zielen macht. Beispielsweise scheint die Verwendung von OAuth-Flows zur Authentifizierung des Benutzer- oder API-Zugriffs mit OAuth-Tokens anstelle von Sitzungscookies eine gute Möglichkeit zu sein, XSS-Angriffe abzuwehren.

Wenn diese Token jedoch im lokalen Speicher gespeichert werden, können Bedrohungsakteure leicht auf den lokalen Speicher und den Sitzungsspeicher zugreifen, um Token zu exfiltrieren. Wenn Token aktualisiert werden können, verschärft sich das Problem, da Angreifer auch nach dem Ende einer Benutzersitzung Zugriff erhalten können.

Ein weiteres Beispiel für unbeabsichtigte Probleme, die mit einem Sicherheitsupdate einhergehen können, ist der Einbau strenger Sicherheitsrichtlinien in Content Security Policy (CSP)-Header. Dies kann zwar eine weitere Ebene der Sicherheitskontrolle hinzufügen, einige Quellen können jedoch möglicherweise Inhaltssicherheitsrichtlinien öffnen und diese deaktivieren.

Unter dem Strich ist der Browser eine feindliche Umgebung, wenn es darum geht, sich vor unbefugtem und böswilligem Zugriff auf Daten und Systeme zu schützen. Alle Sicherheitsmaßnahmen erfordern sorgfältige Tests und ständige Wachsamkeit, um sicherzustellen, dass das Schließen eines Angriffsvektors nicht den Weg für einen anderen öffnet.

Sowohl Cookies als auch Token verwenden

Eine Möglichkeit zur Sicherung von SPAs, die kürzlich zum Schutz der Benutzerauthentifizierung vor böswilligen Akteuren entwickelt wurde, ist ein Token-Handler-Muster, das Website-Cookie-Sicherheit und Zugriffstoken zusammenführt. Durch die Implementierung einer Token-Handler-Architektur, die die Authentifizierung vom Browser entfernt und eine Backend-für-Frontend-Konfiguration (BFF) unter Verwendung von Cookies und Token auf derselben Website nutzt, können Unternehmen von den einfachen Aspekten von SPAs profitieren, ohne auf Sicherheit zu verzichten.

In diesem Setup sitzt ein als Backend-Komponente gehosteter OAuth-Agent zwischen dem SPA und dem Autorisierungsserver. Der OAuth-Agent verwaltet den OAuth-Fluss für die SPA und anstatt der SPA ein Token auszustellen, wird ein sicheres Nur-HTTP-Cookie ausgegeben, mit dem die SPA Zugriff auf ihre Backend-APIs und Microservices erhalten kann.

Ein OAuth-Proxy, der in einem leistungsstarken API-Gateway gehostet wird

Das obige ist der detaillierte Inhalt vonDie Sicherheit von Single-Page-Anwendungen (SPAs) funktioniert nicht wie bei Websites. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!