4
Mit htaccess third-party-scripts einer bestimmten Domain erlauben
Ich betreibe zwei Joomla-Websites und eine Matomo-Analytic-Installation nach folgendem URL-Muster:
Domain-1 mit einer Joomla Erweiterung "Buchungskalender".
Domain-2
Matomo.Domain-1
Schon länger beobachte ich, dass Webbrowser auf meiner "Domain-2" keine Matomo-Scripte ausführen , die von der Subdomain "Matomo.Domain-1" stammen, obwohl ich in Matomo CORS für die Domain-2 frei gegeben habe und auch versucht habe, in der htaccess der "Domain-2" die Verbindung zu "Matomo.Domain-1" als "Same-Origin" zu definieren.
Diese Problematik blieb bisher ungelöst.
Jetzt kam eine neue Aufgabe hinzu:
Auf "Domain-1" ist eine Joomla-Extension "Buchungskalender" installiert, über die meine Kunden einen Termin buchen können. Diese Extension funktioniert einwandfrei. Der Buchungskalender wird aus UI-Gründen in einen iFrame geladen und alle weiteren Vorgänge des insgesamt vierstufigen Ablaufs (vier verschiedene Ansichten, die im iFrame nacheinander dargestellt werden bis zum Abschluss der Buchung) funktionieren einwandfrei.
Nun möchte ich, dass dieser Buchungskalender auch von "Domain-2" aus zuverlässig erreicht werden kann. Auch hier soll der Buchungskalender (wie in "Domain-1") in einem iFrame arbeitet.
Mir ist klar, dass hierzu erlaubt werden muss, dass innerhalb des Context der "Domain-2" Inhalt der "Domain-1" in einen iFrame geladen wird und JS sowie PHP aus der "Domain-1" innerhalb der "Domain-2" ausführbar sein müssen.
Daraus ergeben sich zwei Fragen an die Community hier:
1.) Ist es überhaupt möglich, durch entsprechende Regeln und Definitionen in den htaccess-Dateien der beteiligten Domains dafür zu sorgen, dass auch aktuelle, stark auf Sicherheit ausgelegte Web-Browser die o.g. Scripte und PHP-Funktionen garantiert ausführen?
Wenn nein, erübrigt sich Frage 2.
2.) Welche Regeln und Definitionen in der htaccess von "Domain-1" und welche in der htaccess von "Domain-2" muss ich benutzen, damit mein Vorhaben gelingt?
Das hier ist aktueller Stand der Dinge:
In "Domain-1" ist CORS zu Gunsten der "Domain-2" gesetzt. Und hier sind die Header-Definitionen der htaccess zu "Domain-1"
Hier sind die Header-Definitionen der htaccess zu "Domain-2"
Domain-1 mit einer Joomla Erweiterung "Buchungskalender".
Domain-2
Matomo.Domain-1
Schon länger beobachte ich, dass Webbrowser auf meiner "Domain-2" keine Matomo-Scripte ausführen , die von der Subdomain "Matomo.Domain-1" stammen, obwohl ich in Matomo CORS für die Domain-2 frei gegeben habe und auch versucht habe, in der htaccess der "Domain-2" die Verbindung zu "Matomo.Domain-1" als "Same-Origin" zu definieren.
Diese Problematik blieb bisher ungelöst.
Jetzt kam eine neue Aufgabe hinzu:
Auf "Domain-1" ist eine Joomla-Extension "Buchungskalender" installiert, über die meine Kunden einen Termin buchen können. Diese Extension funktioniert einwandfrei. Der Buchungskalender wird aus UI-Gründen in einen iFrame geladen und alle weiteren Vorgänge des insgesamt vierstufigen Ablaufs (vier verschiedene Ansichten, die im iFrame nacheinander dargestellt werden bis zum Abschluss der Buchung) funktionieren einwandfrei.
Nun möchte ich, dass dieser Buchungskalender auch von "Domain-2" aus zuverlässig erreicht werden kann. Auch hier soll der Buchungskalender (wie in "Domain-1") in einem iFrame arbeitet.
Mir ist klar, dass hierzu erlaubt werden muss, dass innerhalb des Context der "Domain-2" Inhalt der "Domain-1" in einen iFrame geladen wird und JS sowie PHP aus der "Domain-1" innerhalb der "Domain-2" ausführbar sein müssen.
Daraus ergeben sich zwei Fragen an die Community hier:
1.) Ist es überhaupt möglich, durch entsprechende Regeln und Definitionen in den htaccess-Dateien der beteiligten Domains dafür zu sorgen, dass auch aktuelle, stark auf Sicherheit ausgelegte Web-Browser die o.g. Scripte und PHP-Funktionen garantiert ausführen?
Wenn nein, erübrigt sich Frage 2.
2.) Welche Regeln und Definitionen in der htaccess von "Domain-1" und welche in der htaccess von "Domain-2" muss ich benutzen, damit mein Vorhaben gelingt?
Das hier ist aktueller Stand der Dinge:
In "Domain-1" ist CORS zu Gunsten der "Domain-2" gesetzt. Und hier sind die Header-Definitionen der htaccess zu "Domain-1"
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self' https://Domain-02.de https://Matomo.Domain-01.de"
Header set X-Robots-Tag "index, follow"
Header set X-Permitted-Cross-Domain-Policies "none"
Header set Referrer-Policy "origin-when-cross-origin"
Header set Cross-Origin-Opener-Policy "same-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set Cross-Origin-Resource-Policy "same-origin"
Header always set Strict-Transport-Security "max-age=63072000"
SetEnv modHeadersAvailable true
</IfModule>Hier sind die Header-Definitionen der htaccess zu "Domain-2"
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self' https://Domain-1.de https://Matomo.Domain-1.de"
Header set X-Robots-Tag "index, follow"
Header set X-Permitted-Cross-Domain-Policies "none"
Header set Referrer-Policy "origin-when-cross-origin"
Header set Cross-Origin-Opener-Policy "same-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set Cross-Origin-Resource-Policy "same-origin"
Header always set Strict-Transport-Security "max-age=63072000; preload"
SetEnv modHeadersAvailable true
</IfModule>
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668598
Url: https://administrator.de/forum/mit-htaccess-third-party-scripts-einer-bestimmten-domain-erlauben-668598.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
4 Kommentare
Neuester Kommentar
Nur als Anmerkung: X-Frame-Options is deprecated und sollte nur durch eine CSP mit frame-ancestors ersetzt werden .., und das SAMEORIGIN verhindert bei dir genau das was du eigentlich willst, most strict option wins.
Danke dir für deinen Hinweis auf die ersten beiden Zeilen in der htaccess. Vor wenigen Wochen wurde mir das Einfügen dieser Zeilen noch dringend empfohlen. Und da ich mich nicht gut auskenne, habe ich die eingefügt. Jetzt aufgrund der Hinweise bei Mozilla sehe ich, dass beide Zeilen raus sollten.
Die habe ich jetzt gelöscht.
Als Nächstes fand ich dann bei Mozilla den Hinweis, dass ich bei COOP "require-corp" setzen sollte, damit beim Laden von Ressourcen Dritter nur solche berücksichtigt werden, bei denen CORS gesetzt ist (wie z.B. bei "Domain-1" und "Matomo.Domain-1") sodass meine "Domain-2" darauf zugreifen kann.
Also habe ich geändert:
Im Brave-(Chrome)-Browser sehe ich in der Konsole bei "Netzwerk", was geladen und was geblockt wird und teils auch, warum.
In der Konsole wird jetzt das Laden von Matomo Scripten verhindert wegen der Referrer-Policy "origin-when-cross-origin". Ich habe mangels Verständnis alle zulässigen Optionen für die Referrer-Policy ausprobiert, aber auch bei "unsafe-url" wurde blockiert.
Setze ich diese Regel durch Auskommentieren ganz außer Kraft, wird sie offensichtlich vom Browser automatisch durch "strict-origin-when-cross-origin" ersetzt.
Naja, wenn es bereits daran scheitert, dann würde eine Änderung der Cross-Origin-Resource-Policy auf "cross-origin" auch nix mehr ändern.
Vielleicht liegt es an dem im Brave-Browser eingebauten "Brave-Shield" / Brave-Schutz, dass diese Header-Options nicht die von mir gewünschte Wirkung haben?
Moderne Android-Browser und Safari blockieren hier anscheinend in ähnlicher Weise.
Vielleicht ist meine Frage 1 dann doch mit NEIN zu beantworten?
Die habe ich jetzt gelöscht.
Als Nächstes fand ich dann bei Mozilla den Hinweis, dass ich bei COOP "require-corp" setzen sollte, damit beim Laden von Ressourcen Dritter nur solche berücksichtigt werden, bei denen CORS gesetzt ist (wie z.B. bei "Domain-1" und "Matomo.Domain-1") sodass meine "Domain-2" darauf zugreifen kann.
Also habe ich geändert:
Header set Cross-Origin-Opener-Policy "require-corp" Im Brave-(Chrome)-Browser sehe ich in der Konsole bei "Netzwerk", was geladen und was geblockt wird und teils auch, warum.
In der Konsole wird jetzt das Laden von Matomo Scripten verhindert wegen der Referrer-Policy "origin-when-cross-origin". Ich habe mangels Verständnis alle zulässigen Optionen für die Referrer-Policy ausprobiert, aber auch bei "unsafe-url" wurde blockiert.
Setze ich diese Regel durch Auskommentieren ganz außer Kraft, wird sie offensichtlich vom Browser automatisch durch "strict-origin-when-cross-origin" ersetzt.
Naja, wenn es bereits daran scheitert, dann würde eine Änderung der Cross-Origin-Resource-Policy auf "cross-origin" auch nix mehr ändern.
Vielleicht liegt es an dem im Brave-Browser eingebauten "Brave-Shield" / Brave-Schutz, dass diese Header-Options nicht die von mir gewünschte Wirkung haben?
Moderne Android-Browser und Safari blockieren hier anscheinend in ähnlicher Weise.
Vielleicht ist meine Frage 1 dann doch mit NEIN zu beantworten?
Ich habe zu meiner Frage 1 zusammen mit einem ITler das Verhalten des Brave-Browsers (Chromium-Version) geprüft und wir fanden heraus:
1.) Wenn im "Brave-Schutz" die maximale Schutzstufe = "aggressives Blockieren von Trackern und Anzeigen" aktiviert ist, werden Scripte nicht einmal dann ausgeführt, wenn sie von einer Subdomain stammen. In meinem Fall wird also auf "Domain-1" eine Analyse mit Matomo verhindert, wobei Matomo auf einer Subdomain von "Domain-1" läuft.
2.) Wenn im "Brave-Schutz" die mittlere Schutzstufe = "Tracker und Werbung blockieren" aktiviert ist, werden Scripte aus einer Subdomain ausgeführt. Scripte aus anderen Domains werden blockiert, auch wenn in den htaccess Regeln der beiden beteiligten Domains diese Scriptausführung erlaubt wird.
3.) Wenn der Brave-Schutz gegen Tracker und Werbung deaktiviert wird, können Scripte auch von "Third-Party" ausgeführt werden, sofern nicht AddOns im Browser diese blockieren wie z.B. uMatrix oder uBlockOrigin.
4.) Andere Browser und Browser für Android:
Aufgrund von Rückmeldungen von Websitebesuchern hat Safari standardmäßig einen Schutz aktiviert, der mindestens der Stufe 2 in der obigen Beschreibung entspricht. Gleiches gilt für die Standard-Einstellungen des Android-Browsers Vanadium, der beim googlefreien Android-OS "GrapheneOS" mit installiert wird.
Der Android-Brave-Browser reagiert schärfer, als im obigen Punkt 2 beschrieben und lässt auch in der mittleren Schutzstufe nicht zu, dass Scripte aus einer Subdomain im Content der Hauptdomain ausgeführt werden.
Schlussfolgerung:
Aufgrund der prinzipiell natürlich zu befürwortenden Schutzmaßnahmen der Browser-Anbieter kann man Web-Analyse mit Matomo und erst Recht die Ausführung von ThirdParty-Scripten voll vergessen, selbst wenn man die durch htaccess-Regeln ausdrücklich erlaubt.
Was mich dann aber wundert ist, wieso mit den genannten Sicherheits-Einstellungen dann überhaupt noch Websites funktionieren, wenn diese Scripte und Content über CDNs beziehen. Vielleicht gibt es intern im Browser definierte Regeln, die Datenaustausch mit bestimmten, häufig genutzten CDNs erlauben?
1.) Wenn im "Brave-Schutz" die maximale Schutzstufe = "aggressives Blockieren von Trackern und Anzeigen" aktiviert ist, werden Scripte nicht einmal dann ausgeführt, wenn sie von einer Subdomain stammen. In meinem Fall wird also auf "Domain-1" eine Analyse mit Matomo verhindert, wobei Matomo auf einer Subdomain von "Domain-1" läuft.
2.) Wenn im "Brave-Schutz" die mittlere Schutzstufe = "Tracker und Werbung blockieren" aktiviert ist, werden Scripte aus einer Subdomain ausgeführt. Scripte aus anderen Domains werden blockiert, auch wenn in den htaccess Regeln der beiden beteiligten Domains diese Scriptausführung erlaubt wird.
3.) Wenn der Brave-Schutz gegen Tracker und Werbung deaktiviert wird, können Scripte auch von "Third-Party" ausgeführt werden, sofern nicht AddOns im Browser diese blockieren wie z.B. uMatrix oder uBlockOrigin.
4.) Andere Browser und Browser für Android:
Aufgrund von Rückmeldungen von Websitebesuchern hat Safari standardmäßig einen Schutz aktiviert, der mindestens der Stufe 2 in der obigen Beschreibung entspricht. Gleiches gilt für die Standard-Einstellungen des Android-Browsers Vanadium, der beim googlefreien Android-OS "GrapheneOS" mit installiert wird.
Der Android-Brave-Browser reagiert schärfer, als im obigen Punkt 2 beschrieben und lässt auch in der mittleren Schutzstufe nicht zu, dass Scripte aus einer Subdomain im Content der Hauptdomain ausgeführt werden.
Schlussfolgerung:
Aufgrund der prinzipiell natürlich zu befürwortenden Schutzmaßnahmen der Browser-Anbieter kann man Web-Analyse mit Matomo und erst Recht die Ausführung von ThirdParty-Scripten voll vergessen, selbst wenn man die durch htaccess-Regeln ausdrücklich erlaubt.
Was mich dann aber wundert ist, wieso mit den genannten Sicherheits-Einstellungen dann überhaupt noch Websites funktionieren, wenn diese Scripte und Content über CDNs beziehen. Vielleicht gibt es intern im Browser definierte Regeln, die Datenaustausch mit bestimmten, häufig genutzten CDNs erlauben?
Ich fand inzwischen heraus, dass es eine MatomoTracker.php-Lösung gibt, eine PHP-API. Während ein ThirdParty-JS (auf dem Matomo-Server) von den meisten Browsern mit Sicherheitsfeatures geblockt wird (Ausführung des Codes über http GET) funktioniert die Matomo-PHP-Lösung mittels http POST. Und POST kann nicht sinnvoll vom Browser unterdrückt werden, weil dann z.B. auch ausgehende Links unterdrückt würden.
Leider habe ich keine Kenntnisse in PHP und sehe nicht, wie ich für meine Websites und Tracking-Wünsche eine passende MatomoTracking.php Datei zusammen setzen sollte und weiß auch nicht, wie ich die in mein Joomla-System integrieren muss, damit sie korrekt ausgeführt wird.
Wer mir dabei helfen möchte könnte mir ja eine PN senden....
Leider habe ich keine Kenntnisse in PHP und sehe nicht, wie ich für meine Websites und Tracking-Wünsche eine passende MatomoTracking.php Datei zusammen setzen sollte und weiß auch nicht, wie ich die in mein Joomla-System integrieren muss, damit sie korrekt ausgeführt wird.
Wer mir dabei helfen möchte könnte mir ja eine PN senden....
