Das Besondere am World Wide Web ist, dass alle Inhalte miteinander vernetzt sein können. Mit nur einem Klick gelangt man zu weiterführenden Informationen oder neuen Inhalten. Zugleich wurde auch das traditionelle Konzept von „Seiten“ durch das WWW dank seiner Vernetzungs- und Interaktionsmöglichkeiten deutlich erweitert. Neben Fließtext und Bildern kann eine Seite aus weiteren Elementen bestehen, die aus ganz unterschiedlichen Quellen interaktiv eingebunden sind: Youtube-Videos, aktuelle Podcasts, Instagram-Fotos, Tweets (Twitter) oder Präsentationen mit Prezi sind nur ein paar der bekannteren Beispiele.

Diese Einbinde-Möglichkeit hat aber auch ihre Kehrseite, da man selbst als Seitenbetreiber_in kaum mehr überblicken kann, was am Ende auf einer Seite zu sehen sein wird. Thematisch unpassende, aufdringliche Werbeanzeigen nerven; Tracking-Cookies von Werbetreibenden oder von Social Media Funktionen durchleuchten die Besucher_innen meist ohne Vorwarnung und ohne Opt-out-Möglichkeit.

Über solche unerwünschte Aspekte hinaus bedeutet die vernetzte Herangehensweise des World Wide Web auch, dass sogar gefährliche Inhalte in eigentlich harmlose Seiten hineingeraten können.

Typische Einfallstore

Die Einfallstore sind zum Einen die eigentlich willentlich eingebundenen externen Quellen und zum Anderen (unbewusst) bestehende Sicherheitslücken: Wenn die eigene Website durch ein Content Management System befüllt wird, finden sich trotz aller Sorgfalt immer wieder Schwachstellen in der Programmierung dieses Redaktionssystems. Gerade interaktive Funktionalitäten sind besonders gefährdet. Typische Beispiele sind hierfür

• Formulare (Anmeldemasken, Registrierungsformulare, Fragebögen, Suchfelder), die die eingegebenen Daten nicht auf den eigentlich beabsichtigten Inhalt prüfen oder beschränken, sondern z.B. statt der Eingabe einer eMail-Adresse dann möglicherweise die Übertragung von Programmiercode erlauben;
• Funktionen zum Hochladen von Dateien (im Kern ebenfalls Formulare), die es versäumen zu überprüfen, ob z.B. wirklich nur eine Grafik oder doch stattdessen Programmcode übertragen wurde;
• Suchfilter oder andere Parameter, die von einer Seite an die nächste übergeben wurden und bei denen aufgrund mangelnder Überprüfung Code-Einschleusung nicht verhindert wurde.

Eine so präparierte Website kann dadurch ganz andere Inhalte anzeigen als ursprünglich beabsichtigt. Wenn Nutzer_innen dann per eMail oder über Social-Media eine Einladung erhalten die Seiten zu besuchen, können sie nur sehr schwer erkennen, dass die Inhalte manipuliert wurden. Die Web-Adresse sieht ja weiterhin vertrauenswürdig aus und selbst die möglicherweise vorhandene https-Verschlüsselung funktioniert wie eh und je.

Die Lösung naht: Fremde Quellen explizit durch CSP freigeben

Um diesem Dilemma etwas entgegenzusetzen, wurde das Konzept der »Content Security Policy« (CSP) ersonnen. Im Kern funktioniert es so, dass die Betreiber einer Website im Rahmen einer Liste (Whitelist) einzeln aufführt, von welchen fremden Quellen Inhalte überhaupt auf der Website erscheinen dürfen. Die Liste ist dabei in einzelne Sektionen unterteilt. So kann beispielsweise festgelegt werden, dass für Audio und Video bestimmte Quellen zugelassen sind, Schriftarten oder eingebundene Fragebogen aber wiederum nur von anderen Quellen. Dadurch soll verhindert werden, dass eingebunde Quellen Inhalte mit ausliefern, die man als Betreiber_in einer Website nicht vorher eingeplant hat.
Dieses „Whitelisting“ hat allerdings eine Kehrseite: Nicht explizit freigegebene Quellen werden auch ohne weitere Erklärung unterdrückt. Wenn man beim Befüllen der Inhalte die Liste der Freigaben nicht im Kopf hat, wird man bei nicht-angezeigten Inhalten kaum die Ursache des Problems erkennen. Eine Einführung von CSP-Mechanismen sollte daher immer in enger Abstimmung zwischen den technisch und den redaktionell verantwortlichen Teams erfolgen.

Umsetzung von Content Security Policy im ePartool

Das ePartool unterstützt seit dem Frühjahr 2017, ab den Versionen 4.3.x, das Konzept der Content-Security-Policy.

Seither haben wir die Konfiguration noch etwas vereinheitlicht und verbessert. Die Quellen können in der Datei config.ini des ePartool eingetragen werden. Aus Sicherheitserwägungen heraus kann die Liste leider nicht bequem über die Redaktionsoberfläche verändert werden (da sie sonst angreifbar wäre und der Sicherheitsaspekt konterkariert würde). Wir liefern das ePartool bereits mit häufig benutzen Quellen aus, allerdings lohnt es sich auf jeden Fall, die Liste selbst noch zu überprüfen.

Der Aufbau und eine Übersicht der vorhandenen Einstellungsmöglichkeiten finden sich in der config.ini-Beispieldatei, die im selben Ordner zu finden ist wie die config.ini selbst: tool/application/configs/config.local-example.ini

; CORS settings - contains list of allowed addresses from where can be loaded external resources
; allow address for specific type of resource
; for details see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

; Serves as a fallback for the other fetch directives
; cors.default-src[] = "*.example.com"

; Specifies valid sources of application manifest files - <link rel=manifest>
; cors.manifest-src[] = "*.example.com"

; Specifies valid sources for loading media using the <audio> and <video> elements - <video> <audio> <source> <track>
; cors.media-src[] = "*.example.com"

; Specifies valid sources for the <object>, <embed>, and <applet> elements
; cors.object-src[] = "*.example.com"

; Restricts the URLs which can be used as the target of a form submissions from a given context
; cors.form-action[] = "*.example.com"

; Specifies valid sources of images and favicons
; cors.img-src[] = "data: *.example.com"

; Specifies valid sources for fonts loaded using @font-face
; cors.font-src[] = "*.example.com"

; Specifies valid sources for JavaScript
; cors.script-src[] = "*.example.com"

; Specifies valid sources for stylesheets - <link rel=stylesheet>
; cors.style-src[] = "*.example.com"

; Restricts the URLs which can be loaded using script interfaces - XmlHttpRequest() WebSocket() EventSource() sendBeacon() fetch()
; cors.connect-src[] = "example.com"

; Defines the valid sources for web workers and nested browsing contexts loaded using elements such as <frame> and <iframe>
; cors.child-src[] = "*.example.com"

Browserunterstützung: Fast alle sind dabei

CSP wurde bereits weiter entwickelt und ist derzeit in der zweiten Ausbaustufe technisch definiert. Während die Grundfunktionen mittlerweile in den meisten Browsern Einzug gefunden haben, wird der aktuelle Level 2 des Content Security Policy Konzepts vom Opera Mini und dem Internet Explorer 11 nicht unterstützt (aber vom Microsoft-Edge-Browser). Detaillierte Informationen hierzu finden sich bei »Can I Use …« unter https://caniuse.com/#search=csp