Versuch eines Sammelthreads zu X-CSRF-Token / Validierungsproblem

Hallo,

ich hatte ja bereits hier geschrieben, dass wir uns das Thema nochmal für das nächste Release ansehen: https://forum.shopware.com/discussion/comment/189280/#Comment_189280

Deine Anmerkungen geb eich da gerne mit in das Ticket, dann können wir dies auch zusätzlich prüfen.

Vielen Dank
Moritz

@NextMike schrieb:

Inwieweit für das zu der “gefürchteten” Fehlermeldung?

Anmelde-Seite aufgerufen -> kein gültiges Token erhalten -> noch vorhandenes, aber mittlerweile ungültiges Token wird in Formular eingefügt und mit POST-Daten zurück an den Shop übermittelt -> CSRF-Validierung scheitert -> “gefürchtete” CSRF-Fehlermeldung wird ausgegeben

Die CSRF-Validierung funktioniert nunmal so, dass dem User beim Aufruf einer Seite mit POST-Formular (wie z.B. der Anmelde-Seite) ein gültiges Token-Cookie übergeben wird (bzw. ein bereits vorhandenes auf Gültigkeit überprüft und ggf. erneuert wird). Dessen Wert wird dann mit den POST-Daten des Formulars zusammen zurück an den Shop gesendet. So kann anhand des Tokens überprüft werden, dass die POST-Daten tatsächlich von dem Shop-eigenen POST-Formular stammen, und nicht etwa von einem Bot oder Script übermittelt wurden.

Seit Shopware 5.2.17 ist nun beim Aufrufen der Anmelde-Seite ein gültiges Token nicht mehr gewährleistet. Und ohne gültiges Token keine erfolgreiche Validierung, sprich die von Dir “gefürchtete” Fehlermeldung erscheint… zum Schrecken aller… IMMER WIEDER UND WIEDER!!!1!!

:wink:

 

installier ist Version 5.2.20,

kaum ein Kunde kann sich noch anmelden!

Am Speicher oder an der Performance kann es nicht liegen.

Ich hoffe da wird bald an einem Bugfix gearbeitet?

Shopware\Components\CSRFTokenValidationException: The provided X-CSRF-Token for path “/de/newsletter” is invalid. Please go back, reload the page and try again. in /engine/Shopware/Components/CSRFTokenValidator.php:158 Stack trace:
#0 /engine/Library/Enlight/Event/Handler/Default.php(91): Shopware\Components\CSRFTokenValidator->checkFrontendTokenValidation(Object(Enlight_Controller_ActionEventArgs))
#1 /engine/Library/Enlight/Event/EventManager.php(214): Enlight_Event_Handler_Default->execute(Object(Enlight_Controller_ActionEventArgs))
#2 /engine/Library/Enlight/Controller/Action.php(141): Enlight_Event_EventManager->notify(‘Enlight_Control…’, Object(Enlight_Controller_ActionEventArgs))
#3 /engine/Library/Enlight/Controller/Dispatcher/Default.php(523): Enlight_Controller_Action->dispatch(‘indexAction’)
#4 /engine/Library/Enlight/Controller/Front.php(223): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
#5 /engine/Shopware/Kernel.php(180): Enlight_Controller_Front->dispatch()
#6 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(487): Shopware\Kernel->handle(Object(Enlight_Controller_Request_RequestHttp), 1, true)
#7 /engine/Shopware/Components/HttpCache/AppCache.php(255): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
#8 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(258): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
#9 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(275): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true)
#10 /engine/Shopware/Components/HttpCache/AppCache.php(133): Symfony\Component\HttpKernel\HttpCache\HttpCache->invalidate(Object(Symfony\Component\HttpFoundation\Request), true)
#11 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(206): Shopware\Components\HttpCache\AppCache->invalidate(Object(Symfony\Component\HttpFoundation\Request), true)
#12 /engine/Shopware/Components/HttpCache/AppCache.php(114): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/vhosts/xxxxxxxxx.xxx/httpdocs/xxxxxx/shopware.php(117): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
#14 {main}

Merkwürdig finde ich, dass bei Schritt 6 der ursprüngliche, nicht mehr vorhandene Token in den Code reinkommt: der Cookie ist weg und bei Hrefs wird er auch nicht übertragen, oder?

Meines Empfindens nach liegt es doch an Shopware, oder liege ich da falsch ?!

Es kann doch nicht sein das fast jeder nach den letzten Up-Dates Probleme hat und nichts geschieht.

Ich denke SW sollte sich mal um eine Lösung bemühen.

@VELNCS‍ Hat Moritz ja doch auch oben geschrieben? Verstehe deine Antwort bzw. die Wiederholung jetzt nicht ganz. https://forum.shopware.com/discussion/comment/189416/#Comment_189416

Da kommen alle Tickets nochmal auf den Prüfstand z.B. auch Shopware Issuetracker

… nun die Probleme häufen sich doch massiv, ist ja nicht zu überlesen hier. Es sind nicht einzelne betroffen, und es ist nach den Up-Dates aufgetreten ohne veränderungen am Shop, jedenfals bei mir.

Die Shops werden doch nicht zum Hobby genutzt. Mir erscheint es so, als ob man das Problem erst mal vor sich hin dümpeln lässt.

Wenn ein Haus brennt, wartet man doch auch nicht eine halbe Ewigkeit und hört mal was so geredet wird umt dann festzustellen - wir können ja demnächst mal nachsehen.

Ich bitte darum dies nicht persönlich zu nehmen, es ist lediglich mein Eindruck

Naja, den Brand kannst du ja selbst löschen, indem du die Token-Validierung erstmal kurzfristig ausschaltest.
Das ist ja ohnehin die normale Vorgehensweise - wenn ich Probleme mit einer Funktion habe, schalte ich sie ab und schau dann nach warum sie Probleme macht. Klar ist das ein Sicherheitsfeature, hat aber auch in der kompletten 4er und 5er Linie ohne Funktioniert, sodass du dir ohne die Validierung für einige Tage sicherlich kein Bein brechen wirst.

ok

wenn ich es richtig verstanden hab, so liegt es am Google Services Plugin ?  bei mir ist und war dies noch nie aktiviert.

Hallo [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍

Den Brand kann er zwar selber löschen, das stimmt natürlich, ihr habt es allerding auch ganz schön schleifen lassen. 

Es gibt einige Threads bei denen man den Eindruck bekommen kann, wer die CSRF-Token Validierung abschalte, öffne quasi ein Scheunentor in seinem Shop. Dem ist ja nun nicht so. Die ab und an hier im Forum verlinkten Webseite tragen für den landläufigen Shopbetreiber auch nicht zur Beruhigung bei. 

Vielleicht sucht ihr die Threads zusammen und macht dort eine klärende offizielle Aussage am Ende, dann muss sich nicht jeder neu aufregen.

@VELNCS schrieb:

ok

wenn ich es richtig verstanden hab, so liegt es am Google Services Plugin ?  bei mir ist und war dies noch nie aktiviert.

Das hast Du nicht richtig verstanden. Der Grund ist eigentlich unklar, es kann aber ein Plugin sein. Das Google Service Plugin würde ich ausschließen. Deaktiviere den CSRF-Schutz in der config.php, wenn Du sicher bist, dass es kein Bot gewesen ist, der den Fehler ausgelöst hat. 

Warum kommuniziert Shopware nicht einfach mal offen, dass zur Zeit eine fehlerhafte Version ausgeliefert wird?

Kann doch wohl nicht wahr sein, dass man nach einer Erstinstallation zunächst einmal die config.php anpassen muss, damit der Shop auch fehlerfrei läuft.

Und wenn der User dann hier nachfragt, wird er auch noch im Unklaren darüber belassen?

Sorry, nichts Persönliches, aber das ist schlechtes Management.

… dachte schon ich bin der einzige der es so wahrnimmt

Wer einen Zweifel daran hat, dass der Bug seit 5.2.17 im Core enthalten ist, kann das anhand dieses Tests verifizieren: https://forum.shopware.com/discussion/comment/189384/#Comment_189384

@kkr8 schrieb:

Wer einen Zweifel daran hat, dass der Bug seit 5.2.17 im Core enthalten ist, kann das anhand dieses Tests verifizieren: https://forum.shopware.com/discussion/comment/189384/#Comment_189384

 

Das wird doch auch offen von uns kommuniziert, siehe: https://forum.shopware.com/discussion/comment/189624/#Comment_189624 Das Ticket im Issuetracker ist ja bereits für eine Version/Überprüfung eingeplant. Sehe jetzt das Problem nicht. Fakt ist nur, dass bei weitem nicht jede Meldung hier im Forum ein Fehler im Core ist. Ein Teil davon sicherlich. Schaut man sich aber die POST-Requests an die hier so genannt werden, sind da auch viele Bots dabei und da ist die Meldung ja korrekt. Das kann man eben nicht einfach über einen Kamm scheren. Die Probleme die du dort beschrieben hast, schauen wir uns ja auch an im Rahmen des von Sebastian genannten Tickets. Das wird aber definitiv nicht jeden Thread hier erledigen. Um eine individuelle Prüfung des Fehlers wird kein Shopbetreiber drum rum kommen.

Und um das nun mal abzukürzen: Ja wir schauen uns Probleme im Core dazu an, solange kann man den Token-Schutz deaktivieren, wenn man in seinem Shop Probleme damit hat. Generell wird dies aber nicht jede Meldung im Log tilgen, denn es gibt auch berechtige Situationen wo ein solcher Logeintrag/Mail erzeugt wird.

Sorry, aber offene Kommunikation sieht für mich anders aus. Z.B. eine Aktion wie ein fester Eintrag/Stellungnahme von Shopware bei den Hot-Topics oder eine Mitteilung wenn man sich in sein Shopware-Account einloggt. Stattdessen nun nach langer Zeit eine Reaktion in einem Forumsbeitrag.

Ich habe mir wochenlang mühsam die Informationen selber zusammen suchen müssen, inkl. gefährlichem Halbwissen/Tips anderer z.B. das es brandgefährlich sei CSRF-zu deaktivieren etc.pp. da seitens Shopware keine Info vorlag, bzw. erst seit ein paar Tagen “zugegeben” wird das augenscheinlich auch Fehler im Core vorliegen. Vorher lag es nach Info Dritter immer angeblich an irgendwelchen Plugins oder individuellen Änderungen durch den Shopinhaber. Man hätte sich viel Ärger, x-Einträge wg. CSRF-Problemen im Forum dadurch sparen können.

Seitdem ich CSRF deaktiviert habe, kommen wieder Bestellungem in gewohnter Umsatzhöhe rein…wochenlang hatte ich aufgrund des Fehler etliche Bestellabbrüche…ärgert mich  immer noch.

Gruß, Bernd

Wir können natürlich jetzt über das “hätte, würde, könnte” diskutieren oder einfach konstruktiv zusammen an einer Lösung arbeiten. Meine Kollegen schauen sich die Probleme, die uns über den Issuetracker gemeldet werden an. Wenn es dort Probleme gibt, werden diese mit dem nächsten Update behoben. Wenn ihr einen Fehler habt, ist die Reproduzierbarkeit das wichtigste, das könnt ihr auch gerne in diesem Tickets ergänzen.

@myartstore schrieb:

Vorher lag es nach Info Dritter immer angeblich an irgendwelchen Plugins oder individuellen Änderungen durch den Shopinhaber. 

bis zur Version 5.2.17 war es auch so. 

Das mit dem Umsatz ist blöd, aber die Updategeilheit vieler verstehe ich auch nicht. Ich würde niemals produktiv die neuesten Versionen fahren.

3 Likes

Nun, als Shopbetreiber ist der „Update-Button“ aber auch echt verführerisch. Und man kann ja nur die aktuellste Version updaten. Problem ist ja nur, das seitens Shopware hier ich muß es so sagen: NICHTS PASSIERT IST und selbst Supporttickets waren nur Arbeit für mich und keine Lösung.

Updategeil wären wir nicht, wenn man im Backend eine Auswahl hätte welche Version man den updaten möchte!

1 Like

@dakl schrieb:

Nun, als Shopbetreiber ist der “Update-Button” aber auch echt verführerisch. Und man kann ja nur die aktuellste Version updaten. Problem ist ja nur, das seitens Shopware hier ich muß es so sagen: NICHTS PASSIERT IST und selbst Supporttickets waren nur Arbeit für mich und keine Lösung.

Updategeil wären wir nicht, wenn man im Backend eine Auswahl hätte welche Version man den updaten möchte!

Hallo,

naja du kannst ja jederzeit das Update auf deine gewünschte Shopware Version ja auch manuell einspielen - siehe: http://community.shopware.com/Downloads_cat_448.html . Somit hast du ja jederzeit die Auswahl, welche Shopware Version du einspielen möchtest. Nur automatisch wird dir eben auch nur die aktuellste Shopware Version angeboten, was auch nachvollziehbar ist.

Und so und so sollte man vor jedem Update im Livesystem das Update erst einmal vorab in einer Testumgebung durchführen.

Beste Grüße

Sebastian