Content-Security-Policy: Mehr Sicherheit bei Webinhalten

Aktive Inhalte auf Websites – z. B. JavaScript, CSS, ActiveX – stellen ein Sicherheitsrisiko für Internetnutzer und Betreiber von Websites dar. Denn sie können durch sogenanntes Cross-Site-Scripting manipuliert werden. Damit Internetseiten trotzdem ohne Bedenken in vollem Umfang genutzt werden können, hat man eine Content-Security-Policy (CSP) eingeführt. Der Sicherheitsstandard soll gegen schädliche Angriffe schützen und wird inzwischen von den meisten Webbrowsern unterstützt. Das Sicherheitskonzept schützt sowohl Websites als auch Internetnutzer. Aber was steckt dahinter und wie funktioniert CSP?

Die Content-Security-Policy hat ihre Ursprünge im Jahr 2004 – damals noch unter dem Namen „Content-Restriction“. Grund für die Bemühungen waren zunehmende Sicherheitslücken bei Internetskripten. Besonders das Cross-Site-Scripting (XSS), eine kriminelle Methode, um Schadcode in eine Website einzuschleusen, stellt ein großes Risiko für Anwender dar. Dabei rufen die Nutzer zwar eine vertrauenswürdige Website auf, dort läuft allerdings ein Skript, das schädliche Daten aus einer fremden Quelle lädt. Die Cyberkriminellen nutzen dazu z. B. Sicherheitslücken in Kommentarfunktionen der Website. So können sie Zugang zu persönlichen Computern erlangen, ohne dass sich die Internetnutzer dessen überhaupt bewusst sind. Die Webmaster bemerken meist ebenso wenig, dass der fremde Code eingeschleust wurde.

Um dieses Problem zu beheben, hat die Mozilla Foundation die Entwicklung der CSP vorangetrieben. Der Vorteil hinter dem Sicherheitsstandard ist, dass im Browser Regeln aufgestellt werden können, welche Skripte die Software laden darf und welche nicht. Dazu setzt die Content-Security-Policy auf HTTP-Header.

Bei der Kommunikation im Internet tauschen Client und Server Daten über das Hypertext Transfer Protocol (HTTP) aus. Ein wichtiger Bestandteil der Requests und Responses sind HTTP-Header-Felder: In diesen werden Parameter und Argumente übermittelt, die für den Austausch der beiden Gesprächsteilnehmer (Server und Client) wichtig sind. Sie werden grundsätzlich in Anfrage- und Antwortfelder aufgeteilt und können z. B. Informationen über Zeichensatz, Sprache und Cookies beinhalten. CSP wird als Antwort-Headerfeld realisiert. Das bedeutet, dass der Server die Informationen liefert und der Browser diese verarbeitet.

Der Content-Security-Policy-Header wird vom Webmaster erstellt und auf jeder Unterseite der Website eingefügt, auf der der Sicherheitsstandard gelten soll. Als Betreiber der Website haben Sie so die Möglichkeit, unterschiedliche Sicherheitsvorkehrungen für jede einzelne Seite festzulegen. Unkomplizierter realisieren Sie das Sicherheitskonzept, indem Sie .htaccess-Dateien erstellen, die in den gleichen (oder hierarchisch höheren) Ordnern wie die entsprechenden Webpages liegen, oder indem Sie CSP direkt in die Server-Konfiguration verankern.

Im Sinne einer Content-Security-Policy und um Cross-Site-Scripting zu verhindern, sollten Webmaster sämtliche Skripte in gesonderte Dateien auslagern, statt sie direkt im Quellcode der Homepage einzubetten. Die CSP funktioniert dann nach dem Prinzip einer Whitelist: Im Header werden die Quellen genannt, aus denen Skripte und Daten geladen werden dürfen. Sollte ein fremdes Skript unerkannt in den HTML-Code der Seite eingeschleust worden sein und nun versuchen, externe Daten zu laden, muss der Browser des Nutzers dieses verbieten. Standardmäßig blockiert eine CSP alle Skripte, die sich direkt im Code befinden (Inline-Skripte). So werden sowohl die Website als auch der Internetnutzer – und vor allem dessen sensible Daten – geschützt.

Manipulationen durch Cross-Site-Scripting sind für Cyberkriminelle relativ leicht durchzuführen. Fast jede Seite im World Wide Web besitzt ein Eingabefeld: z. B. Kommentarfunktion, Suchleiste oder Log-in-Feld. Statt einfachem Text können dort auch Skripte eingefügt werden. Wenn der Server nicht entsprechend abgesichert ist, implementieren Kriminelle auf diesem Weg Phishing-Interfaces, bringen die gesamte Website zum Erliegen oder erlangen durch Schadsoftware die Kontrolle über den Webbrowser des Nutzers. CSP (oder richtiger: das entsprechende Headerfeld) teilt dem Webbrowser mit, aus welchen Quellen er Daten laden darf. Ist die Policy im Code der Website implementiert, wird der Versuch, über XSS eingeschleusten Code abzurufen, mit einer Fehlermeldung beantwortet.

Über die Content-Security-Policy können Webmaster aber auch viele weitere Einstellungen vornehmen, beispielweise durch diese Direktiven:

• base-uri: Beschränkt die URLs, die im <base>-Element der Webpage auftauchen dürfen.

• child-src: Legt fest, aus welchen Quellen Daten in Frames auftauchen dürfen, z. B. bei eingebetteten Videos von Drittanbietern.

• connect-src: Beschränkt die Quellen, mit denen sich die Seite verbinden kann, z. B. über Links.

• font-src: Bestimmt die Quellen, aus denen Schriftarten geladen werden dürfen.

• form-action: Stellt eine Liste von gültigen Endpunkten in Formularen bereit.

• frame-ancestors: Legt fest, welche Domains die Seite in Frames und iFrames einbauen dürfen.

• img-src: Beschränkt die Quellen, aus denen Bilder geladen werden dürfen.

• media-src: Legt fest, aus welchen Quellen Audio- und Video-Formate geladen werden dürfen.

• object-src: Definiert die Kontrolle über Flash und andere Plug-ins.

• plugin-types: Limitiert die Arten von Plug-ins.

• report-uri: Spezifiziert eine URL, an die Berichte geschickt werden, wenn gegen die Sicherheitsmaßnahmen verstoßen wurde.

• script-src: Bestimmt, welche Quellen für JavaScript erlaubt sind.

• style-src: Funktioniert wie script-src, wird allerdings bei Stylesheets angewendet.

• upgrade-insecure-requests: Legt fest, dass unsichere Seiten mit HTTP wie HTTPS-Seiten behandelt werden.

• sandbox: Verschiebt die betreffende Seite in eine Sandbox, in der u. a. Formulare, Pop-ups und Skripte verboten sind.

Diese Direktiven gelten nur, wenn sie ausdrücklich gesetzt sind. Ansonsten stehen sie standardmäßig offen und stellen somit eine Sicherheitslücke dar. Mit der default-src lässt sich dies allerdings ändern: Hier können Sie den standardmäßigen Zustand aller Direktiven festlegen, die mit -src enden. Statt diese offen zu lassen, stellen Sie z. B. ein, dass nur Daten aus Ihrer eigenen Website geladen werden dürfen, es sei denn, Sie haben es im HTTP-Header einer einzelnen Webpage anders festgelegt. In gesonderten Direktiven fügen Sie dann noch weitere Quellen hinzu.

In das Header-Feld können Sie beliebig viele Direktiven eintragen. Möchten Sie mehrere Direktiven aufnehmen, trennen Sie diese durch Semikolons. Außerdem müssen Sie als Webmaster alle Quellen innerhalb einer Direktive angeben. Mehrmalige Nennungen von gleichen Direktiven mit zusätzlichen Quellen wie im folgenden Beispiel sind nicht zulässig: