Web Security Headers: Content Security Policy und JavaScript-Ausführung

In der heutigen komplexen digitalen Landschaft ist die Sicherheit von Webanwendungen von größter Bedeutung. Eine der wirksamsten Abwehrmaßnahmen gegen verschiedene Angriffe, insbesondere Cross-Site Scripting (XSS), ist die Verwendung von Web Security Headers. Unter diesen sticht die Content Security Policy (CSP) als ein leistungsstarker Mechanismus hervor, um zu steuern, welche Ressourcen ein Browser für eine bestimmte Seite laden darf. Dieser Artikel bietet eine umfassende Anleitung zum Verständnis und zur effektiven Implementierung von CSP, um Ihre Webanwendungen und Benutzer zu schützen.

Grundlegendes zu Web Security Headers

Web Security Headers sind HTTP-Antwort-Header, die dem Browser Anweisungen geben, wie er sich bei der Handhabung bestimmter Inhaltstypen verhalten soll. Sie sind ein entscheidender Teil einer Defense-in-Depth-Strategie und arbeiten mit anderen Sicherheitsmaßnahmen zusammen, um Risiken zu mindern.

Einige der am häufigsten verwendeten Web Security Headers sind:

• Content Security Policy (CSP): Kontrolliert, welche Ressourcen der User-Agent laden darf.
• HTTP Strict Transport Security (HSTS): Zwingt Browser, HTTPS zu verwenden.
• X-Frame-Options: Schützt vor Clickjacking-Angriffen.
• X-Content-Type-Options: Verhindert MIME-Sniffing-Schwachstellen.
• Referrer-Policy: Steuert, wie viele Referrer-Informationen bei Anfragen mitgesendet werden sollen.
• Permissions-Policy (früher Feature-Policy): Ermöglicht eine granulare Kontrolle über Browser-Funktionen.

Dieser Artikel konzentriert sich hauptsächlich auf die Content Security Policy (CSP) und ihre Auswirkungen auf die JavaScript-Ausführung.

Was ist die Content Security Policy (CSP)?

CSP ist ein HTTP-Antwort-Header, der es Ihnen ermöglicht, eine Whitelist von Quellen zu definieren, aus denen der Browser Ressourcen laden darf. Dazu gehören JavaScript, CSS, Bilder, Schriftarten und andere Assets. Durch die explizite Definition dieser vertrauenswürdigen Quellen können Sie das Risiko von XSS-Angriffen erheblich reduzieren, bei denen bösartige Skripte in Ihre Website eingeschleust und im Kontext der Browser Ihrer Benutzer ausgeführt werden.

Stellen Sie sich CSP als eine Firewall für Ihren Browser vor, die jedoch anstelle des Netzwerkverkehrs die Ausführung von nicht vertrauenswürdigem Code blockiert.

Warum ist CSP für die JavaScript-Ausführung wichtig?

JavaScript ist eine leistungsstarke Sprache, mit der dynamische und interaktive Weberlebnisse geschaffen werden können. Ihre Flexibilität macht sie jedoch auch zu einem Hauptziel für Angreifer. XSS-Angriffe beinhalten oft das Einschleusen von bösartigem JavaScript-Code in eine Website, der dann verwendet werden kann, um Benutzeranmeldeinformationen zu stehlen, Benutzer auf Phishing-Seiten umzuleiten oder die Website zu verunstalten.

CSP kann diese Angriffe wirksam verhindern, indem sie die Quellen einschränkt, aus denen JavaScript geladen und ausgeführt werden kann. Standardmäßig blockiert CSP jegliches Inline-JavaScript (Code innerhalb von <script>-Tags) und JavaScript, das von externen Domains geladen wird. Sie können dann selektiv vertrauenswürdige Quellen mithilfe von CSP-Direktiven aktivieren.

CSP-Direktiven: Die Bausteine Ihrer Richtlinie

CSP-Direktiven definieren die Arten von Ressourcen, die geladen werden dürfen, und die Quellen, aus denen sie geladen werden können. Hier sind einige der wichtigsten Direktiven:

• default-src: Dient als Fallback für andere Fetch-Direktiven. Wenn eine spezifische Direktive nicht definiert ist, wird default-src verwendet.
• script-src: Gibt die erlaubten Quellen für JavaScript-Code an.
• style-src: Gibt die erlaubten Quellen für CSS-Stylesheets an.
• img-src: Gibt die erlaubten Quellen für Bilder an.
• font-src: Gibt die erlaubten Quellen für Schriftarten an.
• media-src: Gibt die erlaubten Quellen für Audio- und Videodateien an.
• object-src: Gibt die erlaubten Quellen für Plugins (z. B. Flash) an.
• frame-src: Gibt die erlaubten Quellen für Frames (<frame>, <iframe>) an.
• connect-src: Gibt die erlaubten Ursprünge für Netzwerkanfragen an (z. B. XMLHttpRequest, Fetch API, WebSockets).
• base-uri: Beschränkt die URLs, die im <base>-Element eines Dokuments verwendet werden können.
• form-action: Beschränkt die URLs, an die Formulare übermittelt werden können.
• upgrade-insecure-requests: Weist den Browser an, alle unsicheren URLs (HTTP) auf sichere URLs (HTTPS) zu aktualisieren.
• block-all-mixed-content: Verhindert, dass der Browser Ressourcen über HTTP lädt, wenn die Seite über HTTPS geladen wird.

Jede Direktive kann eine Vielzahl von Quellausdrücken akzeptieren, darunter:

• *: Erlaubt Ressourcen von jeder Quelle (generell nicht empfohlen).
• 'self': Erlaubt Ressourcen vom selben Ursprung (Schema, Host und Port) wie das Dokument.
• 'none': Verbietet Ressourcen aus allen Quellen.
• 'unsafe-inline': Erlaubt die Verwendung von Inline-JavaScript und -CSS (dringend abgeraten).
• 'unsafe-eval': Erlaubt die Verwendung von eval() und verwandten Funktionen (dringend abgeraten).
• 'unsafe-hashes': Erlaubt bestimmte Inline-Event-Handler basierend auf ihrem SHA256-, SHA384- oder SHA512-Hash (mit Vorsicht zu verwenden).
• data:: Erlaubt data:-URIs (z. B. inline base64-kodierte Bilder).
• https://example.com: Erlaubt Ressourcen von der angegebenen Domain (und optional Port) über HTTPS.
• *.example.com: Erlaubt Ressourcen von jeder Subdomain von example.com.
• nonce-{Zufallswert}: Erlaubt bestimmte Inline-Skripte oder -Stile, die ein passendes Nonce-Attribut haben (empfohlen für Inline-Code).
• sha256-{Hash-Wert}: Erlaubt bestimmte Inline-Skripte oder -Stile, die einen passenden SHA256-Hash haben (Alternative zu Nonces).

Implementierung von CSP: Praktische Beispiele

Es gibt zwei Hauptmethoden zur Implementierung von CSP:

1. HTTP-Header: Senden des Content-Security-Policy-Headers in der HTTP-Antwort. Dies ist die bevorzugte Methode.
2. <meta>-Tag: Verwendung eines <meta>-Tags im <head>-Abschnitt des HTML-Dokuments. Diese Methode hat Einschränkungen und wird im Allgemeinen nicht empfohlen.

Verwendung des HTTP-Headers

Um den CSP-Header zu setzen, müssen Sie Ihren Webserver konfigurieren. Die genauen Schritte variieren je nach Server (z. B. Apache, Nginx, IIS).

Hier sind einige Beispiele für CSP-Header:

Grundlegende CSP

Diese Richtlinie erlaubt nur Ressourcen vom selben Ursprung:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Ressourcen von bestimmten Domains erlauben

Diese Richtlinie erlaubt JavaScript von https://cdn.example.com und Bilder von https://images.example.net:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;
            

              
                Copy
              
            
          

Verwendung von Nonces für Inline-Skripte

Diese Richtlinie erlaubt Inline-Skripte, die ein passendes Nonce-Attribut haben:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';
            

              
                Copy
              
            
          

In Ihrem HTML:

            <script nonce="rAnd0mN0nc3">
 // Ihr Inline-Skript
</script>
            

              
                Copy
              
            
          

Hinweis: Der Nonce-Wert sollte für jede Anfrage zufällig generiert werden, um zu verhindern, dass Angreifer die CSP umgehen.

Verwendung von Hashes für Inline-Skripte

Diese Richtlinie erlaubt bestimmte Inline-Skripte basierend auf ihrem SHA256-Hash:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

Um den SHA256-Hash zu generieren, können Sie eine Vielzahl von Online-Tools oder Befehlszeilen-Dienstprogrammen verwenden (z. B. openssl dgst -sha256 -binary input.js | openssl base64).

Verwendung des <meta>-Tags

Obwohl für komplexe Richtlinien nicht empfohlen, kann das <meta>-Tag verwendet werden, um eine grundlegende CSP festzulegen. Zum Beispiel:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

Einschränkungen des <meta>-Tags:

• Kann nicht zur Angabe der report-uri-Direktive verwendet werden.
• Wird nicht so breit unterstützt wie der HTTP-Header.
• Weniger flexibel und schwieriger zu verwalten für komplexe Richtlinien.

CSP im Report-Only-Modus

Bevor eine CSP erzwungen wird, wird dringend empfohlen, den Content-Security-Policy-Report-Only-Header zu verwenden. Dies ermöglicht es Ihnen, die Auswirkungen Ihrer Richtlinie zu überwachen, ohne tatsächlich Ressourcen zu blockieren. Der Browser meldet alle Verstöße an eine angegebene URL, sodass Sie Ihre Richtlinie vor dem Einsatz in der Produktion feinabstimmen können.

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;
            

              
                Copy
              
            
          

Sie müssen einen serverseitigen Endpunkt (z. B. /csp-report) konfigurieren, um die CSP-Berichte zu empfangen und zu verarbeiten. Diese Berichte sind in der Regel JSON-Objekte, die Informationen über die verletzte Direktive, die blockierte URI und andere relevante Details enthalten.

Häufige CSP-Fehler und wie man sie vermeidet

Die Implementierung von CSP kann eine Herausforderung sein, und es ist leicht, Fehler zu machen, die entweder Ihre Sicherheit schwächen oder Ihre Website unbrauchbar machen. Hier sind einige häufige Fallstricke, die Sie vermeiden sollten:

• Verwendung von 'unsafe-inline' und 'unsafe-eval': Diese Direktiven deaktivieren im Wesentlichen die von CSP gebotenen Schutzmaßnahmen und sollten wann immer möglich vermieden werden. Verwenden Sie Nonces oder Hashes für Inline-Skripte und vermeiden Sie die Verwendung von eval().
• Verwendung von *: Das Zulassen von Ressourcen aus beliebigen Quellen untergräbt den Zweck von CSP. Seien Sie bei der Definition Ihrer Richtlinie so spezifisch wie möglich.
• Nicht gründlich testen: Testen Sie Ihre CSP immer im Report-Only-Modus, bevor Sie sie erzwingen. Überwachen Sie die Berichte und passen Sie Ihre Richtlinie bei Bedarf an.
• Falsche Konfiguration der report-uri: Stellen Sie sicher, dass Ihr report-uri-Endpunkt korrekt konfiguriert ist, um CSP-Berichte zu empfangen und zu verarbeiten.
• Versäumnis, Ihre CSP zu aktualisieren: Wenn sich Ihre Website weiterentwickelt, muss Ihre CSP möglicherweise aktualisiert werden, um Änderungen bei den Ressourcenabhängigkeiten widerzuspiegeln.
• Übermäßig restriktive Richtlinien: Zu restriktive Richtlinien können Ihre Website unbrauchbar machen und Benutzer frustrieren. Finden Sie ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit.

CSP und Drittanbieter-Bibliotheken

Viele Websites verlassen sich auf Bibliotheken und Dienste von Drittanbietern, wie z. B. CDNs, Analyseanbieter und Social-Media-Widgets. Bei der Implementierung von CSP ist es wichtig, diese Abhängigkeiten zu berücksichtigen und sicherzustellen, dass Ihre Richtlinie das korrekte Laden von Ressourcen erlaubt.

Hier sind einige Strategien für den Umgang mit Drittanbieter-Bibliotheken:

• Setzen Sie die Domains vertrauenswürdiger Drittanbieter explizit auf die Whitelist: Wenn Sie beispielsweise jQuery von einem CDN verwenden, fügen Sie die Domain des CDNs zu Ihrer script-src-Direktive hinzu.
• Verwenden Sie Subresource Integrity (SRI): SRI ermöglicht es Ihnen zu überprüfen, ob die von Drittanbietern geladenen Dateien nicht manipuliert wurden. Um SRI zu verwenden, müssen Sie einen kryptografischen Hash der Datei generieren und ihn in das <script>- oder <link>-Tag einfügen.
• Erwägen Sie, Drittanbieter-Bibliotheken auf Ihrem eigenen Server zu hosten: Dies gibt Ihnen mehr Kontrolle über die Ressourcen und reduziert Ihre Abhängigkeit von externen Anbietern.

Beispiel mit SRI:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP und Single-Page Applications (SPAs)

SPAs sind oft stark auf JavaScript und die dynamische Codegenerierung angewiesen, was die Implementierung von CSP anspruchsvoller machen kann. Hier sind einige Tipps zur Absicherung von SPAs mit CSP:

• Vermeiden Sie die Verwendung von 'unsafe-eval': SPAs verwenden oft Templating-Engines oder andere Techniken, die auf eval() basieren. Erwägen Sie stattdessen die Verwendung alternativer Ansätze, die kein eval() erfordern, wie z. B. vorkompilierte Templates.
• Verwenden Sie Nonces oder Hashes für Inline-Skripte: SPAs injizieren oft dynamisch JavaScript-Code. Verwenden Sie Nonces oder Hashes, um sicherzustellen, dass nur vertrauenswürdiger Code ausgeführt wird.
• Konfigurieren Sie die connect-src-Direktive sorgfältig: SPAs machen oft API-Anfragen an verschiedene Endpunkte. Stellen Sie sicher, dass Sie nur die notwendigen Domains in der connect-src-Direktive auf die Whitelist setzen.
• Erwägen Sie die Verwendung eines CSP-fähigen Frameworks: Einige JavaScript-Frameworks bieten integrierte Unterstützung für CSP, was die Implementierung und Wartung einer sicheren Richtlinie erleichtert.

CSP und Internationalisierung (i18n)

Bei der Entwicklung von Webanwendungen für ein globales Publikum ist es wichtig, die Auswirkungen von CSP auf die Internationalisierung (i18n) zu berücksichtigen. Hier sind einige Faktoren, die Sie beachten sollten:

• Content Delivery Networks (CDNs): Wenn Sie ein CDN zur Bereitstellung der Assets Ihrer Website verwenden, stellen Sie sicher, dass die Domains des CDNs in Ihrer CSP auf der Whitelist stehen. Erwägen Sie die Verwendung verschiedener CDNs für verschiedene Regionen, um die Leistung zu optimieren.
• Externe Schriftarten: Wenn Sie externe Schriftarten (z. B. Google Fonts) verwenden, stellen Sie sicher, dass die Domains der Schriftartenanbieter in Ihrer font-src-Direktive auf der Whitelist stehen.
• Lokalisierte Inhalte: Wenn Sie verschiedene Versionen Ihrer Website für verschiedene Sprachen oder Regionen bereitstellen, stellen Sie sicher, dass Ihre CSP für jede Version korrekt konfiguriert ist.
• Drittanbieter-Integrationen: Wenn Sie sich in Dienste von Drittanbietern integrieren, die für bestimmte Regionen spezifisch sind, stellen Sie sicher, dass die Domains dieser Dienste in Ihrer CSP auf der Whitelist stehen.

CSP Best Practices: Eine globale Perspektive

Hier sind einige allgemeine Best Practices für die Implementierung von CSP unter Berücksichtigung einer globalen Perspektive:

• Beginnen Sie mit einer restriktiven Richtlinie: Beginnen Sie mit einer Richtlinie, die standardmäßig alles blockiert, und aktivieren Sie dann selektiv vertrauenswürdige Quellen.
• Verwenden Sie zuerst den Report-Only-Modus: Testen Sie Ihre CSP im Report-Only-Modus, bevor Sie sie erzwingen, um potenzielle Probleme zu identifizieren.
• Überwachen Sie CSP-Berichte: Überprüfen Sie regelmäßig CSP-Berichte, um potenzielle Sicherheitslücken zu identifizieren und Ihre Richtlinie zu verfeinern.
• Verwenden Sie Nonces oder Hashes für Inline-Skripte: Vermeiden Sie die Verwendung von 'unsafe-inline' und 'unsafe-eval'.
• Seien Sie spezifisch bei Ihren Quelllisten: Vermeiden Sie die Verwendung von Wildcards (*), es sei denn, es ist absolut notwendig.
• Verwenden Sie Subresource Integrity (SRI) für Ressourcen von Drittanbietern: Überprüfen Sie die Integrität von Dateien, die von CDNs geladen werden.
• Halten Sie Ihre CSP auf dem neuesten Stand: Überprüfen und aktualisieren Sie Ihre CSP regelmäßig, um Änderungen an Ihrer Website und Ihren Abhängigkeiten widerzuspiegeln.
• Schulen Sie Ihr Team: Stellen Sie sicher, dass Ihre Entwickler und Ihr Sicherheitsteam die Bedeutung von CSP und die korrekte Implementierung verstehen.
• Erwägen Sie die Verwendung eines CSP-Generators oder -Management-Tools: Diese Tools können Ihnen helfen, Ihre CSP einfacher zu erstellen und zu warten.
• Dokumentieren Sie Ihre CSP: Dokumentieren Sie Ihre CSP-Richtlinie und die Gründe für jede Direktive, um zukünftigen Entwicklern das Verständnis und die Wartung zu erleichtern.

Fazit

Content Security Policy ist ein leistungsstarkes Werkzeug zur Minderung von XSS-Angriffen und zur Verbesserung der Sicherheit Ihrer Webanwendungen. Durch die sorgfältige Definition einer Whitelist vertrauenswürdiger Quellen können Sie das Risiko der Ausführung von bösartigem Code erheblich reduzieren und Ihre Benutzer vor Schaden schützen. Die Implementierung von CSP kann eine Herausforderung sein, aber indem Sie die in diesem Artikel beschriebenen Best Practices befolgen und die spezifischen Anforderungen Ihrer Anwendung und Ihres globalen Publikums berücksichtigen, können Sie eine robuste und effektive Sicherheitsrichtlinie erstellen, die Ihre Website und Ihre Benutzer weltweit schützt.

Denken Sie daran, dass Sicherheit ein fortlaufender Prozess ist und CSP nur ein Teil des Puzzles ist. Kombinieren Sie CSP mit anderen Sicherheitsmaßnahmen wie Eingabevalidierung, Ausgabekodierung und regelmäßigen Sicherheitsaudits, um eine umfassende Defense-in-Depth-Strategie zu erstellen.

Weitere Ressourcen

• Content Security Policy (CSP) – MDN Web-Dokumentation
• CSP Evaluator
• Content-Security-Policy.com