Beiträge von zero24

    Hi, hab mir gerade besagtes "Joomla Hot Patch" angeschaut.


    Zu finden ist das Paket hier: https://downloads.joomla.org/cms/joomla3/3-0-1


    In dem Fall scheint es ein Paket zu sein welches einige Dateien vom Updater anpasst ohne die Version der Erweiterung anzuheben, wenn es jetzt nochmal zu so einem Problem kommen würde können wir nun ein standalone update der Updater Komponente raus bringen und die hier genannten Probleme umgehen.


    Beim deinstallieren kann es dazu kommen das die drei beinhalten Dateien gelöscht werden.


    Um den Eintrag los zu werden reichen aber folgende Schritte:
    - In der #__extensions den eintrag "Joomla hot patch" bzw. "joomlashort" löschen

    - Im Dateisystem diese Datei löschen, falls sie existiert: administrator/manifests/files/joomlashort.xml


    Die in dem patch enthaltenen Dateien sind:

    administrator/components/com_joomlaupdate/models/default.php

    administrator/components/com_joomlaupdate/views/default/tmpl/default.php

    libraries/joomla/installer/adapters/file.php


    Diese wurden nach dem "Hot Patch" durch core Updates mehr als einmal geändert , und teilweise verschoben und sollten daher keine Nacharbeiten nötig machen machen.


    Sollte das "Hot Patch" bereits deinstalliert worden sein bitte die genannten Dateien prüfen und aus dem letzten stable release wiederherstellen.

    Gibt es eine Möglichkeit bei dem http-header Plugin CSP so zu konfigurieren, dass folgender Quellcode in meiner HTML Seite nicht durch CSP blockiert wird?

    Jein. So wie Re:Later schon geschrieben hat nur durch: script-src 'unsafe-inline' oder via dedizierten hash. Das sind alles aber nur Behelfslösungen für die "richtige" Lösung komplett auf inline JS und CSS zu verzichten und diese Funktionalität in JS/CSS Dateien auszulagern.


    Das Plugin http-header schreibt immer die hashes aus der script-src Direktive auch in die script-src-attr Direktive. Ist das so richtig oder der Grund für den Fehler?

    Jein zeig mir einmal bitte deine CSP Konfiguration "automatisch" sollte das Plugin das nicht machen. Das Problem an script-src-attr ist das es nur in chromium Browsern verfügbar ist: https://caniuse.com/mdn-http_h…ty-policy_script-src-attr

    Da bin ich als Depp schon Stunden im Kreis gelaufen. Die einzige Lösung, die ich bisher gefunden habe, ist Nonces auszuschalten und natürlich 'strict-dynamic', und eine Regel


    script-src: 'unsafe-inline' etc.


    hinzuzufügen.

    Die Kombination sollte aber auch nicht funktionieren. Denn wenn nonces aktiviert sind wird unsafe-inline ignoriert und greift dann nur bei Browsern welche keine nonces unterstützen?


    :thumbup: Danke, das wäre vielleicht sehr hilfreich. zero24 kann besser beurteilen, ob man da etwas in die ToDo Liste für ein neues Joomla aufnimmt. Bis später dann.

    Ich denke es geht hier um das Backend? Der Fokus bei 4.0 wurde auf das Frontend gelegt und ja es gibt noch einige inline scripte im Joomla 4 backend aber die meisten sollten schon auf "nutzen die Joomla API" umgestellt worden sein und werden damit von hashes und nonces abgefangen aber ich möchte nicht ausschließen das es auch noch welche gibt die an der Joomla API vorbei gehen besonders auch 3rd party extensions können hier schnell querschießen

    Ich meine die nonce Werte erscheinen nicht im HTTP Header. Dort sollten Sie aber stehen, genauso wie die Hash Werte. Hat man in der HTML Seite ein Script mit einem nonce Wert, z.B.

    Ja das meinte ich mit dem "{nonce}" placeholder, also nonce option aktivieren + placeholder in der script-src einbauen, das Plugin ersetzt dann den placeholder mit dem nonce wert. :)

    Man kann die CSP Funktion strict dynamic in dem plugin http header aktivieren. Sie wird aber falsch in den CSP header eingefügt. Dies sollte man zusammen mit den fehlenden nonce Werten korrigieren.

    Hi, was meinst du mit falsch? Für nonce gibt es eine option und in dem script-src option kannst du "{nonce}" (ohne die Anführungszeichen) einsetzen und zur Laufzeit wird der richtige nonce Wert gesetzt.


    Außerdem sollte man Optionen für SRI Subresource Integrity

    Wie stellst du dir das vor? Es war mal auf der Agenda das zu prüfen aber du als Site Owner musst die hashes prüfen und setzen. Wenn wir das "bei jeden neuen aufrufen der Seite machen" bist du ja nicht gegen das Problem geschützt da dann immer der neue Hash genommen wird. d.h. du musst den hash statisch für jedes externe script etc setzen. Außer du hast eine Idee wie man das automatisieren kann dann immer her mit den Ideen.


    HPKP public key pinning haben, was gerade bei https sinnvoll ist.


    Scheint aus allen aktuellen Browsern raus zu sein mit Expect-CT as alternative. Letztere ist als Header im Plugin hinterlegt und kann konfiguriert werden.

    Code
    Chrome unterstützt HPKP seit Oktober 2015 (Version 46),[3] hat es mit der Version 68 jedoch als „abgekündigt“ (deprecated) definiert und entfernte dessen Unterstützung mit der Version 72[4] wieder. Firefox unterstützte HPKP seit Januar 2015 (Version 35), entfernte die Unterstützung jedoch im Januar 2020 mit Version 72.[5] Safari und Edge unterstützten HPKP im Gegensatz zu Opera nicht.[6]

    HTTP Public Key Pinning – Wikipedia

    Fehler der nicht existiert ist auch gut. zero24 Nein, Joomla ist daher nicht PCI Compliant, da der Scan explizit auf das Problem hinweist, was dieses Cookie betrifft.

    Naja wenn der Fehler welcher reported wurde wie beschrieben ein Fase positiv ist dann sind wir auf der sicheren Seite :)


    Ich hab jetzt mit dem EU e-privacy directive Plugin mal alles an Cookies geblockt was nur so geht. Analytics ist da auch gleich mal tot.

    Ein Joomla session cookie wird dadurch wahrscheinlich nicht geblockt da dies ein technisch notwendiges Cookie ist um zu wissen ob du angemeldet bist oder nicht und Analytics werden von einem plain J3 auch nicht genutzt. ;)

    -> bei uns ist das Zeug in house gehostet wo auch allerhand anderes Zeug drauf läuft. Da einfach immer so upzugraden ist ein eigener Prozess wo man viel bedenken muss.

    FYI PHP 5.5.9 ist von 2014: https://www.php.net/ChangeLog-5.php#5.5.9 und wird gerade noch so von Joomla unterstützt. Ich kenne mich nicht im Detail mit PCI aus aber üblicherweise ist "Stand der Technik" immer ein Thema was man beachten sollte.

    Vielleicht auch ein Problem?

    Bei mir wird definitiv noch "Thread bearbeiten" angezeigt auch mit unserem Tester Account?


    Ich vermisse eine Möglichkeit, ausgewählte Themen in meinem Profil an irgendeiner Stelle zu speichern. Quasi eine Ablagemöglichkeit, ohne immer wieder die Suche ausführen zu müssen. Ist das in der neuen Version möglich?

    Ich habe so eine Feature noch nicht gesehen.


    Weiß nicht, ob das vorher auch schon war. Ist auch nicht wichtig, nur aufgefallen.

    Hab ich einmal weitergeben. Obs wirklich ein Fehler ist oder nicht kann ich nicht sagen. Meldung hab ich hier aufgemacht: https://www.woltlab.com/commun…C3%A4ten-nicht-angezeigt/

    Hallo,


    heute hat das Joomla Project Joomla in Version 4.1.1 sowie 3.10.7 veröffentlicht:

    Joomla 4.1.1 and 3.10.7 Release
    The Joomla Project is pleased to announce the release of Joomla 4.1.1 Stable - New standards in accessible website design
    www.joomla.org

    Joomla 4.1.1 und Joomla 3.10.7 sind da - Sicherheitsupdate


    Joomla 4.1.1 hat 8 security patches:

    • [20220301] Low Severity - Moderate Impact - Zip Slip within the Tar extractor (affecting Joomla! 3.0.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220302] Low Severity - Low Impact - Path Disclosure within filesystem error messages (affecting Joomla! 3.0.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220303] Low Severity - High Impact - User row are not bound to a authentication mechanism (affecting Joomla! 2.5.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220305] Low Severity - High Impact - Inadequate filtering on the selected Ids (affecting Joomla! 3.0.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220306] Low Severity - Low Impact - Inadequate validation of internal URLs (affecting Joomla! 2.5.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220307] Low Severity - Moderate Impact - Variable Tampering on JInput $_REQUEST data (affecting Joomla! 4.0.0 through 4.1.0) More information »
    • [20220308] Low Severity - Moderate Impact - Inadequate content filtering within the filter code (affecting Joomla! 4.0.0 through 4.1.0) More information »
    • [20220309] Low Severity - Moderate Impact - XSS attack vector through SVG (affecting Joomla! 4.0.0 through 4.1.0) More information »


    Joomla 3.10.7 hat 6 security patches:

    • [20220301] Low Severity - Moderate Impact - Zip Slip within the Tar extractor (affecting Joomla! 3.0.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220302] Low Severity - Low Impact - Path Disclosure within filesystem error messages (affecting Joomla! 3.0.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220303] Low Severity - High Impact - User row are not bound to a authentication mechanism (affecting Joomla! 2.5.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220304] Low Severity - Moderate Impact - Missing input validation within com_fields class inputs (affecting Joomla! 3.7.0 through 3.10.6) More information »
    • [20220305] Low Severity - High Impact - Inadequate filtering on the selected Ids (affecting Joomla! 3.0.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »
    • [20220306] Low Severity - Low Impact - Inadequate validation of internal URLs (affecting Joomla! 2.5.0 through 3.10.6 & 4.0.0 through 4.1.0) More information »