Ich betrachte das parallel eröffnete Supportticket bei SIWECOS dann mal als gegenstandslos...
J5 war in SIWECOS noch nicht als "sicherer" Versionsbranch hinterlegt, ist nun angepasst.
Ich betrachte das parallel eröffnete Supportticket bei SIWECOS dann mal als gegenstandslos...
J5 war in SIWECOS noch nicht als "sicherer" Versionsbranch hinterlegt, ist nun angepasst.
Das Google Authenticator MFA Plugin heißt in Joomla 4+ "Multi-Faktor-Authentifizierung – Verifizierungscode" weil es verschiedene Anbieter (nicht nur Google) unterstützt, die das TOTP Protokoll unterstützen. Soweit ich weiß hat Entrust in unendlicher Weisheit aber beschlossen, diesen offenen Standard nicht zu verwenden, sondern irgendeinen hauseigenen Kram gebaut.
This is the German forum.
I assume that the post author is well aware of that, as it's hard to overlook. The answers are helpful nontheless.
Die Einschätzung bei BSI ist nach Hinweis korrigiert worden: https://wid.cert-bund.de/porta…ry?name=WID-SEC-2024-0430
Dass jetzt noch etwas als Update-Quelle im J3 Backend eingetragen werden soll, konnte ich nicht finden.
Das ist der entscheidende Teil des ganzen Themas, erst damit weiß die Joomla Seite etwas über die Updates.
Die Einstufung des BSI basiert vermutlich darauf, dass zwei der Lücken für XSS Angriffe genutzt werden können und ein XSS Payload, wenn er mit Admin-Rechten ausgeführt wird, im Grunde genommen eine Remote-Code-Execution ist.
Nur einer der beiden Angriffe kann aber überhaupt ohne erweiterte Rechte ausgeführt werden und das erfordert bestimmte Bedingungen und liefert nur einen sehr schmalen Vektor, daher auch unsere Einschätzung als "High", die sich aus dem Score von 7,5 ableitet.
Der Pixel und die Conversion API haben eine entscheidende Gemeinsamkeit: sie machen nur dann Sinn, wenn sie zielgerichtet eingebunden sind. Was meine ich damit?
Der Umstand, dass ein reiner Pageview passiert (also ein Nutzer der von Facebook kam, deine Seite aufruft) hilft dir nur mäßig weiter. Du willst ja wissen, ob er etwas getan hat, was für dich einen relevanten Mehrwert hat, also eine Kontaktanfrage gestellt hat, was gekauft hat, deine Telefonnummer angeklickt hat etc.
Diese Art von Events können im Kontext von Joomla ja aber sowohl im Core als auch in jeder beliebigen Dritterweiterung auftreten - und hier wirds spaßig: wie soll ein Entwickler eines solchen Conversion-API-Plugins denn vorab wissen, mit welcher Dritterweiterung du deine Kontaktformulare baust? Oder anhand welcher Interaktion sich ein "Verkauf" ergibt?
Ich sehe da keine generische Lösung für.
Die Visforms Entwickler nutzen nicht die von Joomla vorgesehenen Methoden um JS und CSS an die Seitenausgabe anzuhängen (Stichwort "Web Asset Manager") sondern gehen ihren eigenen Weg. Dadurch kann Joomla keine passenden Nounces generieren und eine strikte CSP verhindert die korrekte Ausführung. Die richtige Lösung ist, dass Visforms ihre Ausgabe anpasst, die Alternative ist das Erlauben von unsafe-inline.
Welche Events sollen denn da getrackt werden? Stelle mir das nicht unkomplex vor..
Schau mal in den Reiter „Konsole“ der Entwicklertools deines Browsers, dort wirst du vermutlich Fehlermeldungen finden
Da ist das Debugging für Sprachdateien an, findest du in der globalen Konfiguration
WM-Loose schick mir mal bitte per PN einen Zugang zur Seite, ich muss mir das mal angucken.
Welches Risiko siehst du?
Wir haben regelmäßig Nutzer aus dem Pott bei der JUG in Köln, sibd zwar ein paar Meter aber: herzliche Einladung!
Ist in der configuration.php eine cookie domain gesetzt? Falls ja: raus nehmen.
Für mich ist die einzige Erklärung für die Empfehlung, die Variable leer zu lassen, dass das Risiko eines Angriffs in einer modernen, verantwortungsbewussten Serverkonfiguration als ausgeschlossen angesehen wird und daher der Vorteil des automatischen korrekten Auslesens aus dem Header überwiegt.
Korrekt. Host Header Injections sind in der Praxis, insbesondere im Kontext des Massenmarkts nicht praktikabel da Webserver in der Regel mit vhosts konfiguriert werden.
Ich weiß von mindestens 2 Projekten (ein Plugin, ein Github repo) wo andere Devs den Fix für 3.x zurückportiert haben, da solltet ihr also fündig werden können
Und wenn ich genug optimiert habe, dann lösche ich meine Website bei GoogleSearch, warte paar Tage und trage sie erneut ein in der Erwartung / Hoffnung, dass GSC dann komplett neu crawlen wird.
Das wird nicht passieren. Die GCS ist unabhängig vom eigentlichen Indexierungsstatus der Website.
Wie machst du den Login? Nutzt du ein spezielles Modul oder den Login einer Dritterweiterung?
Mach nen separaten Jammer-Thread und bekunde dort der Welt dein Leid, kein Problem. Nur spar dir bitte das kapern von Bestandsthreads mit konkreten thematischen Fragestellungen.