Die Absicherung von SPAs ist Teamarbeit

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Eine der interessanten – und zugleich frustrierenderen – Beobachtungen, die ich im Laufe der Jahre gemacht habe, ist, wie unterschiedlich Netzwerkingenieure und Anwendungsentwickler Anwendungen betrachten. Das zeigt sich sowohl darin, wie Anwendungen in Netzwerkdiagrammen dargestellt werden, als auch umgekehrt darin, wie Netzwerke in Diagrammen zur Anwendungsarchitektur abgebildet werden.

Es versteht sich von selbst, dass beide ein stark vereinfachtes Bild voneinander haben.

Das gilt auch für die IT-Sicherheit, deren Rolle beim Schutz nicht nur von Netzwerken und Anwendungen, sondern des gesamten Unternehmens inzwischen von größter Bedeutung ist. Sicherheitsteams müssen über die Kästchen typischer Architekturdiagramme hinausblicken, um Anwendungen wirklich zu verstehen. Ein erheblicher Anteil der (erfolgreichen) Angriffe erfolgt auf der Anwendungsebene. Je länger wir die besonderen Merkmale der verschiedenen Anwendungstypen nicht erkennen, desto länger bleiben diese Anwendungen anfällig.

In der heutigen Diskussion geht es um SPAs. Für alle, die sich fragen, wofür dieses spezielle Drei-Buchstaben-Kürzel steht: „Single Page Applications“.

Eine Einführung in SPAs

Eine Single-Page-Anwendung ist genau das: eine einzelne Webseite, die als Grundlage für alle anwendungsbezogenen Aufgaben dient. Diese Architektur geht auf die Zeit des Web 2.0 und das Aufkommen von AJAX zurück, mit dem einzelne DOM-Elemente (Document Object Model) „aktualisiert“ werden konnten, anstatt die gesamte Seite neu zu laden. Diese Technik führte zu erheblichen Leistungssteigerungen und war der Vorläufer moderner Single-Page-Anwendungen.

Diese Apps ähneln in ihrem Verhalten eher mobilen Apps: Die Benutzeroberfläche des Clients wird beim ersten Öffnen geladen, und bei der Kommunikation mit dem Server werden ausschließlich Daten übertragen. Das bedeutet, dass jeder Aufruf des Servers nur Daten enthält und sämtliche Änderungen an der Benutzeroberfläche auf dem Client erfolgen. Dadurch wird die Menge der übertragenen Daten drastisch reduziert, was erwartungsgemäß zu einer besseren Leistung führt. Solche Apps nutzen APIs für den Datenaustausch.

Im Allgemeinen sind wir bisher davon ausgegangen, dass die meisten dieser APIs nach REST-Prinzipien implementiert sind. Das bedeutet, dass jedes Objekt (das in der Regel einem einzelnen UI-Element zugeordnet ist) über eine eigene API verfügt, die zur Ausführung von CRUD-Transaktionen (Erstellen, Lesen, Aktualisieren und Löschen) aufgerufen werden kann. Aus Sicherheitsperspektive vereinfacht dies die Sache etwas, da bei einem bestimmten API-Aufruf (URI) Daten in bestimmten Formaten zu erwarten sind. Bei den an "/update/product/123" gesendeten Daten handelt es sich stets um dasselbe serialisierte Objekt, während die an "/delete/order/4433" gesendeten Daten ein anderes serialisiertes Objekt darstellen. Das bedeutet, dass sich diese API mithilfe herkömmlicher Verfahren absichern lässt, bei denen bestimmte Richtlinien mit bestimmten URIs verknüpft werden.

Das Muster einer einzigen URI

SPAs können diesem Muster folgen – müssen es aber nicht. Neue Ansätze für SPAs können und werden dieselbe API sowohl zur Durchführung von Transaktionen als auch für eine traditionellere Zuordnung von Funktionen zu URIs verwenden. Bei einer SPA mit einem einzigen URI-Muster ändert sich die URI nicht – wohl aber die serialisierten Objekte, die zwischen Server und Client ausgetauscht werden.

Dies erinnert an SOA/XML-Transaktionen, bei denen ein einzelner Endpunkt (URI) zum Aufrufen mehrerer Funktionen verwendet wurde. Die aufzurufende Funktion (der Endpunkt) war in den serialisierten XML-Daten enthalten oder wurde mitunter in einen benutzerdefinierten HTTP-Header eingefügt. Dieses Modell machte SOA/XML-Gateways erforderlich, die Anfragen entgegennahmen, die jeweils aufgerufene Funktion ermittelten und die Anfrage anschließend an den richtigen Endpunkt (Server) weiterleiteten.

Bei SPAs haben Sie es möglicherweise mit mehreren API-Aufrufen oder auch nur mit wenigen zu tun. In jedem Fall müssen Sie wahrscheinlich Daten in einem bestimmten Format absichern (vielleicht XML, wahrscheinlicher jedoch JSON). Das bedeutet, dass Sie sich bewusst sein müssen, dass die Inhalte ein Risiko darstellen. Da einige Daten möglicherweise zur dynamischen Generierung von UI-Elementen (oder anderweitig zur Manipulation des DOM auf dem Client) verwendet werden, ist es wichtig, bei jeder Übermittlung nach potenziell schädlichem Code zu suchen und diesen zu entfernen.

Die Sicherheitslücke

Wenn eine einzelne URI für den Datenaustausch zwischen verschiedenen Funktionen verwendet wird, funktioniert die herkömmliche Praxis, Richtlinien an URIs zu knüpfen, leider nicht. Dies kann sogar die Sicherheit beeinträchtigen, da solche Richtlinien häufig auf bestimmte Nutzdatenformate ausgelegt sind. Auch API-Gateways verknüpfen Richtlinien (Routing, Verbrauchsmessung, Zugriff) häufig mit einer bestimmten URI. Das bedeutet, dass die Verwendung nur weniger URIs (API-Aufrufe) zur Abwicklung einer weitaus größeren Anzahl von Funktionen mit unterschiedlichen Datenformaten bestehende Sicherheitsmechanismen außer Kraft setzen kann.

Dies ist ein Beispiel dafür, warum es immer wichtiger wird, dass Security und Entwicklung (nicht DevOps, sondern Entwickler) vom ersten geschriebenen Code bis zur Bereitstellung enger zusammenarbeiten. Entwickler können bereits frühzeitig Maßnahmen ergreifen, die es dem Security-Team erleichtern, geeignete Schutzmechanismen einzurichten – etwa durch das Einfügen eines HTTP-Headers mit einer Kennzeichnung, anhand derer die richtige Richtlinie angewendet werden kann. Schon etwas so Einfaches wie "X-Code: 'order'" würde Anfragen um Informationen ergänzen, anhand derer Sicherheitslösungen die Daten erkennen und anschließend auf potenzielle Exploits prüfen könnten.

Aus architektonischer Sicht kann hierfür ein intelligenter L7-Proxy erforderlich sein, der den Code extrahiert und den URI umschreibt, bevor er die Anfrage an die entsprechende Sicherheitslösung (WAF, API-Gateway usw.) weiterleitet. Dieser Ansatz funktioniert auch, wenn der intelligente L7-Proxy die Sprache des Datenformats, beispielsweise JSON, versteht und die Entwickler bei jedem Austausch einen Code oder Endpunktnamen angeben, anhand dessen die Anfrage umgeschrieben und an die richtige Stelle weitergeleitet werden kann.

Im Idealfall bietet die Integration der Sicherheit auf Anwendungsebene direkt in die App das beste Gleichgewicht zwischen Leistung und Sicherheit. Dies ist jedoch nicht immer möglich, und manchmal sind kreative Architekturlösungen erforderlich, um das angestrebte Sicherheitsniveau zu erreichen.

Sicherheit ist Teamsache

Generell haben Änderungen daran, wie Entwickler verschiedene Verantwortlichkeiten zwischen Client und Server verteilen, erhebliche Auswirkungen darauf, wie die Infrastruktur der Anwendungsdienste mit den nachfolgenden Anfragen und Antworten interagiert. Es ist wichtig, dass die Teams für Sicherheit, Entwicklung und Anwendungsdienstinfrastruktur während des gesamten Softwareentwicklungszyklus (SDLC) eingebunden sind. Auch die Implementierung einer Architekturlösung braucht Zeit. Wird sie „bis zum Schluss“ aufgeschoben, verlängert sich die Markteinführungszeit um Tage, Wochen oder vielleicht sogar Monate. Andernfalls erfolgt die Markteinführung ohne Sicherheitsdienste, was wiederum eigene Risiken (und Konsequenzen) mit sich bringt.

Die Zusammenarbeit vom ersten Entwicklungstag an ist der beste – und schnellste – Weg, um sicherzustellen, dass Anwendungen bei der Produktivsetzung verfügbar, schnell und sicher sind.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie