Wie lange ist denn das Cookie gültig?
Frage hat sich erledigt, Sitzungsende. Das würde hier nun zumindest für einige Fälle eine Erklärung liefern, wenn man einfach den Tab zu lange offen hat und dann erst den Beitrag oder die PN absenden.
Fehlermeldung fehlerhaften XSRF-Tokens
-
- Not a bug
-
Mohikaner -
January 4, 2023 at 6:10 PM
-
-
Frage hat sich erledigt, Sitzungsende. Das würde hier nun zumindest für einige Fälle eine Erklärung liefern, wenn man einfach den Tab zu lange offen hat und dann erst den Beitrag oder die PN absenden.
nein das XSRF hat kein Sitzungsende und auch kein Ablaufdatum. Bei dir wird der Browser das entschieden haben. Zu 80% ist es der Chrome und FF.
Dies passiert auch in unserem Forum. Abhilfe gibt es nur über F12 und Webspace sowie alle Sitzungen löschen auf deiner https-Seite, damit wird wieder ein vernünftiger XSRF gesetzt. Bei manchen Nutzern standen sogar mehr als die üblichen 2. Ich habe im Forum eine Anleitung gesetzt, da bei uns auch viele das Problem haben. Irgendetwas stimmt mit dem Java nicht, oder was auch immer.
Grüße
-
Bei dir wird der Browser das entschieden haben. Zu 80% ist es der Chrome und FF.
Ich kann nur sagen was ich lese, und da steht Sitzungsende. Offenbar funktioniert das auch unter Safari genauso. Ich habe immer noch einen Adblocker im Visier, der js blockt oder beeinflusst.
-
Ich kann nur sagen was ich lese, und da steht Sitzungsende.
Das steht immer, aber es hat kein Ablaufdatum, wie die anderen Cookies.
Das Problem gibt es ab der 5.4 und wurde ab der 5.5 schon öfters hier gemeldet.
Siehe auch in den Neuerungen.
Neuerungen in WoltLab Suite 5.5: Weitere Verbesserungen - WoltLab®WoltLab Suite 5.5 enthält wieder zahlreiche kleinere Verbesserungen aus dem Bereich „Quality of Life“, die wir in diesem Artikel näher vorstellen möchten.www.woltlab.com -
Das steht immer, aber es hat kein Ablaufdatum, wie die anderen Cookies.
Wenn es der Browser tatsächlich so interpretiert, ist das Label hier falsch.
-
nein das XSRF hat kein Sitzungsende und auch kein Ablaufdatum. Bei dir wird der Browser das entschieden haben. Zu 80% ist es der Chrome und FF.
Wenn die Session ausläuft, ist auch der XSRF Token ungültig.
Irgendetwas stimmt mit dem Java nicht, oder was auch immer.
Wäre mir neu das hier Java zum Einsatz kommt.
Ich habe immer noch einen Adblocker im Visier, der js blockt oder beeinflusst.
Ich denke eher, Tab ewig offen, dann was schreiben wollen nach x Stunden, und dann kommt natürlich der Fehler.
-
Hmmm - also versuchte der Google Bot mit ewig offenem Tab hier im Forum etwas zu schreiben?
Na zum Glück hat er das nicht geschafft
Ich vermute nach wie vor, dass das Problem etwas tiefer liegt und nicht dauerhaft mit Browser/ Clienteinstellungen gelöst werden kann..
lg matss
-
Wenn die Session ausläuft, ist auch der XSRF Token ungültig.
Nein bleibt weiterhin bestehen siehe F12 bei Sitzungsende und beim Login ebenso.
Wäre mir neu das hier Java zum Einsatz kommt.
Das ist schon seit der 5.4
Dieses Cookie ist seit den neuen Sessions in 5.4 dafür ausgelegt, dass es durch JavaScript lesbar ist und ab WoltLab Suite 5.5 lesen wir es auch tatsächlich via JavaScript, um BREACH-Angriffe zu verhindern.
Und ich rede jetzt nicht von verschiedenen Instanzen, auch bei einer kommt dieser Fehler.
Und wenn ich das hier sehe, häuft es sich sogar.
Grüße
-
Das ist schon seit der 5.4
Mit Sicherheit nicht. Du verwechselst Java mit JavaScript, was trotz des ähnlichen Namens etwas völlig anderes ist.
-
Nichts anderes habe geschrieben
Nur das es ab der 5.4 zum Einsatz kommt 🤷🏻♂️ ok das Script fehlt hinten, aber ich bin davon ausgegangen, dass es auch so verstanden wurde wie man ja sieht. Außerdem war es auch so verlinkt gewesen 
Trotzdem löst es das Problem nicht.Grüße
-
Das Problem bestand definitiv schon unter 5.4 bei uns. Jetzt unter 5.5 immer noch.
-
- Official Post
Hallo,
Wie lange ist denn das Cookie gültig?
Das Cookie ist ein sogenanntes non-persistent Cookie ohne explizites Ablaufdatum nach RFC 6265, umgangssprachlich „Sitzungscookie“. Sitzung bezieht sich hierbei aber auf die Browsersitzung und nicht die Sitzung am Server. In anderen Worten: Der Webbrowser entscheidet, was als Sitzungsende verstanden wird.
Im Google Chrome endet die Sitzung AFAIK beim Schließen des Webbrowsers. Im Firefox hängt es nach meinem Kenntnisstand davon ab, ob die Sitzung beim Neustart des Webbrowsers fortgesetzt werden soll („Ob die Tabs wiederhergestellt werden sollen“). Wenn dies der Fall ist, dann endet die logische Browsersitzung im Firefox nie.
Das würde hier nun zumindest für einige Fälle eine Erklärung liefern, wenn man einfach den Tab zu lange offen hat und dann erst den Beitrag oder die PN absenden.
Nein. Zum Einen „siehe oben“ für Definition von Sitzung, zum anderen enden auch die Serversitzungen seit WoltLab Suite 5.4 erst 60 Tage nach der letzten Aktivität. Die älteste Sitzung auf WoltLab.com feiert im Mai ihren zweiten Geburtstag.
Wenn die Session ausläuft, ist auch der XSRF Token ungültig.
Das ist, wie ich schon am Montag erklärt habe, falsch:
Ich denke eher, Tab ewig offen, dann was schreiben wollen nach x Stunden, und dann kommt natürlich der Fehler.
Auch das ist falsch, siehe oben.
Und ich rede jetzt nicht von verschiedenen Instanzen, auch bei einer kommt dieser Fehler.
Das Problem in deinem Forum ist vermutlich, dass es sowohl über unverschlüsseltes HTTP als auch HTTPS erreichbar ist, nicht auf die verschlüsselte Version umleitet und auch keine HSTS-Header sendet. Beim Wechsel von HTTPS auf HTTP (etwa durch einen unsicheren Link) wird das HTTPS-Cookie aufgrund des secure-Flags nicht mitgesendet und dadurch durch ein neues ersetzt.
Ich vermute nach wie vor, dass das Problem etwas tiefer liegt und nicht dauerhaft mit Browser/ Clienteinstellungen gelöst werden kann..
Dazu habe ich unsere Zugriffsprotokolle geprüft. Alle diese Google-Fehler sind dadurch begründet, dass der Googlebot bei der entsprechenden Anfrage überhaupt kein Cookie mitgesendet hat. Es ist denkbar, dass der Googlebot zum Test des Verhaltens der Webseite in einigen Fällen einen Webbrowser simuliert, der keine Cookies sendet. In diesem Fall ist die Bemängelung eines fehlerhaften XSRF-Tokens das gewünschte Verhalten.
Konkret stammt die Fehlermeldung aus der impliziten Anfrage nach neuen Beiträgen, wenn man an das Ende der Seite scrollt. Dort werden Serverfehler aktuell nicht ignoriert, das werden wir aber voraussichtlich ändern, weil die Anfrage keine durch den Nutzer explizit ausgelöste Anfrage ist.
Das Problem gibt es ab der 5.4 und wurde ab der 5.5 schon öfters hier gemeldet.
Die Fehlermeldung in diesem Wortlaut gibt es erst seit WoltLab Suite 5.4, in früheren Versionen war das die „Ihre Sitzung ist abgelaufen, bitte laden Sie die Seite neu“-Fehlermeldung. Wir haben die Formulierung aus zwei Gründen bewusst angepasst (https://github.com/WoltLab/WCF/issues/4501):
- Der Schutz vor XSRF-Angriffen ist technisch jetzt von der Sitzung entkoppelt, sodass die Meldung technisch nicht zutreffend war.
- Die neue Formulierung ist bewusst „googlebar“ formuliert, um die Meldung eindeutig identifizierbar zu machen.
-
Das Problem in deinem Forum ist vermutlich, dass es sowohl über unverschlüsseltes HTTP als auch HTTPS erreichbar ist, nicht auf die verschlüsselte Version umleitet und auch keine HSTS-Header sendet. Beim Wechsel von HTTPS auf HTTP (etwa durch einen unsicheren Link) wird das HTTPS-Cookie
aufgrund des secure-Flags nicht mitgesendet und dadurch durch ein neues ersetzt.
Genau das ist wohl eingetreten, danke für den Hinweis. Da ich das Forum erst seit kurzem betreue, habe ich gleich mal nachgeschaut. Und ja, dass http ist dort noch beim Webhoster geführt, obwohl alles auf https umgestellt ist, besteht trotzdem die möglichkeit das Forum über http zu erreichen.
Eine Möglichkeit wäre über eine .htaccess Datei mit:
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
das Problem zu lösen?
Grüße
-
- Official Post
Hallo,
das Problem zu lösen?
ich bin mit der Konfiguration eines Apache-Webservers nicht im Detail vertraut, die Regel sieht aber zumindest nicht falsch aus. Musst du am besten einfach mal ausprobieren. Zusätzlich könnte noch ein Strict-Transport-Security („HSTS“)-Header gesetzt werden.
-
Musst du am besten einfach mal ausprobieren. Zusätzlich könnte noch ein Strict-Transport-Security („HSTS“)-Header gesetzt werden.
Sooo, habe es zuerst im Testboard umgesetzt, und dort ging es einwandfrei. Jetzt im Live Forum die .htaccess eingetragen, und alles super.
Gefühlt geht alles schneller, da wohl keine "http" Seiten mehr gesucht werden. Bis jetzt auch kein XSRF Fehler.
Ich habe auch deinen Rat befolgt, und den HST Header mit eingetragen.
Der Eintrag sieht so aus:
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
Header set Strict-Transport-Security "max-age=31536000"
Vielen Dank für den Tip, bin gespannt, ob noch mal der XSRF auffällig wird.
Grüße
-
Ich habe auch deinen Rat befolgt, und den HST Header mit eingetragen.
Kurze Info noch, vergiss bei dem HSTS Header nicht, das du dann für die angegebene Zeit stets ein gültiges Zertifikat aufweisen musst.
-
Ja das wird automatisch jedes Jahr verlängert eigentlich. Trotzdem Danke für die Info.
Grüße
-
- Official Post
Hallo,
Kurze Info noch, vergiss bei dem HSTS Header nicht, das du dann für die angegebene Zeit stets ein gültiges Zertifikat aufweisen musst.
in der Praxis ist der HSTS-Header wohl auch das geringste Problem, da du Seiten mit persönlichen Information faktisch nur über TLS betreiben darfst.
-
Hallo,
in der Praxis ist der HSTS-Header wohl auch das geringste Problem, da du Seiten mit persönlichen Information faktisch nur über TLS betreiben darfst.
War auch mehr als Hinweis gedacht, leider schon erlebt das man es vergisst.
Ich war selbst Mal davon betroffen.... Weil ACME das Zertifikat nicht verlängern konnte.
-
Bei uns war der Auslöser für die Fehlermeldung des fehlerhaften XSRF-Tokens ein Codeschnipsel:
Code<meta http-equiv="Content-Security-Policy" content="script-src 'self'">Nach dem dieser Code entfernt wurde, kam auch die Fehlermeldung nicht mehr.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!