Eine wichtige Neuerung bei der Version 12 von TYPO3 war die Einführung eines Tools zur Einrichtung einer Content Security Policy (CSP) über das TYPO3 Backend. Wie man eine CSP redaktionell und durch Programmierung konfiguriert, erkläre ich in diesem Artikel.

Was ist überhaupt eine CSP (Content Security Policy)? Eine solche Richtlinie ist seit kurzer Zeit technisch in einem Browser möglich und soll vor dem Eindringen von Schadcode auf den Server durch Cross-Site-Scripting (XSS) schützen. Dabei handelt es sich um den Versuch von Angreifern, durch manipulierte Links und darin enthaltene Befehle Scripte auf den Server einzuschleusen und zumindest einen Teil der Kontrolle über die Webseite oder das Gerät zu erlangen.

XSS ist kein neues Problem, Entwickler schlagen sich mit solchen Gefahren seit Jahren herum, aber ein gewachsenes. Denn wenn man an einer Webseite arbeitet, erfindet man heute in den wenigsten Fällen das Rad neu. Man schreibt kein JavaScript- und CSS-Framework komplett neu, um responsives Design und Funktionen wie eine auf allen möglichen Geräten funktionierende Navigation zu programmieren. Anstelle dessen setzt man auf bewährte und vielfach getestete Frameworks wie jQuery oder Bootstrap, die einem Jahre an Arbeit beim Programmieren und Testen abnehmen. Aber manchmal arbeitet man mehrere Monate nicht mehr an einem Projekt, eine neue Sicherheitslücke ist aufgetaucht oder man wechselt den Dienstleister für den Server… Im Alltag kommt es immer wieder zu solchen Verzögerungen und dann ist das System unsicher. Hier greift der Gedanke einer CSP an: Man sagt der Webseite, wer Daten in das System reinschreiben darf. Alle anderen müssen draußen bleiben.

Ein Beispiel dafür? Angenommen, Sie haben eine Datenschutzerklärung erstellt und in dieser sind Bilder enthalten, um z. B. die Arbeit eines Cookie zu erklären. Diesen Text haben Sie sich in einem Baukastensystem bei einem Dienstleister erstellen lassen und in Ihre Webseite hinein kopiert. Die Bilder liegen aber nicht bei Ihnen auf dem Server, sondern beim Dienstleister. Das macht man, um nicht alle Daten auf den eigenen Server laden zu müssen, und der Dienstleister weiß recht genau, wer wie oft die Datenschutzerklärung nutzt. Mit einer CSP können Sie nun regulieren, dass die Bilder vom Dienstleister auf die eigene Webseite geladen werden können. Aber wenn jemand auf diese Seite zugreifen und ein Bild mit einem integrierten Schadcode aus einer anderen Quelle auf den Server laden will, dann blockt der Server diesen Code und verhindert den Zugriff.

Wie sieht das nun technisch aus? Nun, eine CSP (Content Security Policy) ist eine recht neue Technologie, die von allen gängigen modernen Browsern unterstützt wird und die aber auch die Funktion älterer Browser nicht behindert. Von Seiten des Servers sagt der Entwickler bei der Einrichtung einer CSP, welche Quellen vertrauenswürdig sind und von welchen der Browser Daten holen und ggf. übertragen soll. Dies ist z. B. wichtig für Dienste wie Google Analytics und den Google Tag Manager. Der Browser bekommt diese Information, dass die Links zu Google vertrauenswürdig sind und schickt Nutzerdaten herüber. Wie man dies dem System mitteilt, schildere ich weiter unten.

Ein Content Management System wie TYPO3 12 greift nun auf diese Einstellung zurück und ummantelt die Einbindung von Quellcode im Script Tag mit einer Zufallsvariablen, einer so genannten Nonce Variablen:

<script src="/typo3temp/script-abc123.js" nonce="123abc"></script>

Nonce bedeutet „number used once“, also übersetzt „einmalig verwendete Variable“. Dahinter steckt die Idee, eine Zufallsvariable zu übertragen, mit der die Kommunikation zwischen Server und Anwender geregelt wird. Kommt Ihnen bekannt vor? Richtig, ein ähnliches Prinzip liegt der HTTPS- Verschlüsselung zu Grunde.

Die Zahlen und die Code Snippets in diesem Absatz sind übrigens stark vereinfacht.

Damit der Browser beim Nutzenden nun weiß, dass er diesen Code mit der Nonce Variablen laden und ausführen soll, braucht er natürlich noch die Information zu diesem Code. Diese schicken wir ihm über einer HEADER Anweisung beim Aufruf der Seite. Damit weiß der Browser, welche externe Dateien er nun laden und verarbeiten kann. Mit der HEADER Anweisung werden zudem noch die vertrauenswürdigen Links, Scripte und Quellen übergeben, auf die zugegriffen werden kann. Nähere Informationen zur Funktion der CSP, zu den Headern und den Optionen finden Sie in der Linkliste am Schluss dieser Seite.

Eine CSP muss in TYPO3 12.4 erst einmal von einem Administrator mit System Maintainer Rechten freigeschaltet werden. Dazu gehen Sie in die Modulleiste (deutsche Version) auf:

Einstellungen > Feature Toggles (Configure Feature) > Security: frontend enforce content security policy

Hier rücken Sie den Schieber für diese Einstellung auf aktiviert. Als Standard ist die CSP für das Frontend nicht eingeschaltet.

Damit beginnt die eigentliche Arbeit. Wenn Sie jetzt Ihre Seite aufrufen, wird sie Ihnen vielleicht recht nackt erscheinen. Denn ab diesem Zeitpunkt blockt TYPO3 sämtliche Zugriffe, die von externen Quellen Daten auf Ihren Server schaufeln wollen. Diese müssen wir nun Stück für Stück freischalten. Auf einem Testserver kann man sich nun im TYPO3 Backend ansehen, was blockiert wurde und bekommt zudem Vorschläge, wie man dies einrichten kann. Gehen Sie dazu auf das Modul Content Security Policy. Sie haben nun drei Möglichkeiten, die CSP zu konfigurieren:

• Das Modul Content Security Policy erlaubt Ihnen, jeden einzelnen Fall in die Datenbank Ihrer Webseite mit aufzunehmen
• Eine YAML Datei csp.yaml im gleichen Verzeichnis ihrer Seitenkonfiguration config.yaml enthält die Informationen über die Konfiguration
• Eine PHP Datei ContentSecurityPolicies.php im Configuration Verzeichnis Ihrer Provider Extension bzw. Ihres Site Packages regelt die Konfiguration der CSP

Ich persönlich bevorzuge die Variante der PHP Datei in der Provider Extension. Diese wird bei einem Deployment der Extension automatisch auf den Server übertragen, wogegen man die YAML Datei möglicherweise per Hand übertragen muss. Zudem erlaubt einem eine IDE wie PHPStorm den Zugriff auf Optionen, die man für die Einstellungen in TYPO3 zur Verfügung hat. Die Einbindung über den Klick in Richtung Datenbank ist ein sehr schönes Feature, dann muss die Tabelle sys_csp_resolution aber auch jedes Mal auf den Server deployed werden. Um Probleme dieser Art zu umgehen, bevorzuge ich die PHP Variante.

Legen Sie in Ihrer Provider Extension eine neue PHP Datei an: Configuration / ContentSecurityPolicies.php Diese Datei braucht nun Zugriff auf die Klassen, mit denen man die CSP in TYPO3 per API steuern kann:

<?php

declare(strict_types=1);

use TYPO3\CMS\Core\Security\ContentSecurityPolicy\Directive;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\Mutation;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\MutationCollection;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\MutationMode;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\Scope;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\SourceKeyword;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\SourceScheme;
use TYPO3\CMS\Core\Security\ContentSecurityPolicy\UriValue;
use TYPO3\CMS\Core\Type\Map;

return Map::fromEntries([
  Scope::frontend(),

  ## Beispiel für einen Codeblock zur CSP Konfiguration
  new MutationCollection(
      ## Einstellungen für gesamte Sourcen
      new Mutation(
          MutationMode::Set,
          Directive::DefaultSrc,
          SourceKeyword::self
      ),
   ),
]);

Das Objekt MutationCollection enthält nun sämtliche Unterobjekte Mutation, mit denen die Optionen der CSP eingerichtet werden können. Welche das genau sind, können Sie am besten auf einem Testserver einsehen. Denn wie an der Datenschutzerklärung oben erklärt: Manche Einbindungen sehen wir als Entwickler nicht im Quellcode, sondern sie sind redaktionell erfolgt. Nähere Informationen zu den einzelnen Optionen finden Sie unten in der Linkliste. Hier einige Beispiele für Einstellungen, die im Alltag immer wieder auftauchen:

Einbindung von Bildern eines Servers:

new Mutation(
  MutationMode::Extend,
  Directive::ImgSrc,
  SourceScheme::data,
  new UriValue('https://www.mein-typo3.de')
),

Einbindung von Scripten eines Servers:

new Mutation(
  MutationMode::Extend,
  Directive::ScriptSrc,
  SourceScheme::data,
  new UriValue('https://www.mein-typo3.de')
),

Ein Script Source Element wie den Google Tag Manager zulassen:

new Mutation(
  MutationMode::Extend,
  Directive::ScriptSrcElem,
  SourceScheme::data,
  SourceKeyword::strictDynamic,
  new UriValue('https://www.googletagmanager.com')
),

Google Analytics braucht eine Einstellung für die Verbindung zum externen Server:

new Mutation(
  MutationMode::Extend,
  Directive::ConnectSrc,
  SourceScheme::data,
  new UriValue('https://www.google-analytics.com')
),

Auch wenn man die Google Fonts lokal eingebunden hat, braucht man bei der Einbindung von Google Maps oft die Freischaltung für die von Maps genutzten Fonts:

new Mutation(
  MutationMode::Extend,
  Directive::FontSrc,
  SourceScheme::data,
  new UriValue('https://fonts.gstatic.com')
),

Damit haben Sie die wichtigsten Bausteine für ein Einbindung externer Sourcen in eine Content Security Policy. Wichtig: Das TYPO3 Backend listet ihnen im gleichnamigen Modul die blockierten Sourcen aus. Sie können sehen, wie Ihre Webseite angegriffen wird. Sie können aber auch sehen, dass Virenscanner z. B. eine Fehlermeldung verursachen. Nutzen Sie also die Vorschläge des TYPO3 Backends und nehmen Sie diese in die Liste auf. Auch in diesem Fall: Ich würde die PHP Variante nutzen.

Ein einfaches Beispiel für eine YAML Datei finden Sie hier:

inheritDefault: true
mutations:
  - mode: set
    directive: 'default-src'
    sources:
      - "'self'"

  - mode: extend
    directive: 'img-src'
    sources:
      - 'data:'
      - 'https://*.typo3.org'