HTTP-Header Security Settings machen bei Extensions- und Joomla-Update Probleme

    Hallo!
    Ich verwende in meiner HTACCESS vier HTTP-Header-Security Settings. Solange diese aktiv sind, kann ich manche Extensions nicht über das Backend updaten wie z.B. die Extensions von RegularLabs (früher NoNumber).
    Auch die Joomla-Update-Prüfung funktioniert nicht, weil offensichtlich keine Verbindung zum Update-Channel aufgebaut werden kann. Erst wenn ich im Backend den Menüpunkt "Joomla-Update prüfen anklicke, gelingt die Verbindung und Update-Prüfung. Das Update selbst kann aber nicht durchgeführt werden, weil nach der erfolgten Datensicherung mit Akeeba kein Download des neuen Joomla erfolgt.


    Ich muss also vor jedem Update-Vorgang per FTP in meine htaccess und die oberen drei Security-Settings deaktivieren (auskommentieren), dann die Updates durchführen und prüfen und anschließend die htaccess wieder zurück ändern.


    Hier die vier Settings:

    Code
    Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' http://meine.piwik-domain.de https://www.initiative-s.de"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-XSS-Protection "1; mode=block"
Header set X-Content-Type-Options "nosniff"


    Frage:
    Was muss ich ändern, damit die Updates ohne den oben beschriebenen Änderungsaufwand erfolgen können, die Security-Settings aber weiterhin wirksam bleiben?

  • Zum hilfreichsten Beitrag springen

    Es gibt doch immer wieder was neues hmm
    Diese Header hatte ich noch gar nicht auf dem Schirm.
    Ich sag mal ganz salopp: Header die Udpates verhindern, sind aus sicherheitstechnischer Sicht keine Verbesserung der Sicherheit. ;(


    Bin eh skeptisch, denn die Auswertung der Header obliegt sicher den Browsern und kann daher auch einfach mißachtet werden. Ich habe daher Zweifel an dem Nutzen/Wirksamkeit allgemein, aber wie gesdagt ich kann mich täuschen, denn diese Headereinträge haben mich noch nicht beschäftigt.

    • Hilfreich

    Ich habe gerade mal versucht dass hier nachzustellen, hatte aber erwartungsgemäß keinen Erfolg - die Updates werden erfolgreich abgefragt, sowohl Serverseitig (Joomla macht die eigentliche Abfrage gegen die Update-Server, hier kann die .htaccess auch garnicht greifen) als auch Clientseitig (Browser fragt via AJAX den Update-Status ab und zeigt das Ergebnis).


    Was sagt deine Browser-Konsole beim Abruf der Updates? Dort müssten etwaige Fehler ausgegeben werden.


    flotte:

    Zitat

    Bin eh skeptisch, denn die Auswertung der Header obliegt sicher den Browsern und kann daher auch einfach mißachtet werden. Ich habe daher Zweifel an dem Nutzen/Wirksamkeit allgemein, aber wie gesdagt ich kann mich täuschen, denn diese Headereinträge haben mich noch nicht beschäftigt.


    Die Header greifen dann, wenn ein serverseitiger Angriff bereits erfolgreich war. Beispiel: die Seite hat eine XSS-Lücke über die externes JavaScript eingeschleust werden kann. Die CSP Header führen dann dazu, dass dieses externe JavaScript garnicht erst geladen wird, weil über die CSP ein Whitelisting erfolgt.

    Das ist richtig: Aktuelle Browserversionen von Chrome, Firefox usw. beachten die HTTP-Header und verweigern z.B. das Nachladen von Code fremder Websites / Server. Sofern also der Browser des Users aktuell und sein System nicht gehackt ist, erhält der Besucher meiner Website eine zusätzliche Sicherheit.
    Im Rahmen von Sicherheitsinitiativen Dritter könnte meine Website Auszeichnungen betr. Sicherheit erhalten.


    Ich finde die Maßnahme mit den HTTP-Headern sinnvoll, da meine drei aktuellen Websites immer wieder massiven Hackerangriffen ausgesetzt sind. Im Sommer 2016 haben polnische Hacker zwei Sites hacken und mich als Admin aussperren können. Mir blieb nur die vollständige Löschung des kompletten Webspace und der neu-Aufbau meiner Sites. Dabei waren meine Sites stets aktuell gehalten!


    Dass die dritte Site nicht ebenfalls gehackt wurde, hat damit zu tun, dass ich jede Site vom Webspace der anderen durch Quotas trenne, das Admin-Backend nur per https zugänglich ist und Admin-Username sowie Passwort aus 20-stelligen Zeichenketten bestehen.


    Auch zurzeit finden in ca. monatlichen Abständen durchschnittlich vier Angriffe je Woche statt. Bisher haben mich BruteForceStop und _Marcos-SQLI-LFI-Protector geschützt.
    Angesichts dieses Szenarios ist der Einsatz der HTTP-Header gewiss eine gute Idee (zu Gunsten meiner Site-Besucher).


    PS: Haben andere Joomla-Sitebetreiber eigentlich ähnlich intensive Erfahrungen mit Hackern machen müssen?

    Zitat von Clemens-XS

    Dass die dritte Site nicht ebenfalls gehackt wurde, hat damit zu tun, dass ich jede Site vom Webspace der anderen durch Quotas trenne, das Admin-Backend nur per https zugänglich ist und Admin-Username sowie Passwort aus 20-stelligen Zeichenketten bestehen.


    Auch zurzeit finden in ca. monatlichen Abständen durchschnittlich vier Angriffe je Woche statt. Bisher haben mich BruteForceStop und _Marcos-SQLI-LFI-Protector geschützt.
    Angesichts dieses Szenarios ist der Einsatz der HTTP-Header gewiss eine gute Idee (zu Gunsten meiner Site-Besucher).


    Hallo Clemens,


    ich habe vor Jahren schon meinen Adminzugang mit einem .htaccess Passwortschutz versehen. Seither habe ich gröstenteils Ruhe vor bestimmten Attacken. Mit dieser macht sich auch das BruteForceStop - Plugin fast Überflüssig, weil auch diese Art von angriffen von einigen Hostern schon von Haus aus geblockt werden.