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