Beiträge von zero24

  • Aktualität JED

    Zitat von Elwood

    Richtig. Aber wenn die Extension noch gelistet ist, aber der Download-oder/und Supportlink nicht mehr funktioniert, weil halt nichts mehr aktualisiert wurde und es die Extension vielleicht nicht mehr gibt, sollte es nach Hinweis aus der JED verschwinden.

    Das ist richtig, es sollte eine Meldung gemacht werden dann schauen sich die Listing Leute aus dem JED das an. Die arbeiten die Reports dann alle nacheinander ab. Die Links selbst werden auch regelmäßig stichprobenartig automatisch geprüft und sollte die Domain offline sein wird die Extension unpublished aber ein report sollte dafür sorgen das es etwas schneller geht. :)

  • Joomla 4.0.0-rc1 und Joomla 3.10.0-alpha6

    Hi,


    gerade wurde Joomla 4.0.0-rc1 und Joomla 3.10.0-alpha6 veröffentlicht: https://www.joomla.org/announc…-joomla-3-10-alpha-6.html


    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

  • Joomla 3.9 und MariaDB 10.5

    Zitat von Re:Later

    War nicht als Kritik gemeint. Mir fiel nur auf, dass beim Rumklickern im Netz doch einiges zu finden war, wo Benutzer sich erst mal in Foren und so absicherten, weil auf der Joomla-Requirements-Seite MariaDB nicht explizit genannt wird.

    Hab ich auch nicht so verstanden ich wollte nur eine Erklärung geben :)

    Zitat von Re:Later

    kann dann zusätzlich irritieren. Speziell das "5.5", was ja nun auf Joomla 4 laut Requirements nicht empfohlen wäre, WENN ES eine MySQL-Version wäre. Ging auch mir ganz kurz so, weil ich kürzlich extra auf eine höhere (5.7) habe updaten lassen. Wollte schon meckern gehen ;-)

    Ja kann ich verstehen genau der Fall mit der Version sollte aber im Pre Upgrade Checker etc abgefangen sein. Genau mit dem "Trick" alles hinter 5.5.5 zu prüfen ;)

  • Analyse von HTTP Security Headers

    Zitat von JoomlaWunder

    Nach weiteren Webrecherchen und Tests habe ich folgendes herausgefunden. Es muss bei meinem Hoster tatsächlich noch ein $from bzw. ein Header angegeben werden, also beispielsweise

    Ha das Problem hatte ich bis jetzt bei den 3 Hostern wo ich das script bis jetzt genutzt habe noch nicht, hab das aber jetzt auf der to-do liste das ganze im script zu ergänzen. Danke.

  • Joomla 3.9 und MariaDB 10.5

    Zitat von Re:Later

    Ja, stimmt. So ganz explizit wird das nirgends(?) angegeben, aber dem issue tracker bzw. auf GitHub kann man wenigstens zwischen den Zeilen lesen, dass man bei Joomla auch ein Auge auf MariaDB hat.

    Das Problem ist das es keine explizite Unterscheidung für MariaDB gibt da idR weiterhin die mysqli Erweiterung von PHP benutzt wird. Daher sind alle "Drop in replacements" für mysql wie z.B. MariaDB implizit unterstützt. Wie aber schon erwähnt geben wir uns Mühe auch auf MariaDB zu testen besonders da viele Hoster das entsprechend umstellen. Das ist aber mWn der Grund warum immer nur von MySQL gesprochen wird da eine Kompatibilität zur mysqli Erweiterung vorausgesetzt wird, sollte das irgendwann in Zukunft nicht mehr gegeben sein müsste man den dann neuen weg ins CMS einbauen alternativ würde ggf. auch noch PDO gehen aber auch das wird ja von Joomla unterstützt.

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