4 Min

Richtlinien, die Sicherheit bieten

Eine Content-Security Policy (CSP) ist eine Sicherheitsmaßnahme, die von modernen Webbrowsern unterstützt wird, um Angriffe auf Webseiten zu verhindern, insbesondere Cross-Site Scripting (XSS) und Code-Injection-Angriffe. CSP hilft Entwicklern dabei, zu steuern, welche Ressourcen (wie Skripte, Bilder, Stile, etc.) von einer Website geladen und ausgeführt werden dürfen.

Wie funktioniert CSP?

CSP wird durch HTTP-Header implementiert. Die Website sendet eine Richtlinie an den Browser, die festlegt, welche Arten von Inhalten von welchen Quellen geladen und ausgeführt werden dürfen. Wenn der Browser eine Ressource oder einen Code findet, der nicht mit der Richtlinie übereinstimmt, blockiert er diese.

Einfache Beispielregel einer CSP

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-scripts.com; object-src 'none'

In dieser Regel werden mehrere Dinge festgelegt:

  • default-src 'self': Standardmäßig dürfen alle Ressourcen (z. B. Bilder, Videos) nur von der eigenen Domain geladen werden ('self').
  • script-src 'self' https://trusted-scripts.com: Skripte dürfen nur von der eigenen Domain ('self') oder der vertrauenswürdigen Domain https://trusted-scripts.com geladen werden.
  • object-src 'none': Verhindert das Laden von Plugins oder eingebetteten Objekten (z. B. Flash oder Java Applets), da diese oft als Einfallstore für Angriffe dienen.

Häufig verwendete Direktiven

  • default-src: Bestimmt die Standardquelle für alle Arten von Ressourcen (wenn spezifischere Direktiven fehlen).
  • script-src: Gibt an, von wo JavaScript-Code geladen und ausgeführt werden darf.
  • style-src: Bestimmt, von wo CSS geladen werden darf.
  • img-src: Definiert, von wo Bilder geladen werden dürfen.
  • font-src: Gibt an, von wo Schriftarten geladen werden dürfen.
  • object-src: Kontrolliert, von wo eingebettete Inhalte wie <object>, <embed>, oder <applet> geladen werden dürfen.
  • connect-src: Regelt, wohin Netzwerkanfragen (z. B. über fetch oder XHR) gesendet werden dürfen.
  • frame-src: Gibt an, von wo Inhalte in <iframe> geladen werden dürfen.
  • report-uri: Gibt eine URL an, an die der Browser Verstöße gegen die CSP melden kann.

Vorteile von CSP

  1. Schutz vor XSS-Angriffen: CSP verhindert, dass bösartiges JavaScript von unautorisierten Quellen auf der Seite ausgeführt wird.
  2. Verhindert Datenlecks: CSP kann verhindern, dass sensible Daten durch bösartige Skripte an externe Server übertragen werden.
  3. Schutz vor Code-Injection: Es verhindert, dass Angreifer bösartige Skripte oder Inhalte über unsichere Quellen laden.

Beispiel: Schutz vor XSS-Angriffen

Ein klassischer XSS-Angriff könnte beispielsweise ein bösartiges Skript auf einer Website einschleusen, das Benutzerdaten stiehlt. Mit einer richtig konfigurierten CSP könnte der Browser die Ausführung dieses Skripts blockieren, wenn es von einer nicht erlaubten Quelle stammt.

Stufenweise Implementierung

Eine gängige Praxis ist, CSP zunächst im “Report-Only”-Modus zu testen, um zu überwachen, welche Ressourcen geblockt würden, ohne diese tatsächlich zu blockieren. Dies kann helfen, Probleme zu erkennen, bevor die Richtlinie strikt angewendet wird.

Beispiel einer “Report-Only”-Richtlinie:

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

Dies sendet Verstöße an die angegebene Reporting-URL, ohne dass Ressourcen tatsächlich blockiert werden.

Eine solide Konfiguration der Content Security Policy (CSP) für kleine bis mittelgroße Websites kann dabei helfen, das Risiko von Sicherheitsanfälligkeiten wie Cross-Site Scripting (XSS) und Code-Injection-Angriffen erheblich zu reduzieren.

Hier ist ein Beispiel für eine CSP, die in einem HTML-Dokument implementiert werden kann, um eine ausgewogene Sicherheit zu gewährleisten.

Beispiel einer soliden CSP-Konfiguration

<!DOCTYPE html>
<html lang="de">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Beispiel für Content Security Policy</title>
    
    <meta http-equiv="Content-Security-Policy" 
          content="
            default-src 'self'; 
            script-src 'self' https://trusted-scripts.com; 
            style-src 'self' https://fonts.googleapis.com 'unsafe-inline'; 
            img-src 'self' data: https://trusted-images.com; 
            font-src 'self' https://fonts.gstatic.com; 
            connect-src 'self' https://api.trusted.com; 
            frame-src 'none'; 
            object-src 'none'; 
            base-uri 'self'; 
            form-action 'self';
            report-uri /csp-report-endpoint;
          ">
    
    <!-- Beispiel für CSS von einer erlaubten Quelle -->
    <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans">
    
    <script src="https://trusted-scripts.com/script.js" defer></script>
</head>
<body>
    <h1>Willkommen auf meiner Website</h1>
    <img src="https://trusted-images.com/image.jpg" alt="Beispielbild">
    <form action="/submit" method="POST">
        <input type="text" name="username" required>
        <button type="submit">Absenden</button>
    </form>
    
    <script>
        // Inline-Skripte sind nicht erlaubt, daher verwenden wir externe Skripte
        console.log('Hello, World!');
    </script>
</body>
</html>

Erklärung der CSP-Direktiven

  1. default-src 'self';: Standardmäßig dürfen Ressourcen (z. B. Skripte, Bilder, Styles) nur von der eigenen Domain geladen werden.

  2. script-src 'self' https://trusted-scripts.com;: Skripte dürfen nur von der eigenen Domain und von https://trusted-scripts.com geladen werden. Dies schützt vor XSS, da Skripte von anderen Quellen blockiert werden.

  3. style-src 'self' https://fonts.googleapis.com 'unsafe-inline';: CSS darf von der eigenen Domain und von https://fonts.googleapis.com geladen werden. Das Hinzufügen von 'unsafe-inline' ermöglicht die Verwendung von Inline-Stilen, sollte aber mit Bedacht eingesetzt werden, da dies ein Sicherheitsrisiko darstellen kann.

  4. img-src 'self' data: https://trusted-images.com;: Bilder dürfen von der eigenen Domain, von data:-URLs (z. B. Base64-codierte Bilder) und von https://trusted-images.com geladen werden.

  5. font-src 'self' https://fonts.gstatic.com;: Schriftarten dürfen von der eigenen Domain und von https://fonts.gstatic.com geladen werden.

  6. connect-src 'self' https://api.trusted.com;: Netzwerkverbindungen (z. B. für AJAX-Anfragen) dürfen nur zur eigenen Domain und zu https://api.trusted.com hergestellt werden.

  7. frame-src 'none';: Das Einbetten von Inhalten in <iframe>-Elementen ist nicht erlaubt, um Clickjacking-Angriffe zu verhindern.

  8. object-src 'none';: Das Laden von Plugins oder eingebetteten Objekten wird vollständig blockiert.

  9. base-uri 'self';: Das Setzen der Basis-URI für relative URLs ist auf die eigene Domain beschränkt.

  10. form-action 'self';: Formulare dürfen nur Daten an die eigene Domain senden.

  11. report-uri /csp-report-endpoint;: Berichte über Verstöße gegen die CSP werden an den angegebenen Endpunkt gesendet. Dies hilft dabei, Probleme zu identifizieren, ohne dass die Richtlinie sofort blockiert wird.

Implementierung und Test

  1. Testen der CSP: Beginne mit einer “Report-Only”-Richtlinie, um zu sehen, welche Ressourcen blockiert werden würden, ohne sie tatsächlich zu blockieren. Ändere die Meta-Angabe in Content-Security-Policy-Report-Only und stelle sicher, dass der report-uri-Endpunkt aktiv ist, um Verstöße zu erfassen.

  2. Überwachung der Berichte: Analysiere die Berichte, um zu verstehen, welche Ressourcen möglicherweise nicht korrekt geladen werden, und passe die CSP entsprechend an.

  3. Iterative Verbesserung: Optimiere die CSP regelmäßig, um neue Angriffsvektoren zu berücksichtigen und die Sicherheit deiner Website zu verbessern.

Fazit

Eine solide Content-Security Policy ist ein wichtiger Schritt, um die Sicherheit deiner Website zu erhöhen. Sie sollte jedoch regelmäßig überprüft und angepasst werden, um sicherzustellen, dass sie sowohl sicher als auch benutzerfreundlich bleibt.

Updated:

Similar Content