Versuch eines Sammelthreads zu X-CSRF-Token / Validierungsproblem

Thema: Versuch die vielfach geführte X-CSRF-Token Diskussion zu bündeln

These: Es handelt sich um ein strukturelles Problem im Core und nicht ein individuelles Plugin oder Server Problem
 

Leider ist festzustellen, dass zumindest die Shopwaremoderatoren für dieses Forum darauf beharren, dass es sich immer um ein individuelles und nicht ein strukturelles Problem mit der Tokenvalidierung handelt. Von mir aus können wir ab jetzt über ein individuelles Massenproblem reden

In diesem Zusammenhang ist zu erwähnen, dass schon mehrere User darauf hingewiesen haben, dass der Fehler auch im Shopware-Demoshop reproduzierbar war. Das ist aber nicht verlässlich nachbaubar, aber ich habe es im Zusammenhang mit der Anmeldung auch schon im Demoshop (keine Plugins, Standardtheme) geschafft den Fehler zu reproduzieren. Es liegt nun nahe - und da bin ich nicht alleine - dass man sehr wohl vermuten darf, dass da etwas auf Corebasis nicht sauber läuft und deswegen dieser Fehler in verschiedenen Konstellationen immer wieder auftritt und das eben nicht vereinzelt.

Zugeben muss man auch, dass dieses wahrscheinlich eine Heidenarbeit ist zu analysieren und zu beseitigen. Die von den Modeartoren angeführten Möglichkeiten sind auch soweit nicht falsch. Das ist wirklich sehr komplex. Zu befürchten ist, dass es dafür keine Ressourcen bei Shopware gibt, da wahrscheinlich der größte Teil der Entwickler abgestellt ist bis zum nächsten Community-Day das neue B2B-Wunder zu bauen (oder was da auch kommen mag).

Fakt für uns ist aber auch, dass wir bis vor zwei Wochen einen sauber laufenden Shop unter 5.1 hatten. Mit 5.2.18 war es dann vorbei. Und die Forenbeiträge zu dieser Problematik gibt es seit Erscheinen der 5.2. . Änderungen bei uns zur Vorversion u.a. PHP7, aktuelles Appache. Ansonsten keine neuen Plugins (sogar deutlich weniger).

Um es dann auch wieder zu sagen, wir halten grundsätzlich Shopware für eine der besten Shoplösungen auf dem Markt. Allerdings ist spätestens seit 5.2 zu befürchten, dass es gerade Tendenzen gibt sich zu sehr auf Marketing und BWL-Geschwurbel auszurichten und auf der anderen Seite Einsparungen im Bereich Qualitätsmanagement macht. Die Updateorgien der letzten Monate sprechen für sich.

Inwieweit man hier als Community mal einlenken kann ist schwierig. Denn die Diskussion ist komplett zerfleddert. Ich bleibe bei der Vermutung, dass es ein strukturelles, im Core begründetes Validierungsproblem gibt. Die Massen von Tickets werden zu recht gemacht, aber damit bleibt es tatsächlich individualisiert.

Ein Ansatz war den kompletten Shop (alle Seiten) auf SSL umzustellen. Wir haben tatsächlich den Eindruck, dass dieses Linderung bringt aber nicht die Problemlösung ist. Vermuten lässt sich aber z.B. an diesem Punkt, dass es Probleme bei der Übergabe von unverschlüsselten Seiten auf verschlüsselte gibt. Aber das ist nur einer von sehr vielen Ansätzen und würde auch nicht die Gesamtproblematik erschlagen, da es nur eine Linderung brachte.

Der Ansatz die Validierung abzustellen darf keine Lösung sein. Das Sicheheitsfeature existiert nicht ohne Grund.

Zur Information (hatte ich bereits anderweitig gepostet):

Wikipedia - allgemein: https://de.wikipedia.org/wiki/Cross-Site-Request-Forgery

Zu Shopware -Blogbeitrag synonymous: https://synonymous.rocks/was-ist-cross-site-request-forgery-csrf/

Was die diversen Diskussionen in dem Forum angeht, so kann man sich hier ein Bild machen:

https://forum.shopware.com/search?Search=csrf-protection&sLanguage=1

Ob so ein Sammelthread etwas bringt weiß ich auch nicht. Das kann ja nun der geneigte Leser entscheiden. Da dieses aber nicht nur für uns ein Problem ist, wäre zu hoffen, dass sich mal etwas in die richtige Richtung bewegt (ausgehend von oben genannter These).

Kann jemand der das nötige Verständnis dazu hat sich das mal anschauen? http://blog.arithm.com/2014/05/01/know-your-csrf-timeouts/

[tl;dr] Der seit Shopware 5.2.17 vorliegende CSRF-Fehler kommt dadurch zustande, dass beim Aufruf der Anmelde-Seite ein bereits vorliegendes CSRF-Token-Cookie nicht erneuert wird, obwohl die dazugehörige Session bereits abgelaufen ist. Dadurch fällt die anschliessende Validierung zwangsläufig negativ aus.

Hallo,

bei dem aktuellen CSRF-Problem seit Shopware 5.2.17 handelt es sich, wie von baseline-toner schon vermutet, um einen grundsätzlichen Fehler im Session-Handling und nicht um ein individuelles Problem. Dass die Community hierüber derart im Unklaren gelassen wird, ist dabei genauso unschön festzustellen, wie die Tatsache, dass der Bug trotz aller Hinweise darauf seit mittlerweile mehreren Update-Releases gänzlich unberücksichtigt blieb. Die empfohlene Deaktivierung der CSRF-Validierung KANN und DARF auf Dauer keine angemessene Reaktion auf schlecht umgesetzte Programmierarbeit und fehlerhafte Optimierungsversuche sein. Hier sollte Shopware zu alter Größe zurückfinden. Die momentan in der Community und im Forum vorherschende Hilf- und Ratlosigkeit bzgl. der Thematik CSRF-Probleme ist kein Zeugnis schlechter Software, sondern eines schlechten Umgangs mit der Problematik an sich.

Um den Nebel etwas zu lichten und damit sich jeder selbst davon überzeugen kann, dass es sich um ein generelles, im Core angesiedeltes Problem handelt, hier eine Anleitung zur Reproduktion und Eingrenzung des Problems. Der folgende Test funktioniert auch, wenn die CSRF-Validierung in der config.php deaktiviert wurde.

Proof of Concept

   1. Lade die Startseite eines Shopware-Shops
   2. Lösche alle Domain-Cookies
   3. Lade die Seite erneut (um neue, valide Cookies zu erhalten)
   4. Notiere den Wert der Cookies ‚Session-x‘ und ‚__csrf_token-x‘
       (wobei x die ShopID ist, z.B. ‚Session-1‘ und ‚__csrf_token-1‘ beim Hauptshop)
   5. Invalidiere/Lösche die Session in der Shopware-Datenbank, z.B. mit PhpMyAdmin:
       DELETE FROM s_core_sessions WHERE id=’%Wert_des_Cookies_Session-x%’
   6. Rufe die Anmelde-Seite auf (z.B. www.deinshop.de/account )
   7. Vergleiche den Wert des neu erhaltenen Cookies ‚__csrf_token-x‘ mit dem zuvor notierten Wert

Ist der Wert derselbe, ist die Shopware-Installation von dem Bug betroffen.

Ergebnis mit Shopware 5.2.16: der Wert ist verschieden. Begründung: die Cookies werden in Schritt 6 beim Aufrufen der Anmelde-Seite korrekt als nicht valide erkannt und somit erneuert. Mit dem Erneuern der Session bekommt der User auch ein neues gültiges Token übergeben und die anschliessende Anmeldung oder Registrierung klappt somit problemlos.

Ergebnis mit Shopware ab 5.2.17: der Wert ist unverändert. Begründung: die Cookies werden beim Aufrufen der Anmelde-Seite (in Schritt 6) nicht mehr korrekt als ungültig erkannt und somit auch nicht korrekt erneuert. Daher sind die Werte des Cookies in Schritt 4 und 7 (also vor und nach dem Löschen der Session) auch nach wie vor identisch. Der User versucht also, sich mit dem veralteten Token einer mittlerweile ungültigen Session anzumelden, was zwangsläufig scheitern MUSS.

Um den Test auch auf www.shopwaredemo.de zuverlässig nachstellen zu können (oder falls aus anderem Grund ein Zugriff auf die Datenbank des Shops nicht möglich ist), muss man statt die Session in Schritt 5 aktiv zu löschen, nur etwa eine halbe Stunde warten, bevor mit Schritt 6 fortgefahren wird. Während dieser Zeit läuft die Session ab und der Eintrag wird aus der Datenbank gelöscht. Das Ergebnis des Wartens ist somit das gleiche, wie das einer aktiven Löschung.

Wer es noch genauer haben möchte, kann den entsprechenden Blob-Eintrag aus s_core_sessions auch mit einem Hex-Editor öffnen und feststellen, dass dort seit Shopware 5.2.17 beim Aufruf der Anmelde-Seite (und dem einhergehenden Erneuern der Cookies) kein Token-Wert mehr hinterlegt wird.

Fazit: jeder Besucher, dessen Session zwischenzeitlich abgelaufen ist, wird beim Versuch einer Anmeldung oder Registrierung zwangsläufig an der CSRF-Validierung scheitern.

Der Fehler kommt dadurch zustande, dass beim Aufruf der Anmelde-Seite ein bereits vorliegendes CSRF-Token-Cookie nicht erneuert wird, obwohl die dazugehörige Session bereits abgelaufen ist. Dadurch fällt die anschliessende Validierung zwangsläufig negativ aus.

Vielleicht kommt ja etwas mehr Zug in die Sache, wenn die Umstände klarer werden – und der jüngst eingebaute Bug wird endlich wieder behoben.

Da wurden wohl beim Versuch der Optimierung im Rahmen des Updates auf 5.2.17 ein paar Funktionen zuviel weggekürzt. Fehler passieren, aber dafür sollte man dann auch einstehen und diese offen kommunizieren.

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

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!!

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: Versuch eines Sammelthreads zu X-CSRF-Token / Validierungsproblem - #10 von SebastianKloepper - Allgemein - Shopware Community Forum 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