Hallo zusammen,
ich möchte einen wichtigen Tipp zum Thema Sicherheit und Performance mit euch teilen, der besonders für alle relevant ist, die moziloCMS im Shared Hosting (z. B. bei IONOS oder ähnlichen Massenhostern) betreiben.
Problem
Wenn mann z.B. eine .htaccess-Regel hat, um auf HTTPS und das "www." vor der Domain umzuleiten ähnlich wie dieser hier:
Wenn nun ein Angreifer die manipulierte Adresse www.evil.com an deinen Server schickt, fragt die Bedingung: Beginnt www.evil.com nicht mit www.? Nein, sie beginnt ja mit www. (falsch).
Da die Bedingung damit fehlschlägt, wird die sichere Weiterleitung übersprungen. Der Server bricht die Prüfung ab und reicht die manipulierte Fremddomain www.evil.com ungefiltert weiter in das CMS. Ein Angreifer kann dann bei seinem Aufruf einfach einen manipulierten HTTP-Host-Header wie "www.evil.com" mitsenden.
Das birgt im Shared Hosting das Risiko von "Host Header Spoofing", da dort aus Kompatibilitätsgründen fast immer die Apache-Einstellung "UseCanonicalName Off" aktiv ist. Dadurch reicht der Webserver einem manipulierten Host-Header wie ("www.evil.com") ungefiltert an PHP und damit direkt an moziloCMS weiter, was für Phishing-Angriffe oder schädliche Link-Injektionen missbraucht werden kann.
Abhilfe
Hier ist eine optimierte und gehärtete Version für die .htaccess, die dieses Problem radikal löst und gleichzeitig die Ladezeit verbessert ("www.deine-domain.de" muss natürlich gegen die echte Domain getauscht werden):
Was wurde hier genau verbessert?
Maximale Sicherheit gegen Host-Spoofing Die neue Regel prüft exakt gegen deine echte Domain: !^www.deine-domain.de$ (Ist es NICHT exakt meine Domain?). Jeder falsche oder manipulierte Host erzwingt sofort einen harten 301-Redirect auf deine echte Domain, wodurch der schädliche Header weggewaschen wird, bevor Schaden entsteht.
Performance-Schub (1-Step-Redirect statt Ketten) Wer früher "http://meine-domain.de" (ohne HTTPS und ohne www) aufgerufen hat, flog oft durch eine Kette: Erst der Redirect auf HTTPS, dann ein zweiter Redirect auf WWW. Das sind zwei HTTP-Requests, die spürbar auf die Time to First Byte (TTFB) schlagen und die Core Web Vitals verschlechtern. Durch die logische Verknüpfung mit [,OR] in der neuen Version wird jede falsche Kombination in einem einzigen Schritt direkt auf die Ziel-URL korrigiert.
Quellen und weiterführende Informationen für technisch Interessierte:
OWASP Web Security Testing Guide:
Die OWASP beschreibt in diesem Dokument im Detail, wie Angreifer unvalidierte Host-Header ausnutzen können (z. B. für Cache-Poisoning oder die Manipulation von Passwort-Reset-Funktionen). Die dortige Empfehlung besagt klar, dass eine strikte Validierung der Header-Werte stattfinden muss. Da man im Shared Hosting die globale Serverkonfiguration nicht anpassen kann, simulierst unsere .htaccess-Regel genau dieses geforderte Whitelisting:
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
PortSwigger Web Security Academy:
Eine exzellente, praxisnahe Aufarbeitung der Angriffsvektoren (wie Cache-Poisoning oder das Einschleusen schädlicher Payloads), die durch unvalidierte Host-Header entstehen, findet sich im Fachbereich der PortSwigger Academy:
https://portswigger.net/web-security/host-header
Beste Grüße und viel Erfolg beim Härten eurer moziloCMS-Installationen!
ich möchte einen wichtigen Tipp zum Thema Sicherheit und Performance mit euch teilen, der besonders für alle relevant ist, die moziloCMS im Shared Hosting (z. B. bei IONOS oder ähnlichen Massenhostern) betreiben.
Problem
Wenn mann z.B. eine .htaccess-Regel hat, um auf HTTPS und das "www." vor der Domain umzuleiten ähnlich wie dieser hier:
Code Auswählen
# ACHTUNG: BEISPIEL FÜR EINE UNSICHERE REGEL!
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.meine-domain.de/$1 [R=301,L]
Die Schwachstelle liegt im Detail: Die Bedingung prüft nur, ob die Eingabe nicht mit www. beginnt.Wenn nun ein Angreifer die manipulierte Adresse www.evil.com an deinen Server schickt, fragt die Bedingung: Beginnt www.evil.com nicht mit www.? Nein, sie beginnt ja mit www. (falsch).
Da die Bedingung damit fehlschlägt, wird die sichere Weiterleitung übersprungen. Der Server bricht die Prüfung ab und reicht die manipulierte Fremddomain www.evil.com ungefiltert weiter in das CMS. Ein Angreifer kann dann bei seinem Aufruf einfach einen manipulierten HTTP-Host-Header wie "www.evil.com" mitsenden.
Das birgt im Shared Hosting das Risiko von "Host Header Spoofing", da dort aus Kompatibilitätsgründen fast immer die Apache-Einstellung "UseCanonicalName Off" aktiv ist. Dadurch reicht der Webserver einem manipulierten Host-Header wie ("www.evil.com") ungefiltert an PHP und damit direkt an moziloCMS weiter, was für Phishing-Angriffe oder schädliche Link-Injektionen missbraucht werden kann.
Abhilfe
Hier ist eine optimierte und gehärtete Version für die .htaccess, die dieses Problem radikal löst und gleichzeitig die Ladezeit verbessert ("www.deine-domain.de" muss natürlich gegen die echte Domain getauscht werden):
Code Auswählen
RewriteEngine On
RewriteBase /
# 1. SCHUTZ VOR HOST-SPOOFING & HTTPS/WWW-ZWANG
# Wenn der Host NICHT exakt deine Domain ist OR HTTPS aus ist...
RewriteCond %{HTTP_HOST} !^www\.deine-domain\.de$ [NC,OR]
RewriteCond %{HTTPS} off
# ...dann jage ALLES sofort auf die korrekte, sichere URL.
# Das wäscht jeden gefälschten Host-Header sauber, bevor er mozilo erreicht.
RewriteRule ^(.*)$ https://www.deine-domain.de/$1 [L,R=301]
# 2. Mozilo Standard-Regeln (unverändert, aber sauber getrennt)
# mozilo_start
...
...
# mozilo_end
Was wurde hier genau verbessert?
Maximale Sicherheit gegen Host-Spoofing Die neue Regel prüft exakt gegen deine echte Domain: !^www.deine-domain.de$ (Ist es NICHT exakt meine Domain?). Jeder falsche oder manipulierte Host erzwingt sofort einen harten 301-Redirect auf deine echte Domain, wodurch der schädliche Header weggewaschen wird, bevor Schaden entsteht.
Performance-Schub (1-Step-Redirect statt Ketten) Wer früher "http://meine-domain.de" (ohne HTTPS und ohne www) aufgerufen hat, flog oft durch eine Kette: Erst der Redirect auf HTTPS, dann ein zweiter Redirect auf WWW. Das sind zwei HTTP-Requests, die spürbar auf die Time to First Byte (TTFB) schlagen und die Core Web Vitals verschlechtern. Durch die logische Verknüpfung mit [,OR] in der neuen Version wird jede falsche Kombination in einem einzigen Schritt direkt auf die Ziel-URL korrigiert.
Quellen und weiterführende Informationen für technisch Interessierte:
OWASP Web Security Testing Guide:
Die OWASP beschreibt in diesem Dokument im Detail, wie Angreifer unvalidierte Host-Header ausnutzen können (z. B. für Cache-Poisoning oder die Manipulation von Passwort-Reset-Funktionen). Die dortige Empfehlung besagt klar, dass eine strikte Validierung der Header-Werte stattfinden muss. Da man im Shared Hosting die globale Serverkonfiguration nicht anpassen kann, simulierst unsere .htaccess-Regel genau dieses geforderte Whitelisting:
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
PortSwigger Web Security Academy:
Eine exzellente, praxisnahe Aufarbeitung der Angriffsvektoren (wie Cache-Poisoning oder das Einschleusen schädlicher Payloads), die durch unvalidierte Host-Header entstehen, findet sich im Fachbereich der PortSwigger Academy:
https://portswigger.net/web-security/host-header
Beste Grüße und viel Erfolg beim Härten eurer moziloCMS-Installationen!
