Beiträge von JoomlaWunder

    Nun habe ich die Antwort vom Hoster erhalten:


    "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."


    Den ersten Satz kann ich nicht ganz nachvollziehen, da ich in den PHP-Dateien nirgends etwas ergänzt habe.

    Das würde höchstens für eine andere Webseite zutreffen, auf der ich das Plugin "HTTP Header" teste.


    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.

    Den Link als Menüpunkt definiert (Menüeintragstyp: URL), ausgeblendet...Der Link ist ja trotzdem da und abrufbar.

    Der Werbepartner findet sein Banner trotzdem 2x.

    Der Menüeintragstyp "URL" ist vermutlich der falsche "Typ" dafür. Hast du einen Link zur Seite? Praktisch ist das immer einfacher nachzuvollziehen als theoretisch.

    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.

    Und wie gesagt, der STS wird bereits vom Hoster gesetzt, sobald https verwendet wird.


    htaccess.txt


    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.


    Woran könnte das liegen?


    Bzgl. der htaccess ist mein Hoster noch am testen?

    Ich schütze seit Jahren meine administrator-Verzeichnis mittels Passwort und aktualisiere zeitnah Joomla und die Drittanbieter-Erweiterungen. Wenn man dann noch ein möglicherweise vorhandenes Kontaktformular sicher macht und auch die Benutzerregistrierung deaktiviert, wenn sie nicht benötigt wird, dann hat man schon sehr viel erreicht in Punkto Sicherheit. Bisher hatte ich damit 0 gehackte Seitem und keine Spam-Probleme.


    Falls du noch mehr möchtest, schau dir mal die Möglichkeiten an, die "HTTP Security Header" bieten.


    Aus Interesse: Hast du mal einen Link zu solch einem Artikel?

    Bisher habe ich verschiedene Tarife des gleichen Hosters getestet. Ohne Erfolg!

    Meine Anfrage wurde an die entsprechende Fachabteilung weitergeleitet. Da warte ich morgen noch die Antwort ab.

    Die Alternative wäre SSL über Xampp einzurichten. Das könnte aber weitere Probleme mit sich bringen, weshalb ich davon erst mal Abstand nehme.

    Da scheint etwas über http statt über https aufgerufen zu werden bzw. die Konfiguraton http -> https ist nicht korrekt.


    EDIT: Macht es einen Unterschied, ob die die Seite direkt mit https://.... aufrufst, oder über http:// oder eventuell nur die Domain eingibst?

    Eventuell einfach mit einer Formularkomponente:

    Kunde gibt Kontaktdaten an, setzt die Haken für die gewüschte Leistung, lädt eine oder mehrere Dateien hoch, wählt die Zahlungsart (z.B. Paypal), akzeptiert verschiedene Punkte wie DSE usw., bekommt die Gesamtsumme angezeigt und klickt "Zahlungspflichtig bestellen" an!

    Wurden auch Browser- und Joomla-Cache mal geleert? Seite neu geladen?


    Kann auch sein, dass wenn du in den Menüpunkten unter "Seitenanzeige" entsprechende Einstellungen vornimmst, diese Funktion nicht mehr angewendet wird. Dann würde ich vermuten, dass du den Namen direkt irgendwo unter Seitenanzeige hinzugefügt hast.

    Nein, versuch mal die Header als letztes in der htaccess zu setzen.

    Das macht leider keinen Unterschied.


    Ich frage mich gerade, ob das automatische Setzen des HSTS durch den Hoster auch dieses "includeSubDomains" beinhaltet? Die Probleme kommen ja erst, sobald www ins Spiel kommt (in Verbindung mit http->https).

    Ich kann da nämlich nur ein "max-age" erkennen.


    Beim Hoster kann ich keine diesbezüglichen Einstellmöglichkeiten erkennen. Da muss ich nun auf seine Antwort warten.


    Ich werde den HSTS einfach mal über die .htaccess unsetten und dahinter gleich wieder neu einfügen.

    EDIT: Nein! Das unset und das neue Setzen funktioniert nicht. Keine Reaktion!

    Ja, den CSP Header müsste ich nach weiteren Tests noch anpassen, sobald es läuft. Den habe ich erstmal wieder als Kommentar gesetzt.


    Ich habe gerade in Erfahrung gebracht, dass mein Hoster den HTSTS automatisch setzt, sobald mit https gearbeitet wird. Vielleicht führt die doppelte Angabe zu meinen Problemen. Allerdindgs hatte ich den bei meinen ersten Versuchen gar nicht verwendet, da er bereits bei der Analyse angezeigt wurde. Ich habe mir da jetzt mal ein Ticket geholt. Mal schauen, was mein Hoster meint.


    Bisher habe ich erreicht, dass für folgende Varianten die Header gesetzt werden können:

    http: // example.com

    https: // example.com

    http: // www.example.com


    Alle Varianten leiten zur https: // www.example.com weiter, wo dann keine Header außer HSTS gefunden werden können, obwohl gesetzt.


    1.) Im Verzeichnis, auf das die Domain gestellt ist, existiert das Problem nicht.


    2.) Im Verzeichnis, auf das die www-Subdomain gestellt ist, liegt die .htaccess, welche oben das Setzen der Header enthält und darunter die http->https-Weiterleitung. Ich vermute auch, dass es irgendein Problem mit der Reihenfolge sein könnte.


    EDIT: Müssen die Headers nicht oberhalb von "RewriteEngine On" stehen?

    Welchen Zweck soll das haben?

    (Ein Lotto-Laden macht sich auch nicht unsichtbar für Kunden, die kein Lotto spielen)


    Eventuell könnte man den User informieren, dass eine Anmeldung nicht möglich ist, weil die Cookies nicht gesetzt werden können.

    Ich weiß gerade nicht, was passiert, wenn man versucht sich (ohne Cookies) anzumelden. Kommt da eventuell bereits solch eine Meldung?

    Es gäbe einige Hoster, wo du dir einen kostenlosen Probeaccount einrichten kannst, um dort mal dein Backup einzuspielen. Alternativ natürlich lokal über Xampp und Co.

    Die Backups auf dem eigenen Rechner zu sichern, ist schon sinnvoll, damit man sie notfalls überall wieder einspielen kann.

    Ob und warum du mit deinem Hoster solche Probleme hast, kann ich auch nicht beurteilen.


    Es wurde dir ja auch schon angeboten, mal eines deiner Backups woanders einzuspielen, um mal zu schauen, was Sache ist.

    Habe den Code nochmal geprüft und es reicht in Joomla 3 die „HTTPs erzwingen“ Option auf „gesamte Seite“ zu setzen.

    SniperSister:

    Ist zwar schon älter, passt aber exakt zu meinem Problem:

    Auf meinen Seiten wird auch das nicht-gesetzte Secure-Flag bemängelt (habe nur http only). Nun ist es so, dass ich die https-Weiterleitung über die .htaccess realisiert habe und nicht über die Aktivierung von "HTTPS erzwingen" im Backend.


    1. Gibt es weitere Möglichkeiten, das Secure-Flag zu setzen?

    2. Könnte es Probleme geben, wenn externe Anbieter (z.B. von Cookie Consent Manager-Tools) Ihre Cookies setzen, um die Cookie-Zustimmungen bzw. Einstellungen zu speichern?

    Hallo,


    ich bin gerade am Setzen/Testen und Analysieren von verschiedenen "HTTP Security Headers".


    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.


    Bei der Analyse durch siwecos.de oder auch securityheaders.com stehe ich vor folgendem Problem, weil beim Aufruf der Seite folgende Weiterleitungen stattfinden. Die erkannten Header stehen in Klammern:


    example.de/ (HTST)

    -> 301: example.de/de/ (X-Content-Type-Options, X-Frame-Options, Referrer-Policy)

    -> 301: example.de/de (Antwort: 200) (HTST)


    Letztendlich wird mir das Ergebnis (Bewertung/Punktzahl) der letzten Seite (200) angezeigt.

    1.) Doch warum werden nicht immer alle gesetzten Header angezeigt? Das Ergebnis wird dadurch verfälscht.

    2.) Und warum könnte bei der ersten Weiterleitung der Header STS fehlen?


    3.) Inwiefern spielen Joomla-Cache und OPCache eine Rolle? Letzterer sollte doch keinen Einfluss haben? Oder wird da über PHP etwas gesetzt, was irgendwie dawischenfunkt?


    EDIT: Alles wird über die .htaccess gesetzt. Das Header-Plugin ist nicht installiert.

    Joomla 3.9.26, PHP 7.4


    Ergänzung:

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

    Oder sollte ich den zusätzlich angeben mit entsprechender Zeitangabe? Nicht, dass der dann doppelt gesetzt ist.


    Weiterer Beitrag wegen Zeitüberschreitung:


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


    Danke!


    Neueste Erkenntnisse:

    Ich habe mal ein paar Test mit einer einfachen Webseite gemacht, also keine mehrsprachige Webseite.

    Das Problem bleibt, die Ursache kann aber nun etwas eingeschränkt werden.


    Per .htaccess wird von http -> https weitergeleitet.

    Die Analyse erfolgt über securityheaders.com

    1.Lasse ich die http-Version analysieren, dann werden alle gesetzten Header angezeigt.

    2. Lasse ich die https-Version analysieren, wird nur der STS angezeigt.


    Ich verstehen nicht, wie dieser Dienst die http->https-Weiterleitung in der .htacccess "aushebeln" kann. Nun gut, man braucht dort bei der Analyse dieses "Follow redirects" nicht aktivieren, dennoch finde ich es seltsam.


    Bei Analyse über siwecos.de wird immer nur der STS Header angezeigt. Ich vermute, dass hier die Weiterleitung zu https autmatisch erfolgt. Kann ja auch nirgends deaktiviert werden (zumindest habe ich es noch nicht gefunden).


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