HTTP-Header

Magazinbeitrag

Dieser Artikel basiert auf einem Artikel von Brendan Hedges im Joomla! Community Magazine aus der Ausgabe Mai 2022. Obwohl er für Joomla 4 geschrieben wurde, gilt der Inhalt gleichermaßen für Joomla 5.

Für diejenigen, die dieses Thema schwer verständlich finden, gibt es einen aufschlussreichen Artikel von Scott Helme zu Content Security Policy - An Introduction.

Joomlas neues HTTP-Header-Plugin für J4

Im Anschluss an den Artikel des letzten Monats über Sicherheit, Passwörter und Joomlas WebAuthn-Plugin betrachten wir diesen Monat ein weiteres Joomla-Sicherheitsmerkmal, das mit J4 eingeführt wurde. Es handelt sich um das HTTP-Headers-Plugin, das jetzt Teil der Kernfunktionen von Joomla ist.

Das Internet entwickelt sich ständig weiter, und Joomla ist dabei nie weit zurück. Deshalb habe ich es als meine bevorzugte Plattform für die Webentwicklung gewählt. Egal, ob Ihre Website eine kleine Website für ein Familienunternehmen oder eine voll ausgebaute E-Commerce-Plattform mit Millionenumsätzen ist, das Joomla-Framework hat für jeden etwas zu bieten und setzt stets auf die Einführung neuer Technologien. Manche davon sind sogar bahnbrechend.

Die Einführung des HTTP-Headers-Plugins im Kern von Joomla 4 ist ein enormer Fortschritt dabei, Ihre Website vor Angriffen und bösartigen Aktivitäten zu schützen.

Dieses Systemsicherheits-Plugin hilft Website-Betreibern, die HTTP-Sicherheitsheader bequem über das vertraute Backend von Joomla zu konfigurieren, anstatt in der htaccess-Datei oder anderen Konfigurationsdateien herumwühlen zu müssen. Oder, noch schlimmer, im Cpanel Ihres Webhosters.

Sehen Sie sich an, wie kompliziert die Einrichtung im Cpanel ist, und sagen Sie mir, dass Sie dabei keinen Fehler machen würden! Und das unter der Annahme, dass Sie, sobald das Framework in Apache installiert und die Verzeichnisse angelegt sind, auch das richtige Format kennen, um die gewünschten HTTP-Header hinzuzufügen.

Wie oft haben Sie schon versucht, einen htaccess-Befehl umzusetzen, nur um dann beim Neuladen Ihrer Website mit einem http500-Fehler konfrontiert zu werden?

Das größte Problem dabei ist, dass Ihre Website nicht mehr funktioniert, wenn das Format Ihres HTTP-Headers nicht perfekt stimmt.

Selbst dann funktioniert das, was bei einer Website klappt, nicht zwangsläufig bei einer anderen. Ein gutes Beispiel dafür ist meine htaccess-Datei und die Art und Weise, wie ich den Browser dazu bringe, eine Nicht-www-https-Version meiner Website zu laden:

##www to non www and http to https mixin
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://mywebsite.co.uk%{REQUEST_URI} [R=301,L,NE]
##End www to non www and http to https mixin

Das hat bei meinem vorherigen Hosting-Anbieter hervorragend funktioniert. Aber als ich zu einem anderen Anbieter wechselte, funktionierte es nicht mehr. Wer soll das verstehen!

Der htaccess-Code, den ich jetzt verwenden muss, um das gleiche Ergebnis zu erzielen, sieht so aus:

##www to non www and http to https mixin
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
##End www to non www and http to https mixin

Verwirrend, oder? Und wenn man bei der Formatierung auch nur einen einzigen Fehler macht: BAM! Die Website ist kaputt! Zumindest so lange, bis der Code korrigiert wurde.

Deshalb bedeutet es weniger Frustration, weniger verschwendete Zeit beim Googeln der eigenen Fehler und mehr Zeit zum Feiern, wenn man sich zurücklehnt und die neue Website bewundert, wenn man die Dinge einfach hält – als Teil des Joomla-Kerns.

Schauen wir uns also an, was HTTP-Header eigentlich sind, wie man das Plugin findet und was man damit machen kann. Es sei an dieser Stelle jedoch erwähnt, dass es sich bei dieser Joomla-Funktion um eine fortgeschrittene Funktion handelt, die eher für datensensible Websites geeignet ist als für die neue Website, die man liebevoll über süße Kätzchen erstellt hat. Allerdings sollten auch einfache Websites so sicher wie möglich sein, um die Ausführung von bösartigem Code zu verhindern, nachdem die Website gehackt wurde.

Was sind HTTP-Header?

HTTP-Header dürfen nicht mit dem <head>-Bereich des HTML-Dokuments verwechselt werden. Sie sind etwas völlig anderes. HTTP-Header sind die Vorrede zwischen dem Webserver und dem Browser. Eine Reihe von Anweisungen, die dem Browser mitteilen, was – oder vor allem was nicht – dem Besucher angezeigt werden soll.

Die HTTP-Header und wie sie sich auf einzelne HTML-Objekte beziehen, lassen sich in den DEV-Tools des Browsers einsehen. In Google Chrome die DEV-Tools öffnen, dann den Reiter „Netzwerk“. Nun die Webseite neu laden und ein HTML-Element im linken Bereich anklicken. Im rechten Bereich wird dann der HTTP-Header für dieses Element angezeigt.

Im Bild unten ist zu sehen, dass das markierte Bild einen HTTP-Status von 200 zurückgibt, der Browser hat es also gefunden. Außerdem gibt es eine Reihe weiterer Informationen zu diesem Element, wie zum Beispiel Dateigröße und Bearbeitungsdaten.

Wenn eines der HTML-Elemente nicht angezeigt werden konnte, lässt sich möglicherweise auch in den HTTP-Headern ein Hinweis auf den Grund finden. In diesem Beispiel wurde das zweite Bild nicht angezeigt, und aus den im rechten Bereich angezeigten Informationen ist ersichtlich, dass keine HTTP-Header-Informationen vorhanden sind.

Außer der kryptischen Meldung:

Referrer Policy: 'strict-origin-when-cross-origin'

„Strict-origin-when-cross-origin“ bedeutet lediglich, dass bei einem HTML-Element (in diesem Fall ein Bild), das von einer anderen Quelle (nicht dem eigenen Server) geliefert wird, die zu diesem Zeitpunkt festgelegte HTTP-Header-Richtlinie eingehalten werden muss. In diesem Beispiel weisen die im Joomla-Plugin festgelegten HTTP-Header alle Bilder zurück, die nicht entweder von dieser Website oder einer anderen Website stammen, die ausdrücklich in den HTTP-Header-Parametern des Joomla-HTTP-Headers-Plugins „eingeschlossen“ ist.

Wenn das Bild also aus dem HTML-Dokument aufgerufen wird, weist der Browser es zurück und es wird nicht geladen.

Das unterscheidet sich davon, dass es nicht gefunden wird und eine HTTP-Fehlermeldung „404 nicht gefunden“ zurückgegeben wird. In diesem Fall wird weiterhin auf dem Server, der das Bild hostet, danach gesucht, aber der Browser hat es nicht gefunden.

Was das Joomla-HTTP-Headers-Plugin macht

Abgesehen davon, dass sie dem Browser mitteilen, was angezeigt werden soll, und allgemeine Informationen über das HTML-Dokument zurückgeben, helfen HTTP-Header dabei, Angriffe und Sicherheitslücken auf der eigenen Joomla-Website zu verringern. Genau hier kommt das Joomla-HTTP-Headers-Plugin ins Spiel. Es erreicht dies, indem es HTML-Inhalte explizit auf Grundlage der Einstellungen im Joomla-HTTP-Headers-Plugin selbst anzeigt.

Durch das Hinzufügen zusätzlicher, sicherheitsbasierter HTTP-Header zur eigenen Joomla-Website mit dem HTTP-Header-Plugin wird eine weitere Sicherheitsebene für die Joomla-Website geschaffen.

Das ist wichtig, denn standardmäßig zeigt eine HTML-Webseite dem Besucher ihren gesamten Inhalt an, egal ob gut oder schlecht – es sei denn, ihr wird in den HTTP-Headern der Webseite explizit gesagt, dies nicht zu tun. Das Plugin ermöglicht dies, indem es erlaubt, die erweiterten Sicherheitsoptionen der Content-Security-Policy für die Website zu konfigurieren. Das Plugin kann je nach Anforderungen für jede Website unterschiedlich konfiguriert werden und ist somit eine wirklich flexible Waffe im Arsenal gegen Hacker.

Warum benötige ich dieses Plugin?

In einer idealen Welt bräuchte man es nicht. In der Welt, in der wir leben, gibt es jedoch viel zu viele skrupellose Menschen, die versuchen, auf Kosten der Unschuldigen und Ahnungslosen Geld zu verdienen. In unserer Welt nennen wir diese Menschen Hacker. Hacker tun alles, um Schwachstellen in Software zum finanziellen Vorteil auszunutzen, oft zum Schaden des Website-Betreibers.

Durch die Verwendung des Joomla-HTTP-Header-Plugins, um zu steuern, welche Inhalte den Besuchern ausgeliefert werden, verringert sich die Wahrscheinlichkeit, dass Hacker über veraltete, anfällige Plugins bösartige Website-Inhalte an die Besucher ausliefern können. Dies trägt dazu bei, bösartige Skript-Injektionen auf der Website zu verhindern.

Also, denken wir für einen Moment über diese hypothetische Situation nach.

Man hat eine schöne Joomla-3-Website. Sie wurde vor 5 Jahren erstellt und sieht immer noch gut aus und funktioniert einwandfrei. Alle Komponenten, Plugins und Module sind auf dem neuesten Stand. Perfekt, oder?

Nun, nicht ganz, denn als die Website vor 5 Jahren erstellt wurde, wurde das trendige Foo-Bar-Plugin installiert, um „FOO BAR“ auf der Startseite anzuzeigen. Es sah zunächst cool aus, aber nach einer Weile wurde es sich anders überlegt und der Shortcode des Plugins {foo}FOO - BAR{/bar} aus dem Beitrag der Startseite gelöscht.

Aber hier liegt das Problem: Das Plugin selbst wurde weder deaktiviert noch deinstalliert, und seine Verwendung geriet in Vergessenheit. Das ist etwas, das wir uns wohl ALLE schon einmal haben zuschulden kommen lassen.

Schnellvorlauf zu heute, 5 Jahre später: Dieses Plugin ist immer noch da, veröffentlicht und aktiv auf Ihrer Website, wurde aber seit 5 Jahren nicht mehr aktualisiert, weil Sie das Plugin längst vergessen haben oder der Autor den Support eingestellt hat. Nun hat ein übel gesinnter Zeitgenosse bemerkt, dass dieses Plugin eine Sicherheitslücke aufweist, die ausgenutzt werden kann, um einen Cross-Site-Scripting (XSS)-Angriff auf Ihre Website zu starten und Ihre ahnungslosen Besucher zu Opfern zu machen.

Cross-Site-Scripting, auch bekannt als XSS, ist eine Sicherheitslücke auf Ihrer Website, die es einem Angreifer ermöglicht, die Interaktionen Ihrer Benutzer mit Ihrer nun verwundbaren Website zu kompromittieren.

Der Angreifer/Hacker nutzt XSS, um Ihre verwundbare Website auszunutzen und ein bösartiges Skript an Ihren ahnungslosen Benutzer zu senden. Da das Skript von Ihrer Website stammt, weiß oder vermutet der Browser des Benutzers nicht, dass dem Skript nicht vertraut werden sollte, und führt es aus, wenn die Webseite geladen und geöffnet wird.

Auf diese Weise ausgeführte bösartige Skripte können viele Probleme für Ihren Benutzer verursachen, vom Diebstahl von Anmeldedaten und Benutzernamen, die in Cookies gespeichert sind, bis hin zur Weiterleitung Ihres Benutzers auf gefälschte Phishing-Websites. Skripte können sogar das Erscheinungsbild der Webseite, die Ihre Website ausliefert, verändern und Ihnen andere Werbung anzeigen.

Die Verwendung des HTTP-Headers-Plugin von Joomla hilft, Cross-Site-Scripting zu verhindern, indem sichergestellt wird, dass nur die Skripte und Inhalte, die Sie Ihrem Besucher bereitstellen möchten, tatsächlich ausgeliefert werden. Alles andere wird blockiert.

Im obigen Beispiel hätten Sie also das HTTP-Headers-Plugin so konfigurieren können, dass nur die JavaScript-Dateien (Skripte) Ihrer Website aus einem bestimmten Verzeichnis oder vielleicht einem CDN, falls Sie eines verwenden, ausgeliefert werden, um den Angriff zu verhindern.

Sie könnten auch verhindern, dass die Website Inline-JavaScript ausführt, das in das HTML eingebettet ist. Beachten Sie jedoch, dass dies je nach Gestaltung Ihres Website-HTMLs später zu Problemen führen kann.

Dies würde dann helfen, die Ausführung von bösartigem JavaScript-Code auf Ihrer Website zu verhindern. Selbst wenn Ihr verwundbares Foo-Bar-Plugin ursprünglich dafür verantwortlich war, dass ein Hacker bösartigen Code in Ihre Website einschleusen konnte.

Hinweis:

Häufige Schwachstellen auf Websites, die anfällig für XSS-Angriffe sind, sind Benutzereingabeformulare (Benutzeranmeldeseiten, Newsletter-Anmeldeformulare, Kontaktformulare usw.) ohne Validierung und Verschlüsselung.

Wo befindet sich das HTTP-Headers-Plugin?

Das HTTP-Headers-Plugin von Joomla finden Sie zusammen mit allen anderen Joomla-Plugins, und der Zugriff erfolgt genau auf die Weise, die Sie bereits gewohnt sind.

Verwendung des HTTP-Headers-Plugin

Die Verwendung des HTTP-Plugins von Joomla ist relativ unkompliziert, obwohl es eine gute Idee sein kann, sich vor Änderungen an den Standardeinstellungen mit einigen Fachbegriffen zu dessen Verwendung vertraut zu machen. Einige davon dürften Ihnen allerdings bereits bekannt sein.

Zum Beispiel:

Im Umgang mit Bildern begegnet Ihnen der Begriff 'img-src', wobei 'img' sich auf Bilder und 'src' auf die gültige Quelle des Bildes bezieht. Diese Begriffe sind uns bereits aus grundlegendem HTML vertraut.

Am Ende dieses Artikels finden Sie eine Liste hilfreicher Websites mit zusätzlichen Informationen, die Ihnen die Verwendung dieses Joomla-Plugins erleichtern.

HTTP-Headers-Plugin – Einstellungen – Tab 1

Wenn Sie das Plugin öffnen, wird zunächst der Tab mit den grundlegenden Einstellungen des Plugins angezeigt. Hier können Sie Anpassungen an X-Frame Options, der Referrer-Policy, Cross-Origin-Opener-Policy sowie Force HTTP Headers vornehmen. Es gibt außerdem einige Links zu weiteren Informationen, die Ihnen helfen, diese Einträge genauer zu verstehen.

Schauen wir uns jeden dieser Punkte der Reihe nach an.

X-Frame Options

Die erste Einstellung betrifft die X-Frame Options. Sie ist standardmäßig aktiviert.

Diese Option legt fest, ob der Inhalt der eigenen Website auf einer anderen Website in einem <frame>, <iframe>, <embed> oder <object> angezeigt werden darf. Wird diese Option deaktiviert, kann jede beliebige andere Website die eigene Website in einem iframe anzeigen.

Sobald aktiviert, wird den Website-Headern ein ‘x-frame-options: SAMEORIGIN’-Tag hinzugefügt. Dieses Tag erlaubt weiterhin, eigene Inhalte in einem <frame>, <iframe>, <embed> oder <object> auf der eigenen Website anzuzeigen. Aber niemand sonst kann die eigenen Inhalte in einem <iframe> auf seiner eigenen Website anzeigen.

Der X-Frame Option Header hilft dabei, die eigene Website und deren Benutzer vor ‘Click Jacking’-Angriffen zu schützen. Dabei platziert ein Angreifer ein <iframe> auf seiner eigenen Website und setzt als Quelle des <iframe> die eigene Website. Anschließend legt der Angreifer mehrere transparente Ebenen seiner eigenen Website darüber.

Dies verleitet einen Benutzer dazu, auf eine Schaltfläche oder einen Link auf der transparenten oberen Ebene zu klicken, da der Benutzer glaubt, auf einen Link im darunterliegenden iframe zu klicken.

Der Angreifer „entführt“ somit Klicks, die eigentlich für die ursprüngliche eingerahmte Seite bestimmt waren, und leitet sie auf eine andere Webseite um.

Schwerwiegender noch: Ähnliche Methoden können verwendet werden, um Tastatureingaben für Passwort- und Benutzernamen-Anmeldedaten von E-Mail-Konten, Social-Media-Konten und natürlich dem eigenen Bankkonto abzugreifen.

Die meisten modernen Browser unterstützen die X-Frame Options, was von Vorteil ist. Daher wird empfohlen, diese Einstellung im HTTP-Headers-Plugin zu aktivieren, um die Benutzer davor zu schützen, Opfer von 'Click Jacking' zu werden.

Die meisten modernen Browser unterstützen die X-Frame Options.

Referrer-Policy

Der nächste Punkt auf der Liste im ersten Tab ist die Referrer-Policy. Diese legt, falls aktiviert, fest, wie viele der potenziellen Website-Daten an eine andere Website übertragen werden, wenn auf der eigenen Website ein Link oder ein anderes HTML-Objekt angeklickt wird.

Üblicherweise sieht man dies als HTML-Attribut bei <a>-Tags, wobei ein Link etwa wie folgt formatiert sein könnte: <a href=”https://someplace.com” rel=”noreferrer”>Click Me</a>. Das noreferrer-Tag hält die Details der sendenden Webseite vor der empfangenden Webseite geheim. Dies geschieht, indem die Referral-Informationen aus dem HTTP-Header der Webseite entfernt werden.

Sich bewusst zu sein, welche Daten die eigene Website an eine verlinkte Website ‚preisgeben‘ könnte, ist ein wichtiger Bestandteil der Absicherung der eigenen Website und ihrer Benutzer.

Dies gilt besonders dann, wenn Benutzerregistrierungen erlaubt sind, sensible Daten enthalten sind oder die Website Geldtransaktionen abwickelt. Das HTTP-Headers-Plugin von Joomla hilft dabei, dies auf globaler Ebene zu steuern, anstatt auf der Ebene einzelner Links.

Standardmäßig ist die Referrer Policy der Website auf ‘strict-origin-when-cross-origin’ gesetzt. Dies blockiert keine der Referrer-Daten der ursprünglichen Webseite, außer wenn sie an eine weniger sichere http-Seite gesendet werden. Da heutzutage jedoch die meisten Webseiten https verwenden, ist dies inzwischen ein größeres Problem als früher.

Es gibt natürlich viele harmlose Verwendungszwecke für diese ‚durchgesickerten‘ Daten, falls keine Referrer Policy für die eigene Website festgelegt wird. Dazu könnten Daten gehören, die von der verlinkten Website für Analysen, Protokollierung oder optimiertes Caching gesammelt werden.

Leider nutzt nicht jede verlinkte Website die ‚durchgesickerten‘ Daten für solche harmlosen Zwecke. Die folgende Situation dient als Beispiel.

Die meisten Websites, die eine Benutzerregistrierung erlauben, haben neben ihrem Anmeldeformular auf einer Anmelde-/Registrierungsseite einen Link zum Zurücksetzen des Passworts. Es ist auch wahrscheinlich, dass die Webseite weitere Links zu externen Websites, Social-Media-Links oder vielleicht einige ‚nützliche Links‘ im Footer enthält.

Diese führen alle aus der sicheren Umgebung heraus. Wenn nun keine Referrer Policy eingerichtet ist, ist es möglich, dass der Referrer-Header, der beim Klicken auf einen Link von dieser Anmeldeseite an eine dieser externen Websites gesendet wird, den Link zum Zurücksetzen des Passworts enthält. Ebenso wie andere Informationen, die mit dieser externen Website geteilt wurden.

Dies könnte ein Sicherheitsrisiko für den Benutzer darstellen, indem dessen Daten kompromittiert werden.

Aufgrund des potenziellen Sicherheitsrisikos bei dieser Art von datensensibler Seite ist es außerdem empfehlenswert, sämtliche Inhalte von Drittanbietern von der Seite zu entfernen. Dazu gehören alle Links und Inhalte, die in <iframes> eingebunden sind, wie etwa Social-Media-Widgets und YouTube-Videos. Denn auf dieser Seite eingegebene Daten könnten über den Referrer-Header an diese Websites gesendet werden, wenn auf das niedliche Katzenvideo geklickt wird, das gerade aufgetaucht ist.

Joomlas HTTP-Headers-Plugin behebt dieses Problem, indem es erlaubt, aus 8 Referrer Policies auszuwählen, um eine Referrer Policy für die eigene Website festzulegen. Jede mit eigenen Grenzen, wann und wie viele Daten geteilt werden.

Schauen wir uns diese genauer an. Es gibt eine ausgezeichnete Beschreibung davon auf der Mozilla-Headers-Seite, die sie wie folgt beschreibt:

• no-referrer
  Der Referrer-Header wird weggelassen: gesendete Anfragen enthalten keine Referrer-Informationen.
• no-referrer-when-downgrade
  Sendet den Ursprung, Pfad und die Abfragezeichenfolge im Referrer-Header, wenn die Protokollsicherheitsstufe gleich bleibt oder sich verbessert (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Der Referrer-Header wird nicht für Anfragen an weniger sichere Ziele gesendet (HTTPS→HTTP, HTTPS→file).
• origin
  Sendet nur den Ursprung im Referrer-Header. Zum Beispiel sendet ein Dokument unter https://example.com/page.html den Referrer https://example.com/.
• origin-when-cross-origin
  Bei einer Same-Origin-Anfrage auf derselben Protokollstufe (HTTP→HTTP, HTTPS→HTTPS) werden Ursprung, Pfad und Abfragezeichenfolge gesendet. Bei Cross-Origin-Anfragen und Anfragen an weniger sichere Ziele (HTTPS→HTTP) wird nur der Ursprung gesendet.
• same-origin
  Sendet Ursprung, Pfad und Abfragezeichenfolge bei Same-Origin-Anfragen. Der Referrer-Header wird nicht bei Cross-Origin-Anfragen gesendet.
• strict-origin
  Sendet nur den Ursprung, wenn die Protokollsicherheitsstufe gleich bleibt (HTTPS→HTTPS). Der Referrer-Header wird nicht an weniger sichere Ziele gesendet (HTTPS→HTTP).
• strict-origin-when-cross-origin (Standard)
  Beim Senden einer Same-Origin-Anfrage werden Origin, Pfad und Abfragezeichenfolge übermittelt. Bei Cross-Origin-Anfragen wird (nur) der Origin gesendet, wenn das Sicherheitsniveau des Protokolls gleich bleibt (HTTPS→HTTPS). Der Referrer-Header wird nicht an weniger sichere Ziele gesendet (HTTPS→HTTP). Hinweis: Dies ist die Standardrichtlinie, falls keine Richtlinie angegeben wird oder der angegebene Wert ungültig ist. Zuvor war no-referrer-when-downgrade der Standard.
• unsafe-url
  Origin, Pfad und Abfragezeichenfolge werden bei jeder Anfrage gesendet, unabhängig von der Sicherheit. Warnung: Diese Richtlinie kann potenziell private Informationen aus HTTPS-Ressourcenadressen an unsichere Ursprünge preisgeben. Die Auswirkungen dieser Einstellung sollten sorgfältig abgewogen werden.

Cross-Origin-Opener-Policy

Die dritte Option, die im ersten Tab festgelegt werden kann, ist die Cross Origin Opener Policy – ein browserbasiertes Sicherheitsmerkmal, mit dem unterschiedliche ‘Browser Context Groups' voneinander getrennt werden können.

Ein gutes Beispiel hierfür ist die Verwendung von Pop-ups. Dabei wird die ursprüngliche Browser-Context-Group (aller Text, Bilder, Links usw.) von einer neuen Browser-Context-Group getrennt, die erstellt und dann im Pop-up angezeigt wird.

Diese HTTP-Header-Option ist recht umfangreich und komplex, auch wenn es nur 3 Optionen gibt. Daher wird empfohlen, die untenstehenden Links aufzurufen, um besser zu verstehen, warum diese Option auf der Website gesetzt werden sollte. Ebenso lässt sich dort mehr über einige der erweiterten Funktionen erfahren, die verfügbar werden, sobald diese Option aktiv ist.

Die Cross Origin Opener Policy hilft, eine historische Lücke in der Art und Weise zu schließen, wie Browser Daten zwischen verschiedenen Context Groups austauschen, insbesondere wenn Pop-ups auf der Website verwendet werden.

Das Setzen der COOP hilft dabei, Bedrohungen der Datensicherheit zu mindern, eine bekannte davon wird als ‘Spectre’ bezeichnet. Spectre macht Daten, die in dieselbe Browsing-Context-Group wie der eigene Code geladen werden, potenziell für Hacker lesbar. Spectre ermöglicht es, die Zeit zu messen, die bestimmte Operationen benötigen. Dadurch können Hacker erraten, was sich im CPU-Cache befindet. Gelingt ihnen das, wissen sie, was sich im Prozessspeicher befindet. Damit erhalten sie Zugriff auf die Daten – die unter Umständen sensibel sein können.

COOP funktioniert, indem die ursprünglichen HTML-Dokumentdaten von den HTML-Daten getrennt werden, die in einem Pop-up aus dem ursprünglichen Dokument angezeigt würden. Dies hilft, das zu verhindern, was als Cross-Origin-Angriffe oder XS-Leaks bezeichnet wird.

Dieser Vorgang ähnelt dem bekannten rel="noopener", das bei gewöhnlichen Links verwendet wird. Im Gegensatz zu rel="noopener", das nur bei ausgehenden Links aktiv ist, beschränken Dokumente, bei denen die Cross-Origin-Opener-Policy durch das Joomla-Plugin im HTTP-Header gesetzt wurde, die Daten in beide Richtungen. Daher wird das HTML-Dokument mit einer aktiven COOP-Richtlinie keinen Verweis darauf im HTTP-Header haben, und die window.opener-Eigenschaft des HTTP-Headers des neuen Fensters wird auf null gesetzt.

Beim Festlegen dieser Option im Joomla-HTTP-Headers-Plugin stehen 3 Optionen zur Verfügung.

• unsafe-none
  Dies ist der Standardwert. Er erlaubt, dass Ihr Dokument der Browser Context Group seines Öffners hinzugefügt wird, es sei denn, der Öffner selbst hat eine Cross-Origin-Opener-Policy von same-origin oder same-origin-allow-pop-ups.
• same-origin-allow-popups
  Diese Option behält Verweise auf neu geöffnete Fenster oder Tabs, die entweder keine Cross-Origin-Opener-Policy setzen oder die sich durch das Setzen einer Cross-Origin-Opener-Policy von unsafe-none selbst von der Isolierung ausschließen.
• same-origin
  Isoliert die Browser Context Group nur auf Dokumente derselben Herkunft. Cross-Origin-Dokumente werden nicht in derselben Browser Context Group geladen.

Force HTTP Headers

Die letzte Option, auf die im ersten Tab eingegangen wird, ist Force HTTP Headers, was nicht mit „Force HTTPS“ in den allgemeinen Einstellungen von Joomla zu verwechseln ist.

Dieser Bereich des Joomla-HTTP-Header-Plugins ermöglicht es, bei Bedarf eine Auswahl an „weiteren“ Headern hinzuzufügen, die nicht ausdrücklich in den Plugin-Reitern aufgeführt sind, sowie die Einbindung bestimmter bereits enthaltener Header zu erzwingen.

Aus der Dropdown-Liste stehen derzeit 10 Optionen zur Verfügung. Es ist jedoch zu beachten, dass einige davon im Laufe der Zeit entfallen könnten, da sich die zugehörigen Header-Richtlinien ändern oder neu gestaltet werden könnten.

Die aktuellen HTTP-Header, die hier direkt festgelegt werden können, betreffen Folgendes:

Weitere Informationen zu jeder Funktion finden sich auf der Website der Mozilla Developers.

Content-Security-Policy (Liste)

Der Content-Security-Policy-Antwort-Header ermöglicht es Websites, die Ressourcen zu steuern, die ein Benutzer für jede Webseite laden darf. Die Richtlinien legen hauptsächlich Server-Ursprünge und Skript-Endpunkte fest. Dies hilft, Cross-Site-Scripting-Angriffe zu verhindern. Mozilla: Content-Security-Policy

Content-Security-Policy-Report-Only

Der HTTP-Header Content-Security-Policy-Report-Only ermöglicht es Webentwicklern, mit Richtlinien zu experimentieren, indem deren Auswirkungen überwacht (aber nicht erzwungen) werden. Mozilla: Content-Security-Policy-Report-Only

Cross-Origin-Opener-Policy (COOP)

Der HTTP-Antwort-Header Cross-Origin-Opener-Policy (COOP) stellt sicher, dass ein Top-Level-Dokument keine Browser Context Groups mit Dokumenten anderer Ursprünge teilt. Mozilla: Cross-Origin-Opener-Policy

COOP isoliert das Dokument prozessweise, sodass potenzielle Angreifer nicht auf das globale Objekt zugreifen können, selbst wenn sie es in einem Pop-up öffnen – dies verhindert eine Reihe von Cross-Origin-Angriffen, die als XS-Leaks bezeichnet werden.

Expect-CT (wird eingestellt)

Der Expect-CT-Header ermöglicht es Websites, sich für die Meldung und/oder Durchsetzung von Certificate-Transparency-Anforderungen zu entscheiden, um zu verhindern, dass fälschlich ausgestellte Zertifikate für diese Website unbemerkt bleiben. Mozilla: Expect-CT (wird eingestellt)

Feature-Policy (jetzt veraltet)

Der HTTP-Header Feature-Policy bietet einen Mechanismus, um die Nutzung von Browser-Funktionen im eigenen Frame sowie in Inhalten innerhalb von <iframe>-Elementen im Dokument zu erlauben oder zu verweigern. Mozilla: Feature-Policy

Permissions-Policy

Dies ist der Ersatz für die oben genannte Feature-Policy. Mozilla: Permissions-Policy (ersetzt die oben genannte Feature-Policy)

Referrer-Policy (in der Liste)

Der HTTP-Header Referrer-Policy steuert, wie viele Referrer-Informationen (die mit dem Referrer-Header gesendet werden) bei Anfragen enthalten sein sollen. Mozilla: Referrer-Policy

Report-To

Teil der Content-Security-Policy. Das Content-Security-Policy-Report-To-HTTP-Antwort-Header-Feld weist den User-Agent an, Meldeendpunkte für einen Ursprung zu speichern. Mozilla: Report-To

Die Report-To-Direktive soll die veraltete Report-URI-Direktive ersetzen; Report-To wird jedoch noch von den meisten Browsern nicht unterstützt.

Strict-Transport-Security

Der HTTP-Antwort-Header Strict-Transport-Security (oft als HSTS abgekürzt) teilt Browsern mit, dass auf die Website nur über HTTPS zugegriffen werden sollte und dass zukünftige Zugriffsversuche über HTTP automatisch in HTTPS umgewandelt werden sollten. Mozilla: Strict-Transport-Security

Dies ist sicherer als lediglich eine HTTP-zu-HTTPS-Weiterleitung (301) auf dem Server zu konfigurieren, bei der die anfängliche HTTP-Verbindung weiterhin anfällig für einen Man-in-the-Middle-Angriff ist.

X-Frame-Options (in der Liste)

Der HTTP-Antwort-Header X-Frame-Options gibt an, ob einem Browser erlaubt werden soll, eine Seite in einem <frame>, <iframe>, <embed> oder <object> darzustellen, oder nicht. Websites können dies nutzen, um Click-Jacking-Angriffe zu vermeiden, indem sichergestellt wird, dass ihre Inhalte nicht in andere Websites eingebettet werden.Mozilla: X-Frame-Options

Die zusätzliche Sicherheit wird nur geboten, wenn der Benutzer, der auf das Dokument zugreift, einen Browser verwendet, der X-Frame-Options unterstützt.

Der X-Frame-Options-Header hat untergeordnete Einträge namens frame-ancestors, die den Frame-Options-Header ersetzen. Wenn eine Ressource beide Richtlinien hat, wird die frame-ancestors-Richtlinie angewendet und die X-Frame-Options-Richtlinie ignoriert.

Im Feld HTTP Header Value können die gewünschten Werte festgelegt und entweder der eigenen Website, der Administratoroberfläche oder beiden zugewiesen werden.

HTTP-Headers-Plugin-Einstellungen – TAB 2

Strict-Transport-Security (HSTS)

Der Tab Strict Transport Security Policy ist standardmäßig deaktiviert.

Ich liebe es zu recherchieren. Denn manchmal stößt man auf einen echten OMG-Moment. Dies ist einer dieser Momente.

Wikipedia schreibt:

Netscape Communications entwickelte HTTPS 1994 für seinen Webbrowser Netscape Navigator. Ursprünglich wurde HTTPS mit dem SSL-Protokoll verwendet. Als sich SSL zu Transport Layer Security (TLS) weiterentwickelte, wurde HTTPS im Mai 2000 formal durch RFC 2818 spezifiziert. Google kündigte im Februar 2018 an, dass sein Chrome-Browser HTTP-Websites nach Juli 2018 als „Nicht sicher“ kennzeichnen würde. Dieser Schritt sollte Website-Betreiber dazu ermutigen, HTTPS zu implementieren, um das World Wide Web sicherer zu machen.“ ……

Wer hätte gedacht, dass Netscape die HTTPS-Protokolle schon vor so langer Zeit erfunden hat? Noch überraschender ist, wie lange es gedauert hat, es in das Internet zu implementieren, das wir heute kennen und lieben.

Seit Jahren haben sie uns überredet, unter Druck gesetzt und schließlich bedroht, HTTPS auf all unseren Websites zu implementieren. Die meisten von uns haben nachgegeben, und das World Wide Web ist nun endlich sicher. Oder etwa nicht?

Es gibt jedoch einige Nachzügler, Hartgesottene oder vergessene Websites, die ihre Inhalte immer noch nur über HTTP ausliefern, wenn auch mit einer Warnung „Diese Website ist nicht sicher“ von Google/Firefox usw.

Eine kurze Google-Suche brachte mehrere veraltete Listen dieser „nur-HTTP-schuldigen“ Websites zutage. Seit der Veröffentlichung dieser Listen haben zwar viele Websites auf HTTPS umgestellt. Dennoch gab es einige offensichtliche Ausnahmen von Organisationen, von denen man annehmen sollte, dass sie es besser wissen müssten.

Zum Beispiel:

• NGINX (http://nginx.org/)
• GNU (http://www.gnu.org/)
• Die University of Washington (http://www.washington.edu/)

Laut w3techs.com laufen etwa 20 % aller Websites noch ausschließlich über HTTP.

Warum ist das ein Problem?

Dies ist ein Problem, weil alle Daten, die von einem Benutzerbrowser gesendet und empfangen werden, abgefangen werden können. Dies ist als Man-in-the-Middle-Angriff bekannt. Das mag unwichtig erscheinen, wenn es auf der eigenen Website nur um Bilder niedlicher Kätzchen geht.

Aber selbst einfache Websites können Opfer von Hackern und Angreifern werden, die Click-Jacking und andere Cross-Origin-Angriffe durchführen, die Ihren Benutzern schaden.

Eine Website, die keine Benutzerdaten oder Anmeldeinformationen austauscht, sollte dennoch HTTPS verwenden.

Okay, zurück zum Thema.

Wie Sie bereits wissen, besteht der ganze Sinn von HTTPS darin, eine sichere Verbindung zwischen dem Browser des Benutzers und Ihrem Server herzustellen. Eine Verbindung, bei der jeder Datenaustausch in einer sicheren Umgebung stattfindet, die nicht von Dritten abgefangen und kopiert werden kann. Einem Man-in-the-Middle.

Aber wussten Sie, dass Ihre „sichere“ Verbindung nicht so sicher ist, wie Sie erwarten, sofern Ihr HTTPS-SSL-Zertifikat kein TLS verwendet? Nicht-TLS-HTTPS-Verbindungen sind weiterhin anfällig für Man-in-the-Middle-Angriffe.

Obwohl es sich um einen alten Blogbeitrag handelt, erklärt dieser Artikel anschaulich, wie ein Man-in-the-Middle-Angriff funktioniert.

Browser haben TLS inzwischen weitgehend übernommen.

Und TLS 1.3 ist nicht direkt mit früheren Versionen kompatibel, es sei denn, es wird im Kompatibilitätsmodus ausgeführt. Das könnte für manche ein Problem darstellen.

Die Verwendung des HTTP-Headers-Plugins von Joomla zur Handhabung von Strict-Transport-Security (HSTS) hilft, Man-in-the-Middle-Angriffe zu verringern, indem die Verwendung von TLS im Webbrowser Ihrer Besucher erzwungen wird. TLS stellt sicher, dass die gesamte Webkommunikation auf Client-Seite über eine sichere Transportschicht erfolgt.

Verwenden Sie eine 301-Weiterleitung, um die unsichere HTTP-Version Ihrer Website zur sicheren HTTPS-Version umzuleiten?

Die meisten Menschen tun dies. 301-Weiterleitungen sind Anweisungen, die die meisten Website-Betreiber in ihrer htaccess-Datei einrichten. Sie teilen Google mit, dass die Version der Website, die verwendet werden soll, die HTTPS-(sichere)-Version ist. Das Problem dabei ist, dass die 301-Weiterleitung lediglich eine URL-Weiterleitung ist, sodass Ihre Website weiterhin einen Teil der anfänglichen Verbindung über HTTP abwickelt.

Anders als bei Verbindungen zwischen einem Benutzer und einem Website-Server, die HSTS verwenden, bei denen der Server automatisch nur über HTTPS interagiert.

HSTS hat jedoch eine Schwachstelle, da die erste anfängliche Verbindung zwischen dem Browser des Benutzers und dem Website-Server noch über HTTP erfolgt. Aber alle nachfolgenden Verbindungen werden automatisch über HTTPS hergestellt, bis das Ablaufdatum des HTTP-Headers erreicht ist und dieser Header zurückgesetzt wird.

Dies unterscheidet sich von einer herkömmlichen 301-Weiterleitung, bei der jeder Seitenaufruf eine anfängliche HTTP-Anfrage enthält, um die HTTPS-Verbindung einzuleiten.

Es gibt eine Lösung für diese Schwachstelle in den HSTS-Einstellungen der HTTP-Header: Aktivieren Sie „Preload“.

Dadurch wird der Tag „Preload“ zum Antwort-Header hinzugefügt.

In den Einstellungen gibt es außerdem eine Link-Preload-Liste**. Dies ist eine Liste, die fest in viele moderne Browser integriert ist. Die Liste teilt dem Browser mit, dass die Verbindung zu example.com nur über HTTPS hergestellt werden darf. Dadurch entfällt sogar die Notwendigkeit, die anfängliche Verbindung über HTTP herzustellen.

Sobald HSTS im HTTP-Headers-Plugin von Joomla eingerichtet ist, werden alle notwendigen Angaben zum HTTP-Response-Header hinzugefügt. Dies teilt dem Browser jedes Benutzers, der versucht, eine Verbindung zum Server herzustellen, mit, dass alle Verbindungen über HTTPS erfolgen müssen, unabhängig davon, ob dies im HTML angegeben ist oder nicht.

Zusammenfassend lässt sich sagen, dass die Verwendung des HTTP-Headers-Plugins von Joomla zur Integration von HSTS, anstatt sich auf 301-Weiterleitungen zu verlassen, um Inhalte über HTTPS auszuliefern, eine wichtige Sicherheitsverbesserung darstellt. Eine Verbesserung, die hilft, Man-in-the-Middle-Angriffe zu verhindern, und den Benutzern eine sichere Umgebung bietet.

HSTS deckt die gesamte Domain ab, im Gegensatz zu einer 301-Weiterleitung, die nur einen bestimmten URI-Pfad abdeckt.

HSTS verwendet einen separaten Browser-Cache, der in der Regel getrennt ist, sodass er nicht einfach oder versehentlich gelöscht werden kann.

HSTS kann in einen Browser vorab geladen werden. Dies stellt sicher, dass ein Benutzer nur über HTTPS eine Verbindung zum Server herstellt, unabhängig davon, ob er die Website zuvor schon besucht hat.

HTTP-Headers-Plugin-Einstellungen – TAB 3

Content Security Policy (Tab 3)

Der Tab „Content Security Policy“ ist standardmäßig deaktiviert.

Wenn die Content Security Policy von Joomla über das HTTP-Headers-Plugin aktiviert wird, teilt man dem Browser der Besucher genau mit, welche Inhalte vom Server der Website geladen werden dürfen. Dies ist eine gute Möglichkeit sicherzustellen, dass nur die Inhalte ausgeliefert werden, die tatsächlich ausgeliefert werden sollen.

Eine wirksame Content Security Policy ist eine effektive Möglichkeit, Cross-Site-Scripting (XSS)- und Click-Jacking-Angriffe zu verhindern, die von der eigenen Website ausgehen.

Cross-Site-Scripting, auch bekannt als XSS-Angriff, ist ein Angriff auf eine Website, bei dem ein bösartiges Skript in eine ahnungslose und ansonsten vertrauenswürdige Website „eingeschleust“ wird. Angreifer suchen nach einem Schwachpunkt, der meist dort liegt, wo Benutzer Daten eingeben können.

Veraltete Komponenten, die Benutzereingaben zulassen, zum Beispiel nicht validierte Kommentarformulare, können Schwachstellen aufweisen, die bei einem Cross-Site-Scripting-Angriff ausgenutzt werden können. Deshalb ist es ratsam, Joomla-Komponenten immer zu aktualisieren, um solche Möglichkeiten zu minimieren.

Am Beispiel des infizierten Kommentarformulars:

Ihre Website verwendet am Ende eines Beitrags ein Kommentarformular, um die Diskussion der Nutzer zu sammeln, wie es viele Websites tun. Das ist großartig.

Ihre Kommentarerweiterung von dodgy-joomla-extensions.com funktioniert hervorragend und Ihre Nutzer lieben sie. Aber Sie haben sie seit 5 Jahren nicht aktualisiert und die Entwickler haben sie längst aufgegeben.

Nun, 5 Jahre später, stellt Herr Hacker fest, dass er aufgrund einer Schwachstelle im Code der Kommentarkomponente ein bösartiges Codefragment in einem Kommentar verstecken kann, das ansonsten harmlos aussieht.

Was dieser Code letztlich bewirkt, variiert, aber eines ist sicher: Jedes Mal, wenn Ihre harmlose Beitragsseite mit den Kommentaren geladen wird, wird auch dieser bösartige Code geladen und ausgeführt. Er ist schließlich Teil des HTML, und der Browser weiß nicht, dass er dort nicht hingehört oder nicht vertrauenswürdig ist.

Also wird der bösartige Code ausgeführt. Vielleicht prüft er Ihre Cookie-Daten. Vielleicht stiehlt er sensible Daten, die der Browser gespeichert hat. Oder vielleicht lädt er Werbung von Online-Casinos oder Erwachsenenwebsites. Vielleicht lädt er das HTML Ihrer harmlosen Webseite über niedliche Kätzchen komplett über eine externe JavaScript-Datei neu, um die Kreditkartendaten Ihrer Nutzer zu stehlen.

Tatsächlich kann an dieser Stelle ein Skript ausgeführt werden, um fast alles zu erreichen.

Eine gute Content Security Policy hilft, diese Art von Angriff zu verhindern, selbst wenn Ihre kompromittierte Kommentarerweiterung zum Ziel von Herrn Hacker wird.

Das gelingt, weil das Joomla HTTP-Headers-Plugin die CSP als HTTP-Antwort-Header ausliefert, der dem Browser explizit mitteilt, was geladen werden darf. In den Einstellungen des CSP-Tabs im HTTP-Headers-Plugin können direkt 28 Policy Directives angesteuert werden. Die Direktiven helfen, Ihre Website zu sichern, indem nur genehmigte Quellen für Ihre Dateien und Inhalte verwendet werden.

Das obige Angriffsbeispiel führte dazu, dass eine JavaScript-Datei von einer anderen Quelle geladen wurde, um die auf dem Bildschirm dargestellte HTML-Ausgabe zu verändern. Dies hätte verhindert werden können, indem die Direktive script-src 'self' zur CSP von Joomla im Plugin hinzugefügt worden wäre.

In diesem Beispiel lädt der Browser nur dann JavaScript-Dateien im HTML-Dokument, wenn sie von Ihrer Domain stammen. Alle anderen JavaScript-Dateien werden abgelehnt, einschließlich der von Herrn Hacker.

Dies trägt zwar zur Sicherung Ihrer Website bei, kann aber auch andere legitime JavaScript-Dateien blockieren, die Sie laden möchten, während die Webseite auf dem Bildschirm dargestellt wird. Diese externen Dateien können als Quellen auf einer Positivliste in derselben Direktive hinzugefügt werden. Wenn Sie beispielsweise Bootstrap von einem CDN verwenden, würden Sie hinzufügen:

script-src 'self' https://cdn.jsdelivr.net

Wenn Sie in diesem Beispiel Schwierigkeiten haben, Bootstrap vom CDN https://cdn.jsdelivr.net zu laden, könnten Sie versuchen, die vollständige URL zur benötigten Bootstrap-Datei hinzuzufügen. Ihre Direktive würde dann wie folgt formatiert: script-src 'self' https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.min.js.

Das Hinzufügen dieser externen Quellen ließe sich leichter umsetzen, wenn man eine neue Website von Grund auf aufbaut. Durchsucht man jedoch das gerenderte HTML seiner bestehenden Website mit den DEV-Tools, sollten sich alle bereits verwendeten externen Dateien finden und in die CSP aufnehmen lassen.

Beim Hinzufügen von Direktiven zur Content Security Policy im HTTP-Headers-Plugin gibt es eine Reihe von Kernwerten, mit denen sich festlegen lässt, was der Browser explizit laden soll. Dies sind die grundlegenden Werte, um eine erste Content Security Policy einzurichten.

Weitere Optionen stehen für einige der fortgeschritteneren Direktiven zur Verfügung; eine ausführlichere Liste und Beispiele für ihre Verwendung finden sich auf der Website des Content Security Policy (CSP) Quick Reference Guide.

• 'none' blockiert die Verwendung dieser Art von Ressource.
• 'self' entspricht dem aktuellen Ursprung (jedoch nicht Subdomains).
• 'unsafe-inline' erlaubt die Verwendung von Inline-JS und -CSS.
• 'unsafe-eval' erlaubt die Verwendung von Mechanismen wie eval().

Schauen wir uns also einige dieser Direktiven an. Hier ist eine Liste einiger der im Joomla-HTTP-Headers-Plugin verfügbaren Direktiven, zusammen mit einer kurzen Beschreibung, mit freundlicher Genehmigung von Content Security Policy. Es empfiehlt sich, diese Website für weitere Informationen und Beispiele zu besuchen.

default-src

Die Direktive default-src definiert die Standardrichtlinie zum Laden von Ressourcen wie JavaScript, Bildern, CSS, Schriftarten, AJAX-Anfragen, Frames, HTML5-Medien.
BEISPIEL DEFAULT-SRC-RICHTLINIE
default-src 'self' https://cdn.example.com

script-src

Definiert gültige Quellen für JavaScript.
BEISPIEL SCRIPT-SRC-RICHTLINIE
script-src 'self' https://js.example.com

style-src

Definiert gültige Quellen für Stylesheets bzw. CSS.
BEISPIEL STYLE-SRC-RICHTLINIE
style-src 'self' css.example.com

img-src

Definiert gültige Quellen für Bilder.
BEISPIEL IMG-SRC-RICHTLINIE
img-src 'self' https://img.example.com https://example.com

connect-src

Gilt für XMLHttpRequest (AJAX), WebSocket, fetch(), <a ping> oder EventSource. Ist dies nicht erlaubt, emuliert der Browser einen HTTP-Statuscode 400.
BEISPIEL CONNECT-SRC-RICHTLINIE
connect-src 'self'

font-src

Definiert gültige Quellen für Schriftressourcen (geladen über @font-face).
BEISPIEL FONT-SRC-RICHTLINIE
font-src https://font.example.com https://example.com

object-src

Definiert gültige Quellen für Plugins, z. B. <object>, <embed> oder <applet>.
BEISPIEL OBJECT-SRC-RICHTLINIE
object-src 'self'

media-src

Definiert gültige Quellen für Audio und Video, z. B. HTML5-<audio>-, <video>-Elemente.
BEISPIEL MEDIA-SRC-RICHTLINIE
media-src https://media.example.com

frame-src

Definiert gültige Quellen zum Laden von Frames. In CSP Level 2 wurde frame-src zugunsten der Direktive child-src als veraltet markiert. CSP Level 3 hat die Veraltung von frame-src wieder aufgehoben, wird jedoch weiterhin auf child-src zurückgreifen, falls dieses nicht vorhanden ist.
BEISPIEL FRAME-SRC-RICHTLINIE
frame-src 'self'

sandbox

Aktiviert eine Sandbox für die angeforderte Ressource, ähnlich dem iframe-Sandbox-Attribut. Die Sandbox wendet eine Same-Origin-Richtlinie an, verhindert Pop-ups, Plugins und blockiert die Skriptausführung. Der Sandbox-Wert kann leer gelassen werden, um alle Einschränkungen beizubehalten, oder es können Werte hinzugefügt werden: allow-forms, allow-same-origin, allow-scripts, allow-pop-ups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox und allow-top-navigation.
BEISPIEL SANDBOX-RICHTLINIE
sandbox allow-forms allow-scripts

report-uri

Weist den Browser an, Berichte über Richtlinienverstöße per POST an diese URI zu senden. Sie können auch Content-Security-Policy-Report-Only als HTTP-Header-Namen verwenden, um den Browser anzuweisen, nur Berichte zu senden (es wird nichts blockiert). Diese Direktive ist in CSP Level 3 veraltet und wird zugunsten der report-to-Direktive abgelöst.
BEISPIEL REPORT-URI
report-uri /some-report-uri

child-src

Definiert gültige Quellen für Web Worker und verschachtelte Browsing-Kontexte, die mithilfe von Elementen wie <frame> und <iframe> geladen werden
BEISPIEL CHILD-SRC POLICY
child-src 'self'

form-action

Definiert gültige Quellen, die als Aktion eines HTML-<form> verwendet werden können.
BEISPIEL FORM-ACTION POLICY
form-action 'self'

frame-ancestors

Definiert gültige Quellen für das Einbetten der Ressource mittels <frame> <iframe> <object> <embed> <applet>. Wird diese Direktive auf 'none' gesetzt, entspricht dies in etwa X-Frame-Options: DENY. Wenn diese Direktive aktiv ist und der Browser sie unterstützt, überschreibt sie die Einstellungen in X-frame-options.
BEISPIEL FRAME-ANCESTORS POLICY
frame-ancestors 'none'

plugin-types

Definiert gültige MIME-Typen für Plugins, die über <object> und <embed> aufgerufen werden. Um ein <applet> zu laden, muss application/x-java-applet angegeben werden.
BEISPIEL PLUGIN-TYPES POLICY
plugin-types application/pdf

base-uri

Definiert eine Reihe erlaubter Webadressen, die im src-Attribut eines HTML-base-Tags verwendet werden können.
BEISPIEL BASE-URI POLICY
base-uri 'self'

report-to

Definiert einen Berichtsgruppennamen, der durch einen Report-To-HTTP-Antwort-Header festgelegt wird. Weitere Informationen finden Sie in der Reporting API.
BEISPIEL REPORT-TO DIREKTIVE
report-to groupName

worker-src

Schränkt die Webadressen ein, die als Worker, Shared Worker oder Service Worker geladen werden dürfen.
BEISPIEL WORKER-SRC POLICY
worker-src 'none'

manifest-src

Schränkt die Webadressen ein, von denen Anwendungsmanifeste geladen werden dürfen.
BEISPIEL MANIFEST-SRC POLICY
manifest-src 'none'

prefetch-src

Definiert gültige Quellen für das Vorabladen und Vorab-Rendern von Anfragen, zum Beispiel über den link-Tag mit rel="prefetch" oder rel="prerender":
BEISPIEL PREFETCH-SRC POLICY
prefetch-src 'none'

navigate-to

Schränkt die Webadressen ein, zu denen das Dokument auf irgendeine Weise navigieren darf. Zum Beispiel, wenn ein Link angeklickt, ein Formular abgeschickt oder window.location aufgerufen wird. Ist form-action vorhanden, wird diese Direktive bei Formularübermittlungen ignoriert. Implementierungsstatus
BEISPIEL NAVIGATE-TO POLICY
navigate-to https://example.com

Das HTTP-Headers-Plugin von Joomla bietet außerdem die Möglichkeit, einige globale Parameter im Reiter Content Security Policy festzulegen.

Mit der Client-Einstellung kann ausgewählt werden, ob die CSP auf die Website, den Administrator-Bereich oder auf beide angewendet wird.

Mit der Option „Report-Only“ können die Direktiven getestet und mit DEV-Tools vor dem Livegang auf Fehler überprüft werden. Es macht immer Spaß, die Ursache von CSP-Fehlern in der Konsole von Google aufzuspüren!

Als Nächstes folgt die Einstellung „Nonce“. Nonce, was „nur einmal verwendete Zahl“ bedeutet, ist ein System, das einer eingebetteten <script>- oder <style>-Tag, die über die Joomla-API in das HTML eingefügt wird, eine zufällig generierte Zeichenfolge zuweist. Diese Fälle werden üblicherweise von Drittanbietern von Joomla-Komponenten/-Modulen/-Plugins implementiert, wenn diese zusätzliche Funktionalität auf der Website installiert wird.

Im Bild unten ist der <style>-Tag mit einem nonce-rel-Attribut zu sehen, das den CSS-<styles> hinzugefügt wurde, die von der Akeeba-Backup-Komponente in mein HTML-Dokument eingefügt wurden.

Interessanterweise enthält der Joomla-Core-JavaScript- und CSS-Code, der dem HTML-Dokument hinzugefügt wird, derzeit kein ‘nonce’-Tag. Das liegt daran, dass sie Teil des ‘Core’ sind, anstatt über die Joomla-API hinzugefügt zu werden.

Wird der ‘Nonce’-Schalter in den CSP-Einstellungen aktiviert, können diese Inline-Skripte und -Stile vom Browser als ‘sicher’ dargestellt werden. Außerdem muss das Joomla {nonce}-Tag in der script-src-Policy-Direktive auf script-src 'self' {nonce} gesetzt werden. Als Fallback für ältere Browser, die ‘Nonces’ nicht unterstützen, kann zusätzlich {script-hashes} nach dem {nonce}-Platzhalter hinzugefügt werden, also script-src 'self' {nonce} {script-hashes} (auf die Leerzeichen achten). Aber nicht vergessen, zuerst Script Hashes zu aktivieren.

Joomla generiert die Zeichenfolge für den ‘Nonce’-Wert zufällig und fügt sie den <style>- und <script>-Tags hinzu. Wird die ‘Nonce’-Option in den Plugin-Einstellungen aktiviert, wird die Zeichenfolge an den HTTP-Header übergeben. Der Browser interpretiert dann den HTTP-Header und verarbeitet das passende <script> oder <style>. Gleichzeitig entfernt er die Nonce-Zeichenfolge aus dem im Browser gerenderten HTML.

Dies wiederum verhindert, dass Herr Hacker die Nonce-Zeichenfolge kapern und seinem eigenen eingeschleusten Code hinzufügen kann. Selbst wenn es Herrn Hacker gelingt, sein bösartiges JavaScript in das HTML einzuschleusen, blockiert der Browser es.

Script Hashes

Wir alle wissen, dass Inline-JavaScript nicht in HTML eingebunden werden sollte, sondern in einer Datei my-javascript.js geschrieben und dem <head> hinzugefügt oder direkt vor dem </body>-Tag platziert werden sollte. Aber wir alle machen uns hin und wieder dieser Sünde schuldig.

Das Problem dabei ist: Wird dies getan und zusätzlich die CSP-Direktive ‘script-src 'self'’ gesetzt, wird standardmäßig sämtliches Inline-JavaScript blockiert. Dies ist so vorgesehen, um zu verhindern, dass von Herrn Hacker eingeschleustes JavaScript auf der Website ausgeführt werden kann.

Es gibt dafür eine Übersteuerung mit der Direktive script-src 'unsafe-inline', die es Herrn Hackers Inline-JavaScript erlaubt, zusammen mit dem eigenen vertrauenswürdigen Code ausgeführt zu werden. Das ist aus naheliegenden Gründen nicht die beste Option.

Script Hashes zur Rettung!

Joomlas HTTP-Headers-Plugin sammelt automatisch alle <styles> und <scripts>, die über die Joomla-API an die Website übergeben werden. Anschließend werden die entsprechenden Hashes generiert und über den HTTP-Header übergeben. Der Browser generiert dann die Hashes auf der Website selbst und bestätigt, dass die Hashes übereinstimmen. Ist dies der Fall, werden die Skripte ausgeführt, andernfalls werden sie blockiert.

Um diese Plugin-Funktion zu aktivieren, den Schalter auf 'Aktiviert' stellen. Anschließend in der script-src-Policy-Direktive den Wert 'self' {script-hashes} hinzufügen. Wird zusätzlich zu ‘Script Hashes’ auch die ‘Nonce’-Funktion verwendet, den Direktivwert wie im obigen Nonce-Beispiel setzen.

Das ist schon raffiniert.

Aber was noch besser ist: Man kann dieselbe Idee nutzen, um Script Hashes manuell zu verarbeiten und sie der Direktive script-src 'self' hinzuzufügen. Es erfordert etwas Arbeit bei Einrichtung und Pflege, kann aber hilfreich sein, wenn JavaScript zu einem Beitrag oder benutzerdefinierten Modul hinzugefügt wurde.

Es gibt detailliertere Methoden hierfür mithilfe eines sha256-, sha384- oder sha512-Hash-Generators. Da die meisten Benutzer jedoch nur kleine JavaScript-Schnipsel zu ihrem Beitrag oder benutzerdefinierten Modul hinzufügen, lässt man die Arbeit am besten von Googles Dev-Tools erledigen.

Der Vorgang ist einfach. Der einzige Unterschied liegt darin, wie der Hash erzeugt wird.

Vorausgesetzt, das Joomla-HTTP-Headers-Plugin ist aktiviert, CSP ist aktiv und die Direktive script-src 'self' wurde gesetzt und gespeichert.

Schritt 1 – Das eigene Inline-JavaScript zum Beitrag oder benutzerdefinierten Modul hinzufügen und speichern. Dabei nicht vergessen, die Editor-Einstellungen so anzupassen, dass der Editor den Code beim Speichern nicht entfernt.

Schritt 2 – Zur Webseite mit dem Skript navigieren. Dev Tools öffnen, und im Tab „Konsole“ erscheint ein Fehler ähnlich diesem:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='), or a nonce ('nonce-...') is required to enable inline execution.

Schritt 3 – Jetzt muss nur noch der Hash aus der Fehlermeldung in die JavaScript-Direktive im Plugin kopiert und erneut gespeichert werden:

script-src 'self' 'sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='

Anschließend die Webseite neu laden und erneut in Googles Dev Tools prüfen. Der Fehler ist nun verschwunden, und der Browser lädt das Skript auf der Webseite.

Notiz: In diesem Beispiel wird noch ein Fehler angezeigt, da das zum Beitrag hinzugefügte JavaScript nicht vollständig ist. Es zeigt jedoch, dass der Inline-Code zumindest zu funktionieren versucht.

Das Hinzufügen von Hashes zum Inline-Code ist eine gute Möglichkeit, sie im HTTP-Header auf eine Positivliste zu setzen, sodass sie weiterhin ausgeführt werden, während jeglicher Inline-Code, der nicht explizit gehasht und zur CSP hinzugefügt wurde, weiterhin blockiert wird. So wird der Versuch von Herrn Hacker, die Website zu kompromittieren, vereitelt.

Notiz:

Wird das JavaScript geändert, muss der Hash neu berechnet und der Wert in der CSP-Direktive geändert werden.

Bei Problemen mit den Hashes gibt es 3 häufige Ursachen, Lösungen dazu finden sich auf der Webseite „Using a hash with CSP“.

Strict Dynamic

Wird die Option Strict Dynamic in der CSP aktiviert, wird die einem Skript explizit über einen Hash oder eine Nonce erteilte Berechtigung auf alle anderen Skripte übertragen, die direkt mit ihm verknüpft sind oder von ihm aufgerufen werden. Diese Aktion überschreibt zudem Standard-Direktiven wie 'self' oder 'unsafe-inline', die in den allgemeinen CSP-Direktiven für diese Kind-Skripte gesetzt wurden. Sie werden ignoriert.

Style Hashes

Der Style Hash der CSP funktioniert genau wie die oben beschriebenen JavaScript-Hashes, wird jedoch verwendet, wenn CSS-<style>-Blöcke in den HTML-Body eingefügt werden. Genau wie bei 'Script Hashes' muss die Plugin-Funktion aktiviert und eine style-src Policy Directive gesetzt werden, die mit dem Wert 'self' {style-hashes} darauf verweist.

Notiz:

Wenn das eigene Inline-CSS geändert wird, statt CSS, das von der Joomla-API erzeugt wird, muss der Hash neu berechnet und der Wert in der CSP-Direktive geändert werden.

Frame Ancestors ‘self’

Diese Option im Plugin erlaubt es, dass eine Seite eingebettet werden kann, zum Beispiel in einem iframe, jedoch nur von derselben Website.

Soll ausdrücklich eine andere Website erlaubt werden, die eigenen Inhalte einzubetten, kann eine spezifische Direktive ‘frame-src’ eingerichtet werden.

Abschließender Hinweis / Fazit:

Beim Verfassen dieses Artikels ist mir bewusst geworden, dass ich nur an der Oberfläche dieses riesigen Themas gekratzt habe.

Ich liebe es, Themen zu entdecken, die ich zuvor ignoriert habe oder von denen ich nichts wusste. Geht es Ihnen genauso?

Das Fazit, zu dem ich bei der Recherche zum Thema HTTP-Header gekommen bin, insbesondere beim Einsatz von Joomlas neuem J4-Plugin zu deren Einrichtung, lautet: Wir alle müssen dieses Thema beherrschen. Es gibt viel zu viele Leute (Hacker) da draußen, die nur auf eine Gelegenheit warten, Websites mit schwacher Sicherheit auszunutzen. Also helfen Sie Ihren Nutzern nicht dabei, zu Opfern zu werden.

Viel Spaß beim Erkunden des Joomla-HTTP-Headers-Plugins und beim Lernen, wie es dabei helfen kann, die eigene Website abzusichern.

Es wird jedoch empfohlen, vor dem Start noch etwas mehr zu diesem interessanten Thema zu recherchieren. Unten befinden sich Links, um die eigene Recherche anzustoßen. Man bekommt dadurch ein viel besseres Verständnis davon, wie das Internet funktioniert und wie die eigene Website damit interagiert.

Zur Referenz

Falls das Plugin zurückgesetzt werden muss: Das HTTP-Headers-Plugin wurde mit folgenden Einstellungen installiert:

Das Plugin ist standardmäßig aktiviert.

• Die Reiter HSTS und CSP sind standardmäßig deaktiviert.
• Die X-Frame Options sind standardmäßig aktiviert.
• Die Referrer-Policy ist anfänglich auf: strict-origin-when-cross-origin gesetzt.
• Die Cross-Origin-Opener-Policy ist anfänglich auf same-origin gesetzt.

Wer bis hierher gelesen hat und dachte „Das ist nicht fair, was ist mit J3?“, „Warum können wir nicht dieselben Funktionen in Joomla 3 haben?“ – die gute Nachricht ist: Das geht. Allerdings muss das Plugin dafür vom JED heruntergeladen werden.

Nachdem die HTTP-Header mit dem Joomla-4-Plugin eingerichtet wurden, können diese auf der Security-Headers-Website getestet werden.

Wie war das Ergebnis?

Es ist zu beachten, dass die Aktivierung des HTTP-Headers-Plugins unerwartete Auswirkungen auf das Frontend haben kann.

Abschließend möchte ich Tobias Zulauf & Ced Keiflin für ihren Beitrag danken, diesen Artikel rechtzeitig fertigzustellen!