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

  • Affected Version
    WoltLab Suite 5.4
    Affected App
    WoltLab Suite Core

    Dadurch, dass das Cookie XSRF-TOKEN nicht mit dem WSC-Cookie-Präfix versehen wird, ist es seit WoltLab Suite 5.4 unmöglich zwei Instanzen eines WSC auf derselben Domain/Subdomain zu betreiben.

    Damit ist es auch nicht möglich eine produktive Instanz unter www.example.com zu betreiben und eine interne Testumgebung unter www.example.com/intern/test/.


    Ich bitte darum diesen Missstand schnellstmöglich zu beheben; ich habe keinen Nerv für alle Test-Instanzen eigene Subdomains anlegen zu müssen. Wohlgemerkt für vielleicht 2 Tage Entwicklung nur um das alles dann wieder rückgängig machen zu müssen.

  • Ich sehe hier ein wenig das Problem, dass aktuell zwischenzeitlich / als Verzeichnis gesetzt wird, selbst wenn sich die Instanzen in Unterverzeichnissen befinden. Mein Stand ist eigentlich, dass das mit dem Token kein Problem ist, wenn sich die Instanzen in verschiedenen Verzeichnissen befinden. Dazu müsste aber für die Cookies auch stets der korrekte Pfad gesetzt werden.


    In meinem Test ist das WSC 5.4 ein Mal in wsc54 und ein Mal in wsc54-2 installiert. Rufe ich beide gleichzeitig auf, gibt es erst einmal keine Probleme. Nach dem Aktualisieren der Seite ist der Pfad plötzlich /, wo aber gar kein WSC installiert ist. Könnte mir vorstellen, dass das dein Problem ist.

    • Official Post

    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).

    • Official Post

    Hallo,

    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…ionHandler.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:

    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.

  • Das heißt die "Lösung" ist, dass ich für die Nutzer einen entsprechenden Hinweis einblenden muss, dass es ggf. zu Problemen kommen kann, weil der Fehler, der die Software teilweise unbenutzbar macht, nicht behoben wird und gleichzeitig rechne ich mehr Zeitaufwand für die Entwicklung in den Verkaufspreis?

    • Official Post

    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.

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

    Schlussendlich ist das Anlegen von Testinstanzen aber auch Zeit, die bezahlt sein will. Ohne Testinstanzen testet es sich nunmal schlecht. ;)


    Schlussendlich wird der Keks nur in diesem kleinen Teil überhaupt verwendet: https://github.com/WoltLab/WCF…ndler.class.php#L455-L503

    Welche Nachteile bestünden aktuell und für WSC 5.5 darin, dort den Präfix zu nutzen? Schlussendlich ist es ein stinknormaler Keks, der nur an einer Stelle im Core verarbeitet wird - die kommerziellen Apps habe ich mangels aktuellem Code nicht durchsucht.

    • Official Post

    Hallo,

    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.

    • Official Post

    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.

  • Kenne mich leider nicht so gut aus.


    Bei mir haben auch einige User das Problem mit dem XSRF Token. Bisher scheinbar nur wenn sie am Handy auf der Seite unterwegs sind.


    Das Forum ist bei mir auf der Domain forum.webseite.de . Ich weiss nun nicht womit sich dieser Token dann beißen könnte... Wie kann ich das rausfinden? Können das andere Subdomains sein die sich da gegenseitig behindern?

  • Nur sofern da auch eine Instanz läuft.

    Und die Cookie-Domain nicht restriktiv genug gesetzt wurde.

    In meinem Fall ist das Problem, dass in der Instanz .mysterycode.de genutzt wird, da sich die Instanz über mehrere Subdomains erstreckt. Nutzt man dann eine weitere Instanz ebenfalls auf einer Subdomain der gleichen Domain, bekommt man Probleme.

  • Hmm, verstehe ich das richtig, dass man mit 5.4 keine zwei Umgebung mehr in verschiedenen Verzeichnissen der gleichen Domain laufen lassen kann? Aber in einem Verzeichnis 5.3 und im anderen 5.4 würde noch gehen, ja? Ich nutze sowas eigentlich nur für das Upgrade selbst, nicht für eine Testumgebung. Wenn irgendwas schief läuft und ich zurück muss, dann steht die Umgebung eben schon fertig da. Wenns alles klappt, kommt sie danach weg.

    Liebe Grüße
    Susi

    • Official Post

    Hallo,

    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).

  • 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).

    Ja, das ist richtig und habe ich auch so. Danke!

    Liebe Grüße
    Susi

  • Habe nun alle anderen Dinge vom Server gelöscht und die User haben immer noch das Problem.


    Allerdings nur am Handy.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!