Content Security Policy (CSP) ist eine Sicherheitsfunktion, die in Webbrowsern implementiert ist, um Websites und Webanwendungen vor verschiedenen Arten von Angriffen zu schützen, wie z. B. Cross-Site-Scripting (XSS) und Data-Injection-Angriffe. CSP kontrolliert und begrenzt die Quellen verschiedener Arten von Inhalten, die Sie auf einer Webseite laden oder ausführen können. Zu diesen Arten von Inhalten gehören:
- Skripte
- Stylesheets
- Abbilder
In diesem Beitrag werden wir zunächst einen Blick darauf werfen, wie CSP funktioniert. Wir werden sehen, dass eine effektivere und dynamischere Nutzung von CSP einige Berechnungen beinhaltet, die auf dem Server stattfinden müssen. Es ist jedoch möglich, diese Berechnungen an den Rand zu verlagern, wodurch die Latenzzeit verringert und ein optimales Endbenutzererlebnis gewährleistet wird. Wir werden auch untersuchen, wie diese Edge-Computing-Lösung funktionieren könnte.
Sind Sie bereit, sich darauf einzulassen? Beginnen wir damit, zu verstehen, wie CSP funktioniert.
Wie CSP funktioniert
Ein CSP wird normalerweise serverseitig durch Hinzufügen eines Content-Security-Policy Header zu Ihrer HTTP-Antwort. Diese wird vom Webserver an einen Benutzer gesendet, der eine Webseite anfordert. Diese Kopfzeile gibt die Regeln an, die der Browser beim Laden und Ausführen des Inhalts der Seite befolgen soll.
Beispiele für die Einstellung der Content-Security-Policy Kopfzeile
Nehmen wir an, Sie arbeiten mit Express in Node.js. Sie würden Ihren CSP-Header folgendermaßen einstellen:
const express = require('express'); |
Wenn Sie Python mit Flask verwenden würden, würde der Code wie folgt aussehen:
app = Flask(__name__) |
Arbeiten mit Direktiven
Jeder CSP-Header kann mehrere Direktiven enthalten, und jede Direktive kann Werte haben, die für die Art der bereitgestellten Einstellung geeignet sind. Diese Direktiven definieren die Sicherheitsregeln für verschiedene Arten von Ressourcen. Zum Beispiel kann die script-src gibt die zulässigen Quellen für Stylesheets an.
Betrachten Sie den folgenden CSP-Kopf:
Content-Security-Policy: default-src 'self'; script-src 'self' https://static.example.com; style-src 'self' 'unsafe-inline'; |
In der obigen Kopfzeile sehen wir drei Direktiven, jede mit zugehörigen Werten.
- Die
default-srcRichtlinie, festgelegt auf'self'legt fest, dass standardmäßig alle Inhalte aus demselben Ursprung wie die Seite selbst geladen werden sollen. - Die
script-srcermöglicht das Laden von Skripten aus demselben Ursprung ('self') und die angegebene externe Quelle (https://static.example.com). - Die
style-srcermöglicht das Laden von Stylesheets aus demselben Ursprung und erlaubt auch Inline-Styles.
Die Liste der verfügbaren Richtlinien ist ziemlich umfassend. Sie kann hier eingesehen werden. Die Richtlinien umfassen:
font-src: Quellen für Schriftarten, die mit@font-faceframe-src: Quellen für verschachtelte Browsing-Kontexte, die in Elemente wie<frame>und<iframe>img-src: Quellen für Bilder und Favicons
Einbindung des CSP in HTML
Sobald der CSP-Header auf dem Server gesetzt ist, setzt der Browser diese Regeln beim Laden von Ressourcen auf der Webseite durch.
Im HTML-Quelltext können Entwickler Elemente (z. B. Skripte oder Stylesheets) inline oder durch Verweise auf Ressourcen (aus demselben oder einem anderen Ursprung) hinzufügen. Der Browser überprüft dann den CSP-Header, um sicherzustellen, dass diese Ressourcen den festgelegten Regeln entsprechen. Ist eine Ressource durch das CSP nicht zugelassen, blockiert der Browser ihre Einbindung und Ausführung.
Einzigartig bei jeder Anfrage
Aufgrund der Art und Weise, wie CSP-Header definiert sind, sind sie in der Regel bei allen Anfragen für eine bestimmte Webseite gleich. Die Details und Direktiven für jede Anforderung einer einzelnen Seite sind bei jeder nachfolgenden Anforderung dieser Seite gleich.
Das wirft eine interessante Frage auf: Wie würden wir mit dynamischen Inline-Skripten und -Stilen umgehen? Möglicherweise möchten wir die Ausführung bestimmter Inline-Skripte und -Stile zulassen, ohne die Tür für die Einbeziehung aller Inline-Skripte und -Stile zu öffnen.
Für dieses Szenario ist es möglich, Nonce-Werte oder Hashes einzuführen, um sicherzustellen, dass die Quelle eines Skripts oder Stils auch dann ausgeführt werden kann, wenn sie nicht explizit im CSP aufgeführt ist - solange sie mit dem Nonce- oder Hash-Wert übereinstimmt, der im CSP-Header angegeben ist.
Diese Nonce-Werte oder Hashes können sich bei jeder Anfrage ändern, wodurch sie eindeutig werden. Sie müssen also auf einem Server erzeugt und verwaltet werden. Aber nur weil diese Nonces oder Hashes auf einem Server ausgeführt werden müssen, müssen sie nicht unbedingt auf dem Hauptserver Ihrer Website ausgeführt werden. Und genau hier kommt Edge Computing ins Spiel.
Was ist Edge Computing?
Edge Computing ist im Wesentlichen das Konzept, dass bestimmte Berechnungen am äußeren Rand des Netzes - in geografischer Nähe zu den Endnutzern - ausgeführt werden können. Im Grunde handelt es sich um eine Art der verteilten Datenverarbeitung, die es ermöglicht, Rechengeschwindigkeiten in Echtzeit zu erreichen, sogar über das Internet, und gleichzeitig die Latenzzeit im Netz zu verringern.
Mit Edge Computing könnten Sie die Probleme verlagern, indem Sie Nonces und Hashes für Ihre CSP-Header näher an Ihren Endnutzern generieren und so die Zeit verkürzen, die diese auf die Sicherung Ihrer Website warten müssen.
Wie Edge Computing bei CSP helfen kann
Einer der Hauptgründe, warum CSP Ihre Website verlangsamen kann, ist die Tatsache, dass die Nonces in den Headern zu Cache-Fehlern führen können, so dass der Browser Ihres Kunden den ganzen Weg zum Server zurücklegen muss, damit Ihre Website die frischesten Header ordnungsgemäß generiert bekommt. Um dies zu vermeiden, können Sie einen dynamischen CSP-Nonce-Generator in einer Edge-Instanz implementieren. Auf diese Weise können Sie sicherstellen, dass Ihr Caching weiterhin nützlich ist und gleichzeitig die Sicherheit gewahrt bleibt.
Zu den Vorteilen dieses Ansatzes gehören:
- Geringere Latenzzeit: Die Edge-Compute-Instanz generiert das Nonce und fügt es in die Anfrage ein. Die Anfragen, die nun mit der eingefügten Nonce versehen sind, werden weiter zum Cache geleitet, so dass nicht bei jeder Anfrage der Ursprungsserver aufgerufen werden muss, um neue Antworten abzurufen.
- Verteilte Sicherheit: Die Verwendung von Edge-Berechnungen bedeutet, dass Sie eine zusätzliche Sicherheitsebene haben, bevor die Kunden überhaupt mit den primären Servern und dem Anwendungscode Ihres Systems interagieren müssen. Selbst wenn Sie eine Anwendungsschwachstelle haben, bietet Ihre Edge-Berechnung, die den CSP-Nonce berechnet, eine zusätzliche Sicherheitsebene, die Ihnen hilft, potenzielle Probleme zu entschärfen.
- Leichtere Wartung: Wenn Sie die dynamische Nonce für den CSP-Header am Edge mit einem serverlosen Ansatz verwalten, vereinfacht dies Ihre Wartungsaufgaben. Insbesondere können Sie CSP-Richtlinien verwalten, ohne den Anwendungscode zu ändern. Außerdem können Sie diese Art von Änderungen in der Regel von einem zentralen Kontrollsystem aus verwalten, ohne dass Sie spezielle Code-Deployments vornehmen müssen. Diese Edge-Computation-Funktionen können auch von mehreren unabhängigen Anwendungen genutzt werden, so dass die Bedenken der einzelnen Teams, die an den einzelnen Anwendungen arbeiten, ausgeräumt werden und die Sicherheitsexperten sicherstellen können, dass die richtige Nonce-Generierung erfolgt.
Fazit
Sind Sie daran interessiert, mehr über die Nutzung von Edge Computing zu erfahren? Dann sollten Sie sich einige der vorgestellten Produkte von Akamai ansehen. Insbesondere EdgeWorkers schaffen eine serverlose Erfahrung, die genau das tun kann, was wir in diesem Artikel besprochen haben - ohne die Komplexität, herauszufinden, wie Sie selbst Server am Rand Ihres Netzwerks bereitstellen können.
Wenn Sie bereit sind, es selbst auszuprobieren, melden Sie sich noch heute für eine kostenlose Testversion an! Es ist an der Zeit, Ihre Website mit besseren CSP-Headern zu sichern, die Ihr Caching-System nicht zerstören!
Kommentare