Zwei Instanzen auf einer Domain/Subdomain führen zu Session-Problemen

Hallo,

wie ich hier bereits erklärt habe, ist die Sonderbehandlung des XSRF-Token-Cookies kein Fehler: RE: Upgrade mehrere Instanzen im Multi-Domain-Setup

Die beschriebene Problematik tritt nur dann auf wenn in zwei Instanzen auf einer (Sub-)domain parallel gearbeitet wird und nach einem Wechsel der Instanz kein regulärer Seitenaufruf (der ein neues gültig signiertes Cookie setzt) erfolgt.

Von dem Betrieb mehrerer Instanzen auf einer Domain können wir auch ohne dieses Cookie grundsätzlich nur abraten, da Webbrowser viele neue Features mit der Same-Origin-Policy pro Domain scopen und auch andere Browserfunktionen zu Problemen führen können (z.B. ServiceWorker).

Hallo,

Quote from SoftCreatR

Darf ich einhaken und fragen, wo die oben beschriebene Problematik mit dem Cookie-Pfad herrührt?

das Cookie wird fest auf path=/ gesetzt: https://github.com/WoltLab/WCF/bl….class.php#L500

Auf Unterpfade gescopte Cookies verhalten sich ziemlich intransparent und kollidieren noch viel schlimmer: Wenn eine Instanz im root-Verzeichnis der Domain läuft und eine weitere in einem Unterordner, dann ist nicht definiert, welches der identisch benannten Cookies die Instanz im Unterordner gesendet bekommt.

Wenn man sich auch die (nicht mehr) neuen Features in Bezug auf Cookie-Sicherheit ansieht (beispielsweise das __Host--Präfix), dann sieht man recht deutlich, dass der Trend zu einer sauberen Trennung auf Basis von Domains geht:

Quote from Set-Cookie im MDN

In addition, cookies with the __Host- prefix must have a path of / (meaning any path at the host) and must not have a Domain attribute.

Hallo,

mir ist der Zusammenhang zwischen deinen Testinstanzen und deinen Kunden nicht ganz klar?

Ganz unabhängig davon arbeiten wir fortlaufend an der Verbesserung der Software, insbesondere um neue und zeitgemäße Sicherheitskonzepte umzusetzen. Ein durch diese Sicherheitskonzepte induzierter Änderungsbedarf für unübliche Anwendungsfälle ist daher leider nicht immer vermeidbar, um die Sicherheit der Software im Gesamten auf einem hohen Niveau zu halten.

Hallo,

Quote from MysteryCode

Die Testinstanzen dienen unter anderem dazu, dass der Kunde noch testen und "fühlen" kann, bevor er/sie/es es bei sich installiert.

Die Installation von mutually-untrusted Instanzen in Unterordnern auf der selben Domain ist in Bezug auf die Sicherheit generell bedenklich. Insbesondere dann, wenn die Domain zusätzlich für (vertrauliche) Kundendaten genutzt wird. Nicht ohne Grund liegen beispielsweise GitHub Pages auf github.io (inklusive Eintrag in der Public Suffix List), anderer UGC auf githubusercontent.com und unsere Demos auf woltlab-demo.com (auch mit PSL).

Ansonsten weiß ich natürlich sehr wohl an welcher Stelle das Cookie wie und auf welche Weise in unserem Code verarbeitet wird. Die Methode ist die einzige Stelle (ein direkter Zugriff auf das Cookie ist unzulässig und von keinerlei Kompatibilitätsgarantien gedeckt). Die Designentscheidungen sind in der Methode dokumentiert, in dem initial verlinkten Beitrag und in diesem Thema noch einmal erklärt.

Das Sitzungssystem ist einmal komplett modernisiert worden, entsprechend wurde bei der Entwicklung auch Wert darauf gelegt, dass es dem aktuellen Stand der Technik entspricht, nicht von Anfang an veraltet ist (auch in Hinblick auf die zu erwartenden zukünftigen Entwicklungen) und in jeder zukünftigen Version noch einmal mit etwaigen Inkompatibilitäten nachjustiert werden muss. Es wird an dem Cookie keine Änderung erfolgen.

Wir orientieren uns an Industrie-Standards im Hinblick auf die Sicherheit von Websites. Insbesondere die Browser-Hersteller haben in den letzten Jahren massiv Druck ausgeübt, um einheitliche Mindeststandards zu erreichen. Das jüngste Beispiel ist das geänderte Standardverhalten bei Cookies bzgl. dem SameSite-Attribut. Der hier von dir bemängelte Cookie verwendet einen Software-übergreifend einheitlichen Namen, ebenso sind Cookies auf Pfad-Ebene de facto soft-deprecated. Cookie-Präfixe wie z. B. __Host-, der abweichende Pfade vollständig verbietet, sind ein unübersehbarer Wink mit dem Zaunpfahl seitens der Browser-Hersteller…

Du hast bereits im Ausgangsbeitrag deutlich gemacht, dass für dich das eigentliche Problem darin liegt, dass du deine Architektur hinsichtlich der Test-Instanzen anpassen musst. Es ist auch durchaus nachvollziehbar, dass du nicht gerade Freudensprünge machst angesichts der vor dir liegenden Arbeit. Die Tendenz bei den Cookies hat sich schon seit langem abgezeichnet, weswegen wir bereits vor Jahren unsere Demos von Verzeichnissen auf Subdomains umgestellt haben.

Und ja, es ist vollkommen unstrittig, dass das auch einiges an Arbeit war, auf die wir gerne verzichtet hätten. Dennoch kann und darf das kein Argument sein, um das Sicherheitsniveau unserer Software abzusenken, nur um die unausweichliche Umstellung noch weiter hinauszuzögern.

Hallo,

Quote from Geronimo

Nur sofern da auch eine Instanz läuft.

nein. Andere Subdomain = andere Cookies.

Hallo,

Quote from Susi

Hmm, verstehe ich das richtig, dass man mit 5.4 keine zwei Umgebung mehr in verschiedenen Verzeichnissen der gleichen Domain laufen lassen kann?

Nein, das verstehst du falsch. Du wirst bei gleichzeitiger Verwendung von Instanzen mit einem unterschiedlichen Signierschlüssel aber möglicherweise Meldungen über ein ungültiges XSRF-Token sehen.

Wenn du die Instanzen nicht gleichzeitig verwendest, dann bemerkst du nichts. Wenn die Instanzen den gleichen Signierschlüssel haben (das ist bei Kopien der produktiven Instanz der Fall), dann bemerkst du nichts.

Nichtsdestotrotz empfehle ich die Verwendung unterschiedlicher Subdomains, nicht zuletzt, weil diese aus Sicherheitsgründen dann in einem komplett separaten vHost liegen können und, weil die Verzeichnisstruktur die gleiche bleiben kann (weil sich nur die Domain ändert).