Content Security Policy

Am Ende hängt es ja auch immer von deinem Setup und deinen Einstellungen ab. Je nach dem was deine KI weiß, kann sie auch nur raten. Daher würde ich das so nicht umsetzen, aber hier ausführlich in gleicher Form:

Worked for 1m 59s
Urteil

Nein, nicht vollständig. Der Text enthält richtige Grundideen, mischt aber ältere Joomla-Anleitungen mit einer sehr aggressiven CSP-Konfiguration. Ich würde diese Einstellungen nicht ungeprüft auf einer produktiven Joomla-Seite übernehmen.

Dass du bisher nichts verändert hast, war richtig.

Was stimmt?

Das Plugin „System – HTTP Headers“ gehört zum Joomla-Core. Für eine dynamische CSP mit Nonces ist es grundsätzlich geeigneter als eine statische Regel in der .htaccess. Joomla erzeugt bei aktivierter Nonce-Funktion einen zufälligen Wert und setzt ihn für script-src und style-src ein.

Ebenfalls richtig:

zuerst nur Content-Security-Policy-Report-Only verwenden
die eigentliche Sperre erst später aktivieren
CSP nicht gleichzeitig unabhängig in Joomla, Cloudflare und .htaccess pflegen
script-src, object-src und base-uri sind für eine wirksame XSS-Abwehr besonders wichtig
Nonces oder Hashes sind stärker als einfache Domain-Freigaben

Mehrere CSP-Header überschreiben sich nicht einfach. Der Browser berücksichtigt alle Richtlinien. Eine Ressource muss daher durch jede aktive Richtlinie erlaubt werden.

Was ist falsch oder veraltet?
1. „Detect“, „Automatic“ und automatische Joomla-Berichte

Diese Beschreibung passt nicht zur aktuellen Joomla-6-Version des Plugins. Die aktuelle Konfiguration enthält unter anderem:

CSP aktivieren
Client
Report-Only
Nonce
Script-Hashes
Strict Dynamic
Style-Hashes
frame-ancestors
einzelne Direktiven

Einen auswählbaren Modus „Detect“, „Automatic“ oder „Custom“ gibt es in der aktuellen Joomla-6-Implementierung nicht mehr.

Auch die Aussage, dass Joomla die gefundenen Verstöße automatisch unter System → Verwalten → Content Security Policy sammelt, stammt aus älteren Joomla-Versionen. In Joomla 6 erzeugt das Plugin im Wesentlichen den Header.

Ohne report-to beziehungsweise einen echten Reporting-Endpunkt werden keine Berichte an Joomla oder einen Server gesendet. Report-Only-Verstöße lassen sich aber in den Entwicklerwerkzeugen des Browsers beobachten.

2. Nonces und Hashes erfassen nicht automatisch alles

Joomla berechnet die Hashes aus den Inline-Skripten und Styles, die in den Dokument-Kopfdaten registriert sind. Das bedeutet nicht, dass automatisch jedes Skript eines Templates, Page Builders, Cookie-Banners oder Drittanbieter-Plugins abgedeckt ist.

Die Joomla-Dokumentation weist ausdrücklich darauf hin, dass Erweiterungen problematisch sein können, wenn sie:

rohe Inline-Skripte ausgeben
onclick, onload oder ähnliche HTML-Attribute verwenden
Styles direkt über style="..." setzen
Skripte nicht über die Joomla Document API einbinden

Bei einer Seite mit Helix Ultimate, SP Page Builder, Cookie-Banner, Werbeskripten und eingebetteten Inhalten ist das Risiko für Probleme entsprechend hoch.

3. 'unsafe-inline' ist kein zuverlässiges Sicherheitsnetz

Der vorgeschlagene Wert lautet:

script-src 'self' 'unsafe-inline' 'strict-dynamic' https:

Wenn Joomla zusätzlich einen Nonce oder Hash einfügt, ignorieren moderne Browser bei dieser Direktive 'unsafe-inline'. Ohne passenden Nonce oder Hash ausgegebene Inline-Skripte werden dann trotzdem blockiert.

Dasselbe Problem kann bei style-src auftreten. Ein Page Builder verwendet häufig zahlreiche direkte style-Attribute. Werden diese nicht korrekt berücksichtigt, kann die komplette Darstellung beschädigt werden.

4. 'strict-dynamic' verändert die Regel grundlegend

Bei einer gültigen Nonce- oder Hash-basierten Richtlinie sorgt 'strict-dynamic' dafür, dass moderne Browser unter anderem folgende Einträge ignorieren:

'self'
https:
'unsafe-inline'

Danach werden im Wesentlichen nur noch Skripte mit passender Nonce beziehungsweise passendem Hash sowie von diesen vertrauenswürdig nachgeladene Skripte ausgeführt.

Das kann eine gute Sicherheitslösung sein. Es ist aber keine Einstellung, die man ohne vollständigen Kompatibilitätstest auf einer bestehenden Joomla-Seite aktiviert.

Joomla 6 besitzt dafür außerdem einen eigenen Schalter Strict Dynamic. Man muss 'strict-dynamic' daher nicht zusätzlich manuell in das Wertefeld schreiben.

5. https: ist viel zu pauschal

Diese Einträge:

script-src ... https:
style-src ... https:
font-src ... https:
connect-src ... https:

erlauben grundsätzlich Quellen von jeder HTTPS-Domain. Das verbessert häufig die Kompatibilität, ist aber keine sorgfältig erstellte Allowlist.

Bei script-src wird das teilweise durch 'strict-dynamic' relativiert. Bei Bildern, Fonts, Styles und Verbindungen bleibt https: jedoch sehr breit.

6. Die Liste ist nicht vollständig

Je nach Website können zusätzlich nötig sein:

media-src
worker-src
manifest-src
child-src

Ohne eigene Direktive greift häufig default-src 'self'. Dadurch können externe Videos, Blob-Worker, Web-Push, Analysewerkzeuge oder bestimmte Page-Builder-Funktionen blockiert werden.

form-action 'self' kann außerdem externe Newsletter-, Zahlungs- oder Formularanbieter blockieren. frame-src nur mit YouTube reicht nicht aus, wenn andere Einbettungen verwendet werden.

Was bedeutet „kein anderer CSP-Header“?

Im Plugin gibt es einen Bereich Zusätzliche HTTP-Header. Dort sollte keine manuelle Zeile wie diese eingetragen sein:

Content-Security-Policy

oder:

Content-Security-Policy-Report-Only

wenn du die CSP bereits über den eigenen CSP-Bereich des Plugins konfigurierst.

Auch in folgenden Bereichen sollte dann keine zweite CSP vorhanden sein:

.htaccess
Cloudflare Transform Rules
IONOS-Serverkonfiguration
anderes Sicherheits-Plugin
Template oder System-Plugin

Wenn in „Zusätzliche HTTP-Header“ aktuell nichts mit Content-Security-Policy steht, musst du dort nichts eintragen.

Meine Empfehlung für deine Seite

Auf der Live-Seite würde ich die CSP vorerst nicht erzwingen.

Für einen ersten ungefährlichen Test auf einer Kopie oder Testdomain:

Content Security Policy: Aktiviert
Client: Website
Report-Only: Aktiviert
Nonce: Deaktiviert
Script-Hashes: Deaktiviert
Strict Dynamic: Deaktiviert
Style-Hashes: Deaktiviert
frame-ancestors 'self': Aktiviert

Als vorläufige Testdirektiven:

default-src 'self'
script-src 'self' 'unsafe-inline' https:
style-src 'self' 'unsafe-inline' https:
img-src 'self' data: blob: https:
font-src 'self' data: https:
connect-src 'self' https: wss:
frame-src 'self' https:
media-src 'self' blob: https:
worker-src 'self' blob:
object-src 'none'
base-uri 'self'
form-action 'self'

Das ist bewusst noch keine starke finale CSP. Es ist nur eine kompatiblere Ausgangsbasis, um in der Browser-Konsole zu erkennen, welche Dienste deine Seite tatsächlich verwendet.

Erst danach würde man:

pauschales https: durch konkrete Domains ersetzen,
Erweiterungen auf Nonce-Kompatibilität prüfen,
Nonce und gegebenenfalls Script-Hashes testen,
anschließend 'strict-dynamic' testen,
erst ganz am Ende Report-Only deaktivieren.

Fazit: Die ursprüngliche Empfehlung ist als allgemeine Erklärung brauchbar, aber als konkrete Joomla-6-Anleitung zu ungenau und für eine bestehende produktive Seite zu riskant. Besonders Nonce, Style-Hashes und Strict Dynamic solltest du nicht gleichzeitig und ungeprüft einschalten.

Zitat

chatgpt empfiehlt eine ziemliche veraenderung dieses plugins. ich kannte das bisher nicht. vielleicht will da mal jemand drueber gucken?

Bestimmt nicht. Mach einfach was chatGPT sagt und trag die Konsequenzen.
Aber bitte beachtet die forenregeln:

Wir stellen fest, dass KI-Tools zunehmend genutzt werden. Diese Regel soll Transparenz gewährleisten und Missverständnisse vermeiden:

• Kennzeichnungspflicht: Jeder Beitrag, bei dem eine KI zum Inhalt beigetragen hat, muss eindeutig als "KI-generiert" gekennzeichnet werden. Unsere Moderatoren behalten sich das Recht vor, die Kennzeichnung “KI-generiert” hinzuzufügen, auch wenn der Nutzer dies nicht selbst getan hat.

• Konsequenzen bei Verstößen:

  • Freundliche Erinnerung an die Regel und Aufforderung zur Kennzeichnung.
  • Wiederholung: Löschung des Beitrags sowie Bann.

  
  

Hier kannst du deine Seite testen:

https://securityheaders.com/

Es ist auch meiner Meinung nach durchaus komplex und nicht banal insbesondere CSP!

Um sinnvollen Einstellungen des System-Plugins HTTP Headers empfehlen zu können müßte man zumindest zuerst wissen um welche Website es sich handelt da dies je nach Website individuell ermittelt werden muß.

Der in #4 verlinkte jug-zueri.ch Beitrag enthält ja bereits allgemeine Hinweise und Empfehlungen.

Um welche Website handelt es sich?

Wird die nachfolgend verlinkte Joomla-Standard .htaccess im Frontend unverändert verwendet?

github.com/joomla/joomla-cms/blob/6.1.2/htaccess.txt

Falls nein. Welche Veränderungen wurden an der .htaccess im Frontend vorgenommen?

Eventuell nützlich z.B. auch:

Zitat von zero24

Die Standard Einstellungen beinhalten einen ersten Stand welcher für 99% der Seiten passt. Erstmal machst du damit aber auch nichts falsch. CSP also Content-Security-Policy ist da aber noch nicht dabei da es hier eine sehr individuelle Thematik ist.

Vielleicht ist es ein guter Start hier ein YouTube Video zu schauen wo David in das Thema etwas tiefer eingestiegen ist:

https://www.youtube.com/watch?v=URa9g-bA4G8

Übrigens das Gün und Rot in deinen Bildern in #6 besagt nur das ein entsprechender Eintrag im header der html-Datei z.B. für Permissions-Policy vorhanden ist(Grün) oder nicht vorhanden ist(Rot).

Ob der jeweilige Wert des Eintrages die "Sicherheit" der Website erhöht oder gar nicht verändert bzw. gar nicht verbessert wird durch die Farbe Grün nicht ausgesagt!

Zitat von firstlady

Aber bitte beachtet die forenregeln:

Wir stellen fest, dass KI-Tools zunehmend genutzt werden. Diese Regel soll Transparenz gewährleisten und Missverständnisse vermeiden:

• Kennzeichnungspflicht: Jeder Beitrag, bei dem eine KI zum Inhalt beigetragen hat, muss eindeutig als "KI-generiert" gekennzeichnet werden. Unsere Moderatoren behalten sich das Recht vor, die Kennzeichnung “KI-generiert” hinzuzufügen, auch wenn der Nutzer dies nicht selbst getan hat.

• Konsequenzen bei Verstößen:

  • Freundliche Erinnerung an die Regel und Aufforderung zur Kennzeichnung.
  • Wiederholung: Löschung des Beitrags sowie Bann.

  
  

Danke, Christiane.

Wusste ich nicht. Wenn man schon so lange dabei ist, schaut man nicht mehr so oft rein......

Eventuell auch nützlich:

https://www.joomla.de/wissen/joomla-…p-header-plugin

wiki.selfhtml.org/wiki/Sicherheit/Content_Security_Policy

Zitat

Wusste ich nicht. Wenn man schon so lange dabei ist, schaut man nicht mehr so oft rein......

Das ist auch neu.
Was wir nicht wollen, das ist ein unreflektiertes copy/paste von KI Texten die so tun als würden sie von einem Supporter kommen.

Man kann sagen "laut Claude oder .. my KI friend.. ist es so oder so. Es scheint mir plausibel aber ich habe es nicht geprüft" oder eben "KI erstellter Text, ich habe es geprüft".

oxenator vielleicht hilft dir das kleine Tool bei den Einstellungen.

Zitat von Sieger66

Um welche Website handelt es sich?

oxenator Da könnte man sicher mehr sagen.

Zitat von oxenator

Das Thema ist halt wegen der vielen joomla Angriffe aktuell.

Bei 95% der Angriffsvektoren der letzten Wochen war eine CSP generell wirkungslos, bei den anderen 5% hätte nur eine strikte und im CMS Kontext daher normalerweise unbenutzbare CSP etwas gebracht.

Zitat von oxenator

Kann eigentlich über die joomla Suche Schadcode eingeschleust werden?

Es gibt keine bekannte Lücke.

oxenator , wegen des HTTP-Header Plugin musst du dir gemäss SniperSister nicht zu viel Sorgen machen.

Aber ich verstehe dich, dass du, wenn möglich, alles im Grünen haben möchtest. Da bei meiner Webseite alles im grünen Bereich ist und du nichts Spezielles installiert hast, könntest du es mit meinen Einstellungen versuchen. (Mache zuerst einen Screenshot, wie deine Einstellungen jetzt sind, und natürlich wie immer ein Backup.)

Zitat von oxenator

...ist es theoretisch möglich in das suchfeld schadcode einzuschleusen? wenn ja, waere es doch sinnvoll auf die suche zu verzichten.

Das ist sicher nicht möglich, ist ja nur eine Anfrage und es wird nichts hochgeladen.