optimale CSP - wie kann ich ein Plugin zulassen?

    Hallo,

    bin etwas hmm

    Was macht denn das Plugin: https://extensions.joomla.org/extension/httpheader/

    - Ich bekomme von dem Plugin keine Hilfe, was ich eintragen muss

    - Ich kann keine Richtlinie deaktivieren, um zu testen, sondern muss sie löschen

    Zu allem

    - Note: If you have configured some HTTP Security Headers directly on the server, then this Plugin might create double entries.

    (1) wenn ich das Plugin wieder lösche, sind alle Einträge von HttpHeader weg?


    Unfassbar, wie so ein Plugin 4,5 von 5 Sternen erhalten kann rofl .


    Was wollte ich überhaupt mal probieren?

    Ich erstelle in 2 Minuten manuell einen CSP-Zeile in der .htaccess.

    (2) Mein Problem ist nun, wie kann ich ein Plugin zulassen?

    Bei einer optimalen CSP läuft das Plugin nicht mehr.

    Gruß und schönen Sonntag


    PS: es sind zwei (2) Frage und nicht alles zu ernst nehmen beer !

    Eine Suchmaschine quäle ich immer zuerst ;)

    Zitat von jof1

    - Note: If you have configured some HTTP Security Headers directly on the server, then this Plugin might create double entries.

    (1) wenn ich das Plugin wieder lösche, sind alle Einträge von HttpHeader weg?

    Ja. Wenn du die Einstellungen auch ohne das Plugin haben willst, musst du sie auf dem Server konfigurieren bzw. per .htaccess. Wie in der Pluginbeschreibung, die du zitierst, beschrieben, empfiehlt es sich, entweder das eine oder das andere zu machen, damit man keine doppelten Regeln bekommt.

    Zitat von jof1

    Unfassbar, wie so ein Plugin 4,5 von 5 Sternen erhalten kann rofl .

    Was ist das denn für ne Aussage? Versuch die Anleitung zu verstehen oder frag nach, wenn du was nicht verstehst. Aber erst mal das Plugin runtermachen, das ein sehr aktives Mitglied dieser Community in seiner Freizeit geschrieben hat und dir kostenlos zur Verfügung stellt, ist natürlich ne gute Alternative.

    Zitat von jof1

    Ich erstelle in 2 Minuten manuell einen CSP-Zeile in der .htaccess.

    (2) Mein Problem ist nun, wie kann ich ein Plugin zulassen?

    Bei einer optimalen CSP läuft das Plugin nicht mehr.

    Ein paar mehr Informationen wären nicht schlecht. Wie sieht deine CSP-Konfiguration aus? Welches Plugin willst du zulassen? Was für ein Fehler kommt dabei (die Entwicklerkonsole von Firefox oder Chrome zeigt CSP-Fehler sehr detailliert an)? Und was verstehst du unter einer optimalen CSP?

    Zitat von Harmageddon

    ... Versuch die Anleitung zu verstehen oder frag nach... . Aber erst mal das Plugin runtermachen, das ein sehr aktives Mitglied dieser Community in seiner Freizeit geschrieben hat und dir kostenlos zur Verfügung stellt, ... .

    ... Welches Plugin willst du zulassen? Was für ein Fehler kommt dabei (die Entwicklerkonsole ...)? Und was verstehst du unter einer optimalen CSP?

    Ich verstehe deinen Unmut, aber nicht alles gut gemeinte ist gut. Naja, lassen wir das.


    Es ist ein Plugin, das ein pop-up bringt, welches ist egal, geht keinen was an und ist normal als Plugin installiert.

    Meine Zeile in der .htaccess bringt dann schließlich ein A+ bei observatory.mozilla.org, jedoch geht das pop-up des Plugins nicht mehr auf, weil eben object-src 'self'; script-src 'self' das verhindern:


    Header always set Content-Security-Policy "default-src https:; object-src 'self'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; base-uri 'self'; form-action 'self'"


    Ich habe bezüglich object-src und script-src mit filesystem: und vieles mehr getestet, aber ich bekomme das Plugin einfach nicht zugelassen ohne Teile der CSP-Zeile zu entfernen. Keiner im Internet kann das erklären.


    Fehler in der Entwicklerkonsole habe ich tatsächlich auch feststellen können, aber eben nur, dass das Plugin durch meine Einstellung blockiert wurde.


    (https://www.thorsten-willert.d…p-content-security-policy, viele Anweisungen, aber nichts hilft.)

    Eine Suchmaschine quäle ich immer zuerst ;)

    Und wo sind deine Infos wie z.B.:


    Zitat von Das Forenteam
    • Gebt so viel Information bei wie möglich, bedenkt dass die Supporter nicht das sehen, was ihr vor euch seht.
    • Joomla Version angeben
    • Welche PHP- / MySQL Version?
    • Gebt alle Angaben zu Versionen, Betriebssystemen, Erweiterungen, die ihr habt an
    • Welche Erweiterungen und Templates sind installiert?
    • Link zur Webseite bzw. Link zum Problem, nur so kann effektiv geholfen werden.

    aus:

    Forenregeln


    und gib uns auch unter

    System -> Systeminformationen -> Als Text herunterladen

    die txt-Datei mit den Systeminformationen.

    Zitat von jof1

    ch verstehe deinen Unmut, aber nicht alles gut gemeinte ist gut. Naja, lassen wir das.

    Das hat weder etwas mit Unmut zutun, ich finde es schade das man etwas zuallererst öffentlichen ruter macht ohne auch nur eine der kostenfreien Möglichkeiten zu nutzen Hilfe zu bekommen. Ich versuche mal mein Glück etwas Feedback zu geben.


    Zitat von jof1

    Es ist ein Plugin, das ein pop-up bringt, welches ist egal, geht keinen was an und ist normal als Plugin installiert.

    Meine Zeile in der .htaccess bringt dann schließlich ein A+ bei observatory.mozilla.org, jedoch geht das pop-up des Plugins nicht mehr auf, weil eben object-src 'self'; script-src 'self' das verhindern:

    Vorschlag setze den Header auf report only dann werden die Fehler in der Browserconsole angezeigt.



    Zitat von jof1

    Header always set Content-Security-Policy "default-src https:; object-src 'self'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; base-uri 'self'; form-action 'self'"

    Ich kenne nicht das genutzte Plugin für das popup aber diese Regel besagt u.a. folgendes:

    objekte, scripte, bilder, css dürfen nur von der lokalen Seite gelanden werden. D.h. alles was von externen und inline geladen werden würde wird blockiert.


    Der default-src greift nur falls eine Directive nicht explizit aufgeführt ist.


    Mein Vorschlag, setze einmal diese Regel: content-security-policy-report-only: default-src 'self';


    Damit wird erstmal alles freigegeben was von der eigenen Seite kommt.


    Und nun wäre mein Vorgehen die Browserconsole anzusehen und nach und nach die Directiven (z.B. script-src) mit den domains zu füllen welche benötigt werden. Ich kann da besonders die Google Chrome Browserconsole empfehlen da die mMn am übersichtlichsten die Meldungen anzeigen.


    Bei konkreten Fragen zum Thema wie die Meldungen zu interpretieren und in eine Regel umzusetzen sind melde dich gerne hier mit einem Screenshot der Chrome console.


    Ein CSP ist idR sehr seitenspezifisch und bedarf etwas Zeit einzurichten.


    Das Plugin ist gedacht für Leute die einen Header setzen wollen, und ja nicht nur den CSP Header. Es spricht aber auch nichts dagegen das direkt in der .htaccess zu konfigurieren aber bitte nicht beides gleichzeitig ;)

    Als Tipp es gibt auch noch diesen PHP CSP Reporter: https://github.com/zero-24/csp-reporter-php da werden dann alle Reportdetails als JSON via Mail geschickt.


    report-uri /lokaler/pfad/zum/reporter.php wäre der Eintrag für den CSP.

    Zitat von zero24

    ...

    zero24, das ist jetzt eine super Erklärung!


    Ich habe jetzt einen wirklich guten Einstieg und kann wenigstens so ziemlich alles nachvollziehen,


    csp-reporter zeigt mir zwar z.B.

    ...

    Violated Directive: script-src-elem

    Blocked Domain: inline

    Blocked Uri: inline

    IP: inline


    an, aber ich weiß immer noch nicht, wie ich in einer directive das keyword 'unsafe-inline' vermeide.

    Eigentlich schon, Quelle angeben, hash usw., aber eben hier hakt es. Den hash hätte ich ja, aber nicht im Quellcode - immer fehlt was.


    Ich glaube das Plugin, das ich hatte, ist ungünstig programmiert, denn mein neues funktioniert

    1. besser und 2. völlig ohne 'unsafe-inline':

    observatory.mozilla.org (A+): 🎉🎉🎉 We don't have any! 🎉🎉🎉

    Make sure to check back occasionally to ensure that your website is keeping up with the latest in web security standards.

    In the meantime, thanks for everything you're doing to keep the internet a safe, secure, and private place!


    Nur in einer Subdomain muss ich style-src 'self' 'unsafe-inline' angeben:

    observatory.mozilla.org (A+): "Your current CSP policy allows the use of 'unsafe-inline' inside of style-src. Moving style attributes into external stylesheets not only makes you safer, but also makes your code easier to maintain."


    Zudem muss es doch so sein, dass ich das zu vermeidende keyword 'unsafe-inline' verwenden kann, wenn

    1. ich überhaupt CSP verwende

    2. sich eine source nicht lokal in meinem Webroot-Filesystem befindet und nachgeladen werden muss, sonst würde ja das keyword 'self' reichen.

    Es muss doch möglich sein diese Quelle direkt zu ermitteln.

    Ich sehe zwar in der Browserconsole die fehlerhafte Zeile, aber die sagt mir rein gar nichts, das wird wohl sein.


    Gruß und Danke für die Erklärungen, hat geholfen!





    Eine Suchmaschine quäle ich immer zuerst ;)

    Bei inline Sachen kann man in den Browser schauen da wird idR auch direkt der Hash angezeigt welche man freigeben kann. Mit Joomla 4 gibts dann auch dafür ein core tool. Ps. Nicht jeder Browser unterstützt script-src-elem daher kann es Sinn machen script-src und script-src-elm anzugreichen.


    Zitat von jof1

    Zudem muss es doch so sein, dass ich das zu vermeidende keyword 'unsafe-inline' verwenden kann, wenn

    1. ich überhaupt CSP verwende

    2. sich eine source nicht lokal in meinem Webroot-Filesystem befindet und nachgeladen werden muss, sonst würde ja das keyword 'self' reichen.

    Es muss doch möglich sein diese Quelle direkt zu ermitteln.

    Ich sehe zwar in der Browserconsole die fehlerhafte Zeile, aber die sagt mir rein gar nichts, das wird wohl sein.

    'unsafe-inline' bedeutet hier das inline styles oder scripte auf der Seite direkt im HTML eingebunden werden. z.B. die "onClick", "onError", etc. handler und "<script>" in JS oder das "style" attribute bzw. "<style>" mit CSS.


    Am besten kommt man ganz ohne diese Dinge aus wenn es unbedingt notwendig ist kann man diese per "hash" freigeben. Dieser wird im Chrome in der Fehlermeldung auch angezeigt.


    Dieser Hash kann dann in der style-src bzw script-src freigeschaltet werden Beispiel: style-src 'self' 'sha256-JfYgjAb4XZJSe1AUBWfJhRKo9xfSpr5ledAcv2OYL3o='

    'sha256-JfYgjAb4XZJSe1AUBWfJhRKo9xfSpr5ledAcv2OYL3o='

    Zitat von zero24

    ...

    'unsafe-inline' bedeutet hier das inline styles oder scripte auf der Seite direkt im HTML eingebunden werden. ...

    Am besten kommt man ganz ohne diese Dinge aus wenn es unbedingt notwendig ist kann man diese per "hash" freigeben. ...

    'sha256-JfYgjAb4XZJSe1AUBWfJhRKo9xfSpr5ledAcv2OYL3o='

    Hi, ja verstehe ich jetzt auch:

    observatory.mozilla.org (A+): "Your current CSP policy allows the use of 'unsafe-inline' inside of style-src. Moving style attributes into external stylesheets not only makes you safer, but also makes your code easier to maintain."


    Ja, hash, das war ja auch mein Gedanke, dass mich freudig aufhorchen lies, als ich das hier https://content-security-policy.com/hash/ las , habe ich gleich so angewendet, aber keine Änderung, wäre ja super, muss ich noch mal probieren...


    Übrigens:

    oben das "Nur in einer Subdomain muss ich style-src 'self' 'unsafe-inline' angeben:" das ist für nextcloud.

    Gruß

    Eine Suchmaschine quäle ich immer zuerst ;)

    Habs noch mal probiert und jetzt vermutlich endlich verstanden.

    Ich müsste für jedes violate den Hash aus der Browserconsole als keyword für die entsprechende CSP-directive eintragen, oder nonce.

    Oder gegebenenfalls eine externe https-Quelle.


    Ich habe für nextcloud aber hunderte hash's einzutragen, die sich beim Quellcode-Wechsel auch noch ändern, was zeitlich schon fast unmöglich ist, außer einer schreibt ein script.

    Und da sind wir wieder beim httpheader plugin, ich hätte erwartet, dass das plugin das tut - so falsch lag ich also nicht.

    Aber auch ich muss jetzt sagen, würde ich mir nicht antun fie !

    Und style-src 'self' 'unsafe-inline' dürfte gar nicht so unschön sein wie bei script-src .


    Somit vielen Dank für die Lehrstunden!

    <3

    Eine Suchmaschine quäle ich immer zuerst ;)

    Zitat von jof1

    Ich habe für nextcloud aber hunderte hash's einzutragen, die sich beim Quellcode-Wechsel auch noch ändern, was zeitlich schon fast unmöglich ist, außer einer schreibt ein script.

    NextCloud != Joomla. Mein NextCloud setzt einen CSP Header mit nonce automatisch da muss ich kein script schreiben.

    Zitat von jof1

    Und da sind wir wieder beim httpheader plugin, ich hätte erwartet, dass das plugin das tut - so falsch lag ich also nicht.

    Aber auch ich muss jetzt sagen, würde ich mir nicht antun fie !

    Kann ich verstehen in 4.0 haben wir das auch genau das umgesetzt in in den Core integriert.


    Also z.B. eine automatische Generierung der hashes und nonces und einen CSP reporter collector.

    Zitat von zero24

    (1) ... NextCloud setzt einen CSP Header mit nonce automatisch ...


    (2) ... in 4.0 haben wir das auch genau das umgesetzt in in den Core integriert.

    Also z.B. eine automatische Generierung der hashes und nonces und einen CSP reporter collector.


    (1) Ja, bemerke ich auch, ich entferne die CSP-Zeile aus der .htaccess Datei für nextcloud und das Ergebnis ist gleich bei observatory.mozilla.org (A+):

    "Your current CSP policy allows the use of 'unsafe-inline' inside of style-src. Moving style attributes into external stylesheets not only makes you safer, but also makes your code easier to maintain."

    Ich wollte halt die Meldung "Your current CSP policy allows the use of 'unsafe-inline' inside of style-src." entfernen.

    Naja, hätte ich vorher genauer wissen sollen, ich nehme es leicht, war nur zur Übung :) !


    (2) Ja, habe ich gelesen "This plugin has been included in the Joomla Core (joomla/joomla-cms#18301) and will be part of the upcomming 4.0 Release.".

    Deswegen wollte ich jetzt schon mal rein schnuppern.


    Ich will ja keine Ansprüche stellen (tue ich aber damit trotzdem hmm ), aber erwähne jetzt schon,

    zero24, du kennst ja jetzt die Unterhaltung mit mir und den Anspruch von weniger geübten: bezüglich Header und CSP so viel wie überhaupt nur möglich automatisieren, denn nicht jeder hat Tage Zeit für übelst aufwendige Konfigurationen.

    Automatismus steigert die Akzeptanz und den Wert eines Projektes enorm, ich bin jedenfalls riesig gespannt auf Joomla 4.0 search .


    Und ja, ich kenne den anerkennenden Wert für Sponsoring and Donation :!:

    Eine Suchmaschine quäle ich immer zuerst ;)

    Zitat von jof1

    (2) Ja, habe ich gelesen "This plugin has been included in the Joomla Core (joomla/joomla-cms#18301) and will be part of the upcomming 4.0 Release.".

    Deswegen wollte ich jetzt schon mal rein schnuppern.

    Richtig das Plugin ist ein Teil der Core Features. Zusätzlich kommt noch ein Reporting endpoint sowie eine Möglichkeit die reports zu prüfen und freizuschalten. Das Plugin wurde dann dahingehend erweitert aus den freigegebene reports einen CSP Header zu generieren.


    Weitere Details gibts u.a. von mir auch hier:

    - Zum 3.xer Plugin: https://www.hosteurope.de/blog…t-http-headern-schuetzen/

    - Zum 4.xer Core (aktueller Zwischenstand): https://docs.joomla.org/J4.x:Http_Header_Management

    - Auch wird aktuell dieses Feature für 4.x noch aktiv weiterentwickelt: https://github.com/joomla/joomla-cms/pull/32893


    Getestet werden kann das bestehende Tooling bereits in the Nightly Builds: https://developer.joomla.org/nightly-builds.html

    Zitat von jof1

    Ich will ja keine Ansprüche stellen (tue ich aber damit trotzdem hmm ), aber erwähne jetzt schon,

    zero24, du kennst ja jetzt die Unterhaltung mit mir und den Anspruch von weniger geübten: bezüglich Header und CSP so viel wie überhaupt nur möglich automatisieren, denn nicht jeder hat Tage Zeit für übelst aufwendige Konfigurationen.

    Automatismus steigert die Akzeptanz und den Wert eines Projektes enorm, ich bin jedenfalls riesig gespannt auf Joomla 4.0 search

    Ja kann ich sehr gut verstehen. Es gibt zwei wichtige Punkte weshalb es von mir noch keinen Backport der 4.x Tools gibt. Und das sind die Zeit die ich nicht habe um das Thema für 3.x zurück zu portieren und auch das Thema das in 3.x einige Core Features nicht in dem Umfang zur Verfügung stehen wie Sie für eine gute Implementierung notwendig wären. U.a. wurde auch im 4.xer Core einiges getan von inline styles und vor allem inline scripts weg zu kommen oder zumindest über die einheitliche API einzubinden, das erleichtert die Implementierung eines Automatismus der dann auch möglichst viele Fälle abdeckt.