Persistente Interaktionsanomalie zwischen Multi-Profil-Container-Instanzen, erweiterten Cookie-Isolationsregeln und seitenübergreifenden Autorisierungsabläufen – Bitte um Einschätzung der Ursache und möglicher Workarounds

Cola-Leid

Guten Tag zusammen,

ich hoffe, ich darf mich mit einer etwas umfangreicheren und möglicherweise ungewöhnlich vielschichtigen Fragestellung an Sie wenden. In den vergangenen Wochen beobachte ich in meinem produktiven Firefox-Setup ein Verhalten, das ich bislang weder reproduzierbar eingrenzen noch eindeutig bestimmten Komponenten zuordnen konnte – was mich mittlerweile an den Punkt bringt, an dem ich auf die Expertise dieses Forums angewiesen bin.

Kurz zum Hintergrund: Ich nutze Firefox (Stable, aktuellste Version) mit mehreren voneinander vollständig isolierten Profilen, die jeweils ausschließlich innerhalb bestimmter Multi-Account-Container betrieben werden. Zusätzlich ist bei mir die Funktion „Enhanced Tracking Protection – Strict“ aktiv, und in zwei der Profile läuft eine feinjustierte Policy für Cookie-Persistenz (Ablauf nach Sitzungsende), kombiniert mit einem externen Passwortmanager, der wiederum Autorisierungsabläufe über definierte Callback-URLs regelt.

Das eigentliche Problem stellt sich wie folgt dar:

Sobald ich mich in einem Container A auf einer Webanwendung X authentifiziere, beginnt Firefox – nicht sofort, aber meist nach ein bis drei Navigationen – bestimmte ressourcenübergreifende Anfragen (z. B. eingebettete Status-APIs oder redirect-basierte Prüfmechanismen) trotz korrekter Container-Zuweisung außerhalb des ursprünglich gewählten Containers zu initialisieren. Das führt dazu, dass Anmelde-Tokens, die laut Entwicklerdokumentation eindeutig domänen- und kontextgebunden sind, plötzlich als „invalid context“ zurückgewiesen werden.

Interessanterweise tritt dieses Verhalten ausschließlich dann auf, wenn:

1. Die Seite X über OAuth2 bzw. OpenID Connect Sign-Ins arbeitet,

2. der externe Passwortmanager über localhost-Callbacks eingebunden ist,

3. und parallel in einem weiteren Container B eine zweite Webanwendung Y eine Sitzung offen hält, die wiederum (laut Netzwerk-Logs) sporadisch Preflight-Checks an X stellt – obwohl sie keinerlei funktionalen Bezug dazu haben sollte.

Ich konnte inzwischen ausschließen, dass es sich um ein reines Cache- oder Cookie-Problem handelt; sämtliche lokalen Daten wurden mehrmals bereinigt, und das Verhalten tritt auch bei frischen Profilen auf, sobald die Container-Konfiguration ähnlich granular eingestellt ist wie in meinem Hauptprofil.

Daher meine Frage an die Runde:

Kann es sein, dass Firefox in bestimmten Konstellationen von Container-Isolationsregeln und externen Callback-Mechanismen intern eine Art „Kontext-Vermischung“ erzeugt, bei der mehrere parallele Autorisierungsflüsse sich gegenseitig beeinflussen, obwohl sie technisch sauber voneinander getrennt sein sollten? Oder ließe sich eher argumentieren, dass hier bereits ein subtiler Bug in der Art vorliegt, wie Firefox mit OAuth-Redirects verknüpfte Netzwerkrequests intern verwaltet?

Mir würde schon eine Richtung helfen:

Ist das ein bekanntes Phänomen, ein möglicher Edge-Case, ein Konfigurationsfehler meinerseits – oder etwas, das ich als Bug reporten sollte?

Vielen Dank im Voraus für jede Einschätzung und für Ihre Geduld beim Lesen dieser doch recht langen Darstellung.

Mit freundlichen Grüßen

StandingBill

Hallo und Willkommen im Firefox-Forum

Vorweg der Hinweis, dass ich mit dem geschilderten komplexen Szenario überfordert bin. Weil bisher kein anderer auf dein Anliegen reagiert hat, habe ich das Problem in etwas verständlicherer Form ChatGPT geschildert. Folgende Antwort hat die KI gegeben:

Das von dir beschriebene Problem klingt nach einer sehr komplexen Konfiguration, bei der mehrere Isolationsebenen und externe Mechanismen zusammentreffen. In der Theorie sollte Firefox mit Multi-Account-Containern (MAC) eine hohe Isolation zwischen verschiedenen Sitzungen ermöglichen, sodass Cookies, Web-Speicher und andere Session-Daten innerhalb eines Containers bleiben und nicht zwischen Containern geteilt werden. Doch es gibt mehrere mögliche Ursachen, warum dieses Verhalten dennoch auftreten könnte, insbesondere in Verbindung mit der von dir verwendeten Konfiguration:

Mögliche Ursachen und Erklärungen

Preflight-Requests und CORS-Problematik:
- Da du Preflight-Checks und ressourcenübergreifende Anfragen erwähnst, könnte es sein, dass die Cross-Origin-Resource-Sharing (CORS)-Politik nicht korrekt durchgesetzt wird. Wenn Webanwendung Y (im Container B) über Preflight-Requests mit Webanwendung X (im Container A) kommuniziert, könnte Firefox in bestimmten Fällen "vermissverstehen", dass es sich um eine autorisierte Anfrage handelt. Dies könnte zu einer Kollision bei der Verarbeitung von Tokens führen, wenn beispielsweise ein Authentifizierungs-Token oder Cookie, das für Container A bestimmt ist, im Zusammenhang mit Container B verwendet wird.
Callback-URLs und Localhost-Isolation:
- Die Verwendung von Callback-URLs über localhost kann zu einer Art „Schwäche“ bei der Container-Isolation führen. In den Multi-Account-Containern werden bestimmte URLs oder IP-Adressen wie localhost manchmal nicht als vollständig isolierte Entitäten betrachtet, da sie als interne Kommunikation betrachtet werden könnten. Wenn du in einem Container (A) ein OAuth2- oder OpenID Connect-Login über einen externen Passwortmanager mit einem Callback an localhost durchführst, könnte es sein, dass Firefox die Anfragen im Kontext des gesamten Browsers interpretiert und somit die Trennung zwischen den Containern beeinträchtigt wird.
Verhalten von Drittanbieter-Cookies und Cookie-Persistenz:
- Da du die Cookie-Persistenz nach Sitzungsende und „Strict Tracking Protection“ aktiviert hast, ist es möglich, dass Firefox in bestimmten Fällen eine „aufgehobene Isolation“ zwischen den Containern anzeigt. Dies kann passieren, wenn Cookies oder Sitzungseinträge auf eine Art und Weise behandelt werden, die die Container-Isolation überschreibt. Insbesondere die Strict Tracking Protection könnte dazu führen, dass Drittanbieter-Cookies nicht korrekt blockiert werden, wenn sie durch eine parallele Sitzung (z.B. Container B) verwaltet werden, was zu einer unabsichtlichen „Vermischung“ von Sitzungsdaten führen könnte.
Interne Firefox-Handling-Fehler bei OAuth2 / OpenID Connect:
- Firefox könnte in bestimmten Fällen auch durch einen internen Fehler oder eine unvollständige Implementierung bei der Trennung von Sitzungsdaten zwischen OAuth2 und OpenID Connect-Mechanismen versagen. Gerade bei komplexen Anmeldeprozessen, die mit verschiedenen Containern und externen Mechanismen kombiniert werden, könnten noch nicht perfekt dokumentierte Szenarien auftreten, bei denen Firefox Sitzungsinformationen falsch zuordnet.
„Context-Vermischung“ durch JavaScript- oder Webstorage-Schnittstellen:
- Eine weitere Möglichkeit könnte sein, dass Webanwendungen (wie X oder Y) auf JavaScript- oder Webstorage-APIs zugreifen, die Informationen über mehrere Fenster oder Tabs hinweg teilen. Auch wenn die Container-Isolation Cookies und HTTP-Daten trennt, könnte es in seltenen Fällen zu einer Überschneidung bei der Nutzung von Web Storage oder anderen Persistenztechniken kommen. Insbesondere durch die Nutzung von Local Storage oder IndexedDB kann es zu einer unbeabsichtigten Datenweitergabe zwischen den Containern kommen, auch wenn der Zugriff auf Cookies korrekt isoliert bleibt.

Mögliche Lösungsansätze

Überprüfung und Anpassung der CORS- und Preflight-Policy:
- Stelle sicher, dass die CORS-Policy und die Preflight-Requests korrekt eingerichtet sind, insbesondere für die betreffenden Webanwendungen. Es könnte hilfreich sein, die CORS-Header und den Umgang mit Cross-Origin-Anfragen in den Entwicklertools zu überwachen und gegebenenfalls anzupassen.
Änderung der Callback-URL:
- Wenn möglich, versuche, die Callback-URL von localhost auf eine andere, eindeutig isolierte URL (z.B. eine Subdomain oder eine andere IP-Adresse) umzuleiten, die in einem eigenen Container läuft. Dies könnte helfen, die Kontexte besser zu trennen.
Prüfung und Debugging von Cookies und Local Storage:
- Überprüfe, ob in einem Container gespeicherte Session- oder Authentifizierungsdaten in einen anderen Container weitergegeben werden. Verwende die Entwicklertools von Firefox, um alle Cookies und Web-Speicher-Informationen zu überwachen, die zwischen den Containern geteilt werden könnten. Es könnte sich herausstellen, dass eine Webanwendung im Container B auf Cookies zugreift, die für Container A gedacht sind.
Deaktivierung von „Strict Tracking Protection“ für den Test:
- Teste, ob das Problem auch auftritt, wenn du die „Strict Tracking Protection“ vorübergehend deaktivierst. Dies könnte helfen, zu prüfen, ob die Schutzmaßnahmen beim Blockieren von Drittanbieter-Cookies oder Ressourcen zu einem unvorhergesehenen Verhalten führen.

Fazit

Ja, es könnte durchaus sein, dass Firefox in bestimmten Szenarien, insbesondere bei der Kombination aus Multi-Account-Containern, externen Passwortmanagern, OAuth2 und OpenID Connect-Mechanismen, eine Art „Kontext-Vermischung“ erzeugt, die zu den beschriebenen Problemen führt. Dies passiert vermutlich durch eine Kombination von fehlender vollständiger Trennung bei der Nutzung von localhost-Callbacks, CORS-bezogenen Anfragen und Cookie- oder Session-Handling. Eine genauere Untersuchung und Anpassung der oben genannten Faktoren könnte helfen, das Problem zu isolieren und zu beheben.