Beiträge von zero24

  • Analyse von HTTP Security Headers

    Zitat von JoomlaWunder

    Nebenfrage:

    Für die Einstellung des CSP-Headers über das Plugin nutze ich momentan "Content-Security-Policy-Report-Only" mit report-uri und dem Skript csp-reporter.php

    Firefox meldet mir die Violations und auch das ein CSP-Bericht versendet wird. Es kommt aber keine Email bei mir an.

    Die Emailadresse wurde im Skript geändert und ich habe es mit dem Pfad zum Skript über /csp-reporter.php versucht als auch mit Angabe der gesamten uri, also https:// ....csp-reporter.php

    Die Domain wurde auch angehängt gemäß Anleitung.

    hmm erlaubt dein Hoster die PHP mail() Funktion? Was kannst du im Netzwerk Tab sehen kommt der request an und gibt nen HTTP 200 zurück?


    Zitat von JoomlaWunder

    "Praktisch sollten die Header überhaupt nicht erkannt werden aus der .htaccess, da die PHP Dateien diese überschreiben. Ich kann nicht sagen warum securityheaders.com fürs checken das bei der einen Seite (ohne www) erkennt und bei der anderen (mit-www) nicht. Möchte Sie diese Header setzen, so müssen Sie diese leider in die PHP Dateien einfügen."

    Das hört sich für mich auch sehr komisch an. Ja wenn mein Plugin läuft dann könnte es passieren das die Überschrieben werden aber ein "Standard" Joomla setzt diese Header noch nicht.



    Zitat von JoomlaWunder

    Dann werde ich die HTTP Security Header wohl über das Plugin setzen. Wäre über die .htaccess zwar schön gewesen, da man hier schnell etwas per C&P hätte übernehmen können, aber was soll's.

    Normalerweise(TM) sollte das auch genau so gehen, war bis jetzt auch auf allen Seiten so wo ich das gemacht habe.

    Zitat von JoomlaWunder

    Hier mal die .htaccess. Diese ist etwas umfangreicher. Aber auch mit anderen funktioniert das nicht, wo dann beispielswiese keine Entfernung des Trailing-Slashes oder die ganzen Cache-Einstellungen unten enthalten sind.

    Hmm sehe ich jetzt auch keine größeren Probleme besonders da du ja auch schon "header als letztes setzen" probiert hast.

  • Analyse von HTTP Security Headers

    hmm das Header Plugin läuft zur Joomla runtime daher wird das dann immer gesetzt egal ob www oder non-www. Die htaccess sollte das aber auch können.


    Kannst du sicherheitshalber einmal die htaccess hier posten? Ggf fällt ja noch etwas auf.

  • Analyse von HTTP Security Headers

    Hi,


    Zitat von JoomlaWunder

    Für die Admins/Mods: Bitte beim Zusammenfassen auch gleich den falschen Link im ersten Beitrag durchtauschen. richtig wäre natürlich siwecos.de

    Done.

    Zitat

    Außer den Einträgen "CSP" und "X-Content-Type-Options", die ja bereits in der .htaccess drinstehen (Joomla-Empfehlung), habe ich weitere gesetzt, beispielsweise Referrer-Policy, X-Frame-Options oder das ältere X-XSS-Protection.

    Der CSP Header welcher im Joomla Default hinterlegt ist schützt lediglich gegen XSS via SVGs ein vollständiger CSP Header ist das nicht. ;)

    Zitat von JoomlaWunder

    Der HSTS wurde von mir nicht gesetzt. Wird der automatisch hinzugefügt, wenn über https übertragen wird?

    ggf wird der über deinen Hoster gesetzt? Bei meinem Hoster kann man das einstellen.

    Zitat von JoomlaWunder

    Aber warum werden bei der Analyse der https-Aufrufe die Header nicht angezeigt. Gibt es ev. einen Header, der genau das unterbinden kann?

    Hmm eigentlich nicht. Frage wie sieht die Reihenfolge in der htaccess aus? Also wird erst auf https weitergeleitet und dann die anderen Header gesetzt oder umgekehrt?

  • optimale CSP - wie kann ich ein Plugin zulassen?

    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.

  • optimale CSP - wie kann ich ein Plugin zulassen?

    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.

  • optimale CSP - wie kann ich ein Plugin zulassen?

    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='

  • optimale CSP - wie kann ich ein Plugin zulassen?

    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 ;-)

  • logfile bei Migration von Joomla 3 auf Joomla 4

    Core extensions können via "Überprüfen" / Discover im Installer nach installiert werden. Erweiterungen -> Verwalten -> Überprüfen -> Überprüfen -> installieren


    Zitat von Reigi

    Kann ich jetzt eigentlich probieren, deaktivierte Erweiterungen wieder zu aktivieren? Gibt Joomla einen entsprechenden Hinweis aus? Oder laufe ich Gefahr, noch einmal die ganze Prozedur machen zu müssen?

    Ja kannst wieder aktivieren und sehen was kaputt geht. Das Upgrade ist durch daher ist das sicher und durch ein wieder deaktivieren wäre die Seite wieder ok.

  • minifrontpage Fehlermeldung

    hmm dann würde ich sagen besser nochmal beim Support melden das es immer noch Probleme gibt. ggf ist eine Stelle übersehen worden. Bevor wir jetzt auf die suche nach einer alternative gehen.

  • logfile bei Migration von Joomla 3 auf Joomla 4

    Zitat von Reigi

    Was mich etwas wundert ist, dass anscheinend auch die deaktivierten Komponenten überprüft wurden.

    Ja da diese ja noch im System sind. Mit der PR die ich oben erwähnt habe werden kritische Erweiterungen genannt diese verschwinden bzw sind nicht mehr kritisch wenn diese deaktiviert sind.


    Die Template Meldung ist bekannt das mit dem Manifestcache eine Warnung hast du ggf diese beiden module deinstalliert?

  • minifrontpage Fehlermeldung

    Hmm diese Fehlermeldung besagt das er ein Bild nicht finden kann. Würde das bei der Seite denn Sinn machen ggf givts eine Option die per default "leer" ist und es dann zu dieser Meldung kommt. Selber nutzen tue ich minifrontpage nicht aber ggf hilft die Info schon weiter.