Beiträge von SniperSister

  • Der Media-Manager in J4 ist suboptimal (Timestamp bei Bilder)

    In der Vergangenheit gab es immer wieder Nutzerbeschwerden, weil Änderungen an Bestandsbildern (Bild ersetzt, Größe angepasst etc) im Backend nicht sofort sichtbar wurden, weil besagte Bilder im Browser-Cache waren. Der Timestamp hebelt den Cache aus um das Problem zu lösen.


    Grundsätzlich also durchaus eine gute Idee, eventuell aber wäre es sinniger, den Timestamp an das modification Date der Datei zu binden.

  • Gestaltung der Update-Pakete

    wilderer wenn ich dich richtig verstehe, vermischst du hier zwei Dinge:


    1. die Dateigröße der Update-Pakete

    2. die Frage ob jedes neue Feature in jedem Update mit drin sein muss


    Das sind völlig unterschiedliche Fragestellungen, die nichts miteinander zutun haben.

    Das Dateigrößen-Thema ist ein technisches Thema, das ist mit überschaubarem Aufwand lösbar.


    Die Frage, ob neue Features Core-Bestandteil sind oder nicht ist hingegen etwas völlig anderes. Dein Wunschszenario ist dabei, dass du dir quasi wie beiden Extensions genau die Core-Features aktivieren kannst, die du auf deiner Seite brauchst. Durchaus eine charmante Idee, die man mal bei der com_weblinks ausprobiert hat. Ergebnis: das ist garnicht so einfach. Denn es gibt fest verdrahtete Abhängigkeiten zwischen vielen Core-Erweiterungen, die man dafür erstmal auflösen müsste. Und da stellt sich die Frage, warum man dafür Ressourcen investieren sollte - welches Problem wird dadurch gelöst?

  • Hack Versuche?

    Zitat von flotte

    Offenbar bist Du dann bei einem Hoster, der nicht vom Joomla-Security-Teams über Core-Lücken informiert wird. Es wurde bei Erscheinen der Sicherheitslücke entsprechende Filterregeln verteilt, um solche Angriffe bereits auf Firewall-Ebene zu blocken.

    Strato wurde informiert.

  • IONOS - Änderung PHP 8 Standardeinstellung zur Fehlerausgabe - potentielle Sicherheitslücke

    Also: um es erstmal in aller Deutlichkeit zu sagen: der Umstand, dass ein System Fehlermeldungen mit Pfaden ausgibt bedeutet an sich erstmal noch nicht, dass man die Seite erfolgreich angreifen kann. Die Fehlermeldungen geben einem Angreifer "nur" interessante Hinweise zu verwendeten Systemkomponenten, Pfadstruktur, Betriebssystem und co - diese Hinweise kann man dann nutzen, um nach anderen Lücken zu suchen bzw. sie können helfen, andere Lücken auszunutzen.

    Voraussetzung für einen erfolgreichen Angriff ist dabei aber immer, dass es eben solche vorhanden Lücken überhaupt gibt. Ohne Lücke, kein erfolgreicher Angriff.


    Dennoch ist es natürlich Best Practice, das Error Reporting auf Produktivsystem möglichst "stumm" zu halten. Wenn in der Joomla Konfiguration das Error Reporting deaktiivert ist, werden dabei etwaige Vorgaben auf Betriebssystemlevel überschrieben. Es wäre dann somit egal, was Ionos da eingestellt hatte.

  • Wichtiges Sicherheitsupdate für J4 | 4.2.8

    Zitat von flotte

    Ich denke die vom Security-Team für die Hoster mitgeteilten mod-security-Regeln kann man auch mit htaccess realisieren.

    Ich möchte das hier nicht veröffentlichen, weil das ggf. auch potentiellen Angreifern hilft.

    Siehe Mitigation Option B:


    The Joomla 4.2.8 security fix and why it's NOT the end of the world
    Personal blog of Nicholas Dionysopoulos. I say what I mean and I mean what I say.
    www.dionysopoulos.me

  • Wichtiges Sicherheitsupdate für J4 | 4.2.8

    Zitat von WM-Loose

    Bin ich ab dem Update auf Joomla 4.2.8 geschützt und wenn bisher noch keine Angriffe erfolgt sind, bedeutet dies, dass die Daten über API noch nicht abgegriffen wurden? Kann ich dann auf die Passwortänderungen verzichten?

    Wenn du sicher sagen kannst, das keine Daten abgegriffen worden sind dann ja, dann kann man darauf verzichten.


    Zitat von WM-Loose

    tatsächlich durch eine Kompromitierung passieren kan

    Datenbank Daten abgreifen, eigene Verbindung zum Datenbank Server aufbauen, neuen Super User erzeugen, einloggen, backdoor installieren. Zack: Seite gehackt.

  • Joomla! 4.2.8 Sicherheitsankündigung

    Mit der Veröffentlichung von Joomla! 4.2.8 wird u.a. eine kritische Sicherheitslücke geschlossen. Das Update erscheint voraussichtlich am 16.02.2023 um 17 Uhr (MEZ).


    Das Joomla Sicherheits-Team (JSST) wurde über eine kritische Sicherheitslücke im Joomla! Core informiert. Da dies eine sehr wichtiger Sicherheitspatch ist, bereitet euch bitte darauf vor, eure Joomla Seiten am kommenden Donnerstag zu aktualisieren.


    Bevor Joomla! 4.2.8 nicht veröffentlicht wurde, können wir aus mehreren Gründen keine weiteren Informationen herausgeben.

  • Joomla Cache speichert URI?

    Zitat von tekknotrip

    JAMP ignoriert den Page-Cache (Plugin), reagiert aber auf den anderen Cache.

    Dann ist es am wahrscheinlichsten, dass das AMP Ding irgendwo die Ausführung von Joomla abbricht, bevor der Cache erzeugt werden kann.


    Zitat von tekknotrip

    Durch den Cache aber wird die Bedingung (.amp in der URI oder nicht) ignoriert.

    Durch den Cache wird der Code, der ohne Cache dazu führt dass Modules Anywhere überhaupt ausgeführt wird, nicht mehr ausgeführt. Da hat Modules Anywhere somit in der Tat keinen Einfluss drauf.