2
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/contentid/668598
Ausgedruckt am: 05.10.2024 um 22:10 Uhr
2 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?
