HTTP-Header und Content Security Policy in Joomla 4

Ändere diesen Beitrag

Die Aufgabe eines Browsers erscheint auf den ersten Blick simpel: er zeigt Text und Bilder an, die man ihm übermittelt. Bei genauerem Hinsehen wird alles komplexer. Web-Standards sind zu unterstützen, Benutzerfreundlichkeit steht hoch im Kurs und Entwickler benötigen Werkzeuge. Hinzu kommt, dass das Web ist ein tückischer Ort ist. Webseiten werden ständig automatisiert angegriffen. Zum Schutz vor verschieden Angriffsvektoren, haben Software Hersteller HTTP Header implementiert, über welche die Webseite im Webbrowser Sicherheitsfunktionen aktiviert und so Angriffsmuster blockiert oder erschwert.

Wie macht man die Header sichbar

HTTP Header werden oft mit dem <head>-Bereich eines HTML-Dokuments verwechselt. HTTP-Header wird man neben den HTML-Header nicht finden! Die stecken im HTTP-Protokoll. Dieses bildet die Basis des World-Wide-Webs. HTTP ist die Sprache, mit der Browser und Webserver kommunizieren. Zusammen mit den sichtbaren Inhalten werden Informationen zu den Daten übermittelt. Diese sind im Kopf-Bereich der Antwort – im Head der Response. Deshalb der Name Header. Um diese anzusehen öffnet man den Netzwerk-Tab der Browser-Entwicklertools.

HTTP Header im Firefox sichtbar gemacht

Mit dem Tool Security Headers von Scott Helme ist es möglich, die HTTP-Header und deren Konfiguration zu überprüfen. Der Service liest dazu alle gesetzten Werte aus, bewertet sie und bildet daraus ein Rating. Ein Report sieht beispielsweise so aus:

Security Headers von Scott Helme

Was bietet Joomla 4

Joomla 4 unterstützt Benutzer mit dem Plugin System - HTTP Headers eine sichere Content Security Policy zu konfigurieren.

Ursprünglich sollte es zusätzlich eine Komponente geben. Über diese wären Content-Security-Policy-Reports verwaltbar gewesen. Mit dem PR github.com/joomla/joomla-cms/pull/33550 wurde diese entfert. Im Kapitel Content-Security-Policy beschreibe ich eine Möglichkeit, die Reports per E-Mail zu erhalten.

Joomla 4 Plugin System - HTTP Headers

Ich beschreibe die wichtigsten HTTP Header und die Konfiguration in Joomla 4.

Vorweg: Wer seine Website unter localhost testet, wird feststellen, dass nicht alle hier beschriebenen Funktionen lokal testbar sind.

HTTP Security Header im Detail

Die folgenden Security Header sind HTTP Response Header, welche der Webserver mit den Daten der Webseite an den Webbrowser übergibt. Daraufhin aktiviert der Browser Sicherheitsfunktionen.

Heausgehobene HTTP Header im Joomla 4 Plugins HTTP Header

Im Joomla Plugin werden die drei Header X-Frame-Options, Referrer-Policy und Cross-Origin-Opener-Policy im oberen Bereich angezeigt und der Header Strict-Transport-Security ist in einem eigenen Tabulator konfigurierbar.

X-Frame-Options

Der X-Frame-Options Header verhindert Clickjacking. Diese Technik lädt eine fremde Website über ein iframe-Tag in die eigene. Ziel ist es, einen Benutzer dazu zu bringen, sensible Daten preiszugeben – zum Beispiel Logindaten. Sobald eine Site versucht, eine andere als iframe zu laden, überprüft der Browser die einzubettende Website. Wenn diese den X-Frame-Options Header setzt, wird die Seite nicht geladen.

Der Header bietet drei mögliche Richtlinien: DENY, SAMEORIGIN, und ALLOW-FROM.

In Joomla 4 ist der Header auf unterschiedliche Arten setzbar. Zum einen gibt es eine eigene Option X-Frame-Options. Wenn die aktiviert ist, setzt das Plugin den Header mit der Richtlinie SAMEORIGIN.

X-Frame-Option in der Joomla 4 Content Security Policy

Wird ALLOW-FROM oder DENY benötigt, ist dies im Plugin konfigurierbar:

X-Frame-Option in der Joomla 4 Content Security Policy

Zusätzlich ist das Setzten des Headers per .htaccess-Datei möglich:

<IfModule mod_headers.c>
  Header always set X-Frame-Options "DENY" "expr=%{CONTENT_TYPE} =~ m#text/html#i"
</IfModule>

Achtung: Wenn du die Option im oberen Bereich aktiviert hast, wird immer SAMEORIGIN gesetzt. Wenn du die ALLOW-FROM oder DENY im unteren Bereich manuell konfigurierst, dann ist erforderlich, die Option im oberen Bereich zu deaktivieren.

X-Frame-Option in der Joomla 4 Content Security Policy

Referrer-Policy

Referrer-Policy weißt den Browser an, den Referer zu entfernen und nicht an die nachfolgende Site zu übermitteln.

Der Referer Anfrage-Header beinhaltet die Adresse von der vorher besuchten Webseite, welche einen Link zur aktuell angefragten Seite beinhaltet. Der Referer-Header erlaubt es Servern zu sehen, von wo die Personen sie Besuchen und diese Daten zum Beispiel zur Analyse, zum Logging oder zum Caching zu benutzen.

Im Joomla Plugin sind alle möglichen Optionen in einem Dropdown ausgewählbar. Die Standardeinstellung im Plugin sieht die Option no-referrer-when-downgrade vor.

Referrer-Policy in der Joomla 4 Content Security Policy

Mittels .htaccess kann der Header ebenfalls gesetzt werden:

<IfModule mod_headers.c>
  Header always set Referrer-Policy "strict-origin-when-cross-origin" "expr=%{CONTENT_TYPE} =~ m#text\/(css|html|javascript)|application\/pdf|xml#i"
</IfModule>

Cross-Origin-Opener-Policy

Der Header Cross-Origin-Opener-Policy (COOP) bietet die Möglichkeit, einen neuen Browser-Kontext anzufordern, um sich besser von anderen, nicht vertrauenswürdigen Aufrufen zu isolieren.

Der Cross-Origin-Resource-Policy Header (CORP) erlaubt es Websites und Anwendungen, sich gegen bestimmte Cross-Origin-Anforderungen zu schützen.

Cross-Origin Resource Sharing (CORS) ist ein HTTP-Header-basierter Mechanismus, der es einem Server erlaubt, andere Ursprünge (Domäne, Schema oder Port) als seinen eigenen anzugeben, von denen ein Browser das Laden von Ressourcen erlauben soll.

Mit der Cross-Origin Embedder Policy (COEP) wird verhindert, Anfragen nicht gleichen Ursprungs zu laden, es sei denn, dies ist ausdrücklich über CORS oder CORP erlaubt.

Mittels .htaccess kann der Header ebenfalls gesetzt werden.

Strict-Transport-Security

Der Strict-Transport-Security (HSTS) Header ist im Plugin in einem eigenen Tabulator konfigurierbar. Er bietet eine zusätzliche Absicherung aller Sites, die mit HTTPS verschlüsselt sind. Ist der Header gesetzt, lehnt der Browser alle unverschlüsselten HTTP-Verbindungen ab.

Bei Seiten, die von HTTP auf HTTPS umgestellt wurden, ist die Wahrscheinlichkeit hoch, dass sich ein Link findet, der nicht mit dem zusätzlichen S versehen ist. Ohne HSTS würde dieser Link unverschlüsselt via HTTP weitergeleitet. Mit HSTS ausgestattete Websites liefern alle Inhalte ohne Ausnahme per HTTPS aus. Links werden umgeschrieben. So finden potenzielle Angreifer nichts Unverschlüsseltes in die Übermittlung.

Im Plugin ist beispielsweise der Wert max-age=31536000; includeSubDomains konfigurierbar. Das folgende bild zeigt die Konfiguration über die Option Force HTTP Headers.

Strict-Transport-Security in der Joomla 4 Content Security Policy

max-age weißt den Browser an, die Domain zu speichern. Der Wert 31536000 steht in Sekunden und entspricht einem Jahr. Mit der Option includeSubDomains weitet der Browser die Funktion auf alle Subdomains aus.

Wenn preload aktiviert ist, wird die Domain in der Preloadliste gespeichert.

Per .htaccess ist der Header wie folgt zu aktivieren:

<IfModule mod_headers.c>
  # Header always set
  Strict-Transport-Security "max-age=16070400; includeSubDomains" "expr=%{HTTPS} == 'on'"
  # (1) Enable your site for HSTS preload inclusion.
  # Header always set
  Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" "expr=%{HTTPS} == 'on'"
</IfModule>

Trotz des Nutzens steht HSTS in der Kritik, da Seitenbetreiber darüber in der Lage sind, Nutzerinformationen auszulesen. Zwar ist der Zugriff kompliziert, aber möglich.

Weitere Plugins im Bereich Force HTTP Headers

HTTP Header Feature-Policy

Der HTTP Header Feature-Policy ist relativ jung und weitreichend. Er teilt dem Browser mit, welche Funktionen die Site benötigt. Wenn kein Zugriff auf das Mikrofon notwendig ist, hat ein möglicher Angreifer keinen Zugriff auf diese Browser-Funktionen - vorausgesetzt der Header ist korrekt gesetzt.

Der Aufbau ist simpel:

Feature-Policy: <directive> <allowlist>

Die steuerbaren Features (Direktiven), , werden bisher nicht alle in allen Browsern unterstützt..

Über das Joomla Plugin ist der Header wie folgt konfigurierbar:

Strict-Transport-Security in der Joomla 4 Content Security Policy

Mittels .htaccess sieht der Eintrag für ein Verbot von microphone und geolocation wie folgt aus:

<IfModule mod_headers.c>
  Header always set Feature-Policy microphone 'none'; geolocation 'none'
</IfModule>

Expect-CT

Der Expect-CT Header erlaubt es Webseiten, die Anforderungen der Certificate Transparency zu erzwingen.

Wenn eine Webseite die Verwendung des Expect-CT Headers aktiviert überprüft der Browser jedes im Zusammenhang mit der Webseite verwendete Zertifikat in öffentlichen CT Protokollen.

Content-Security-Policy

Die Content-Security-Policy oder CSP ist das Tüpfelchen auf das I der HTTP Header.

Ohne CSP lädt ein Browser alle Inhalte, egal von wo. Das ist in vielen Fällen hilfreich. Problematisch ist, dass nicht jede Site vertrauenswürdig ist. Ich meine hiermit das Aufrufen bösartigen Scriptcodes per Cross Site Scripting (XSS). Das Gefährliche ist, dass man als Websitebetreiber die Dinge nicht in der Hand hat, wenn fremde Inhalte aufrufbar sind. Dann reicht es nämlich, wenn der Angreifer eine verlinkte Site mit Schadcode verunreinigte.

CSP bietet einen hohen Schutz, erfordert dafür Sachkenntnis. Im Grund genommen legt man eine Liste aller Ressourcen an, welche die Webseite benötigt. Alles andere wird vom Browser blockiert. Hier wird deutlich: Wer nicht weiß, was er tut, kann seine Website per Content-Security-Policy lahm legen. In der restriktivsten Einstellung lässt der Browser nur Inhalte zu, die von der aufrufenden Domain selbst (self) stammen.

Mit Joomla 4.0 eliminierte man im Joomla Core Inline-Skripte und Styles weitestgehend. Leider verwenden Erweiterungen weiterhin Inline-JavaScript und Inline CSS Styles. Daher ist das Laden von Inline Elmeneten meist erforderlich und darf nicht unterbunten werden. Aus diesem Grund ist mit einer Joomla Website in der Regel nur ein A Rating und kein A+ Rating erreichbar.

Der Header ist wie folgt aufgebaut:

Content-Security-Policy-(Report-Only) <directive> <allowlist>; <directive> <allowlist>;

Die Liste der möglichen Direktiven ist lang und wird von allen gängigen Browsers unterstützt.

Bei der Implementierung der Content-Security-Policy ist es sinnvoll, den Report-Only Modus zu aktivieren und einen reporting Endpoint aufzusetzen. An diesen Endpoint schickt der Browser alle Verletzungen der CSP. So ist die Website anpassbar, bevor die Regel scharf geschaltet wird und Websitefunktionen nicht mehr arbeiten. Empfehlenswert ist der Einsatz dieser Direktive nur dann, wenn man weiß, was man bewirkt. Im schlimmsten Fall ist am Ende der Joomla Administrationsbereich nicht mehr funktionsfähig.

Wenn man einen Report per E-Mail erhalten möchte, bietet das Skript unter der Adresse https://github.com/zero-24/csp-reporter-php eine Möglichkeit.

Das Setzen der Content-Security-Policy in einer .htaccess sieht beispielweise wie folgt aus:

<IfModule mod_headers.c>
  Content-Security-Policy "default-src 'self'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests" "expr=%{CONTENT_TYPE} =~ m#text\/(html|javascript)|application\/pdf|xml#i"
</IfModule>

Viele Sites beinhalten Inline-Stile und Inline-Skripte, so dass es erforderlich ist, dass man unsafe-inline hinzufügt, damit die Website korrekt arbeitet.

Weitere Header

X-Content-Type-Options

Der Header X-Content-Type-Options ist unkompliziert zu konfigurieren, seit Joomla 3.9.13 in der Joomla Core .htaccess enthalten und wird für alle Joomla Webseiten empfohlen.

Es gibt einen gültigen Wert. Dies ist nosniff. Ist der Header gesetzt, versucht der Browser nicht, den Mime Type (Dateitype) einer Datei zu erraten. Dies ist bei heutigen Webseiten nicht mehr notwendig und führt zu unnötigen Sicherheitsproblemen.

Idealerweise wird dieser Header in der Datei .htaccess gesetzt. So ist die Sicherheitsfunktion unabhängig von Joomla auf Webserver-Ebenen aktiviert:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
</IfModule>

X-XSS-Protection

Diesen Header erwähne ich der Vollständigkeit halber. Er ist im Joomla 4 Backend nicht konfigurierbar. Der HTTP X-XSS-Protection Header war dazu gedacht im Browser einen XSS Auditor zu aktivieren. Moderne Browser berücksichtigen diesen Header [nicht mehr]https://portswigger.net/daily-swig/google-deprecates-xss-auditor-for-chrome).

Die empfohlene Konfiguration für ältere Browser ist: 1; mode=block. In Joomla 4 ist der Header ausschließlich über die Datei .htaccess konfigurierbar. Direkt mit der .htaccess Datei wird der Header wie folgt gesetzt:

<IfModule mod_headers.c>
  Header always set X-XSS-Protection 1; mode=block
</IfModule>

Weitere Links

Joomla Dokumentation

Joomla Dokumentation

csp-cheat-sheet

Die Seite scotthelme.co.uk bietet eine Übersicht in englischer Sprache über alle unterstützten Funktionen und Direktiven in der Content Security Policy. Sie kann als Kurzreferenz verwendet werden, um gültige und ungültige Direktiven und Werte zu identifizieren und enthält Beispielrichtlinien und Anleitungen zur effektiven Verwendung von CSP.

CSP-Auswerter

Der CSP Evaluator ermöglicht es Entwicklern und Sicherheitsexperten zu überprüfen, ob eine Content Security Policy (CSP) eine starke Mitigation gegen Cross-Site-Scripting-Angriffe darstellt. Er unterstützt den Prozess der Überprüfung von CSP-Richtlinien, der normalerweise eine manuelle Aufgabe ist, und hilft, subtile CSP-Umgehungen zu identifizieren, die den Wert einer Richtlinie untergraben. Die Prüfungen des CSP Evaluators basieren auf einer groß angelegten Studie und sollen Entwicklern helfen, ihre CSP zu härten und die Sicherheit ihrer Anwendungen zu verbessern. Dieses Tool (auch als Chrome-Erweiterung verfügbar) wird nur für die Bequemlichkeit von Entwicklern zur Verfügung gestellt und Google gibt keine Garantien oder Gewährleistungen für dieses Tool.

Ändere diesen Beitrag

Comments