Gravierender Fehler 5.7.9 - CSRF-Token

Solange SW5 noch Updates bekommt und man die aktuellste Version im Einsatz hat, benötigt man das Sicherheitsplugin nicht, da die „löcher“ in SW5 dann bereits gestopft sind. Doppelt gemoppelt hält in dem Fall dann auch nicht länger :wink:

Zitat aus der Pluginbeschreibung:

Falls Du Dein System nicht, wie empfohlen, auf die neuste Version updaten kannst, sicherst Du Dich mit Updates dieses Plugins ab.

Ja das ist klar aber das ist aktuell auch gar nicht das Problem. Habe ich etwas unglücklich ausgedrückt: Bei den Shops „unter 5.7.10“ (die wir noch nicht auf die neueste Version bringen konnten) haben wir die Option #26662 aufgrund der weiter bestehenden Probleme deaktiviert.

Hallo @P.Thesing,

in der config.php war nur der

‚logger‘ => [
‚level‘ => 300,
],

drin. Habe ich rausgeholt.

Der CSRF-Token-Fehler besteht nach wie vor.

Bestehende Tickets dazu (z.B. Shopware Issuetracker) wurden jetzt kommentarlos geschlossen. Scheint also wirklich nichts mehr zu passieren bzgl. des Plugins.

@LarsFischu entschuldige bitte, dass wir das Ticket ohne Kommentar geschlossen haben.
Wir haben uns intern das Problem bereits angeschaut, aber konnten das Problem nur mit einer kaputten Konfiguration der Shops herstellen.

Leider bot das Issue nicht genügend Informationen, damit wir das Problem mit einer validen Konfiguration herstellen. Daher bitte ich darum, genauere Informationen oder am besten noch eine Test-Umgebung per Support Ticket bereitzustellen. Wir möchten auch die neuen Probleme mit den CSRFs lösen.

1 „Gefällt mir“

@lederwerkstatt,
leider ist das nicht die ganze Konfiguration.
Da müssen noch eine weitere Information vorhanden sein.
Wichtig ist es bspw. die front und php Konfiguration für das Anzeigen von errors zu entfernen.

Danke für die transparente Antwort. Wir werden die Option bei unseren Umgebungen morgen wieder aktivieren. Sollten hier Probleme / Kundenmeldungen dazu auftreten, versuchen wir eine Möglichkeit herzustellen, damit der Fehler untersucht werden kann.

1 „Gefällt mir“

@LarsFischu ich Danke Dir für Deine Bemühungen!

Das Problem scheint wie folgt reproduzierbar zu sein:

  1. eine Session im Live-Shop starten (der Cookie __csrf_token-1 wird angelegt)
  2. in den Test-Shop im Unterverzeichnis gehen, jetzt wird kein __csrf_token-1 Cookie mit dem passenden Path angelegt und es knallt

Das Problem scheint der fehlende Pfad im Cookie zu sein. Vielleicht wird irgendwo mit und irgendwo ohne gearbeitet. So zumindest meine naive Sicht von Außen.

Hallo @P.Thesing,

in der config.php sind keine weiteren Einträge enthalten als diese:

<?php return array (
  'db' => 
  array (
    'username' => 'xxx',
    'password' => 'xyz',
    'host' => '127.0.0.1',
    'port' => '3306',
    'dbname' => 'name',
  ),

 'csrfProtection' => [
        'frontend' => true,
        'backend' => true
    ], 
	
'cdn' => [
    'backend' => 'bunnycdn',
    'adapters' => [
        'bunnycdn' =>
            [
                'type' => 'bunnycdn',
                'mediaUrl' => 'xyz',
                'apiUrl' => 'https://xyz/',
                'apiKey' => '12345'
            ]
     ]
]

);

Sollte hier nach dem Update noch weitere Einträge notwendig geworden sein, bitte Info.

Hallo @NextMike

wie ist denn genau das Setup bei dir? Ich nehme an, das sind letztlich zwei Shopware Installationen, relativ identisch?
Welche Shopware Version? und welche Version des Security Plugins? Wie sehen die jeweiligen Shop-Konfigurationen aus? Sprich Host, Pfad, virtuelle URL, usw, was halt rein spielen könnte. (Einstellungen → Grundeinstellungen → Shopeinstellungen → Shops)

Viele Grüße aus Schöppingen
Michael Telgmann

Hallo @Michael_Telgmann,

ja genau, die SW Installationen sind nahezu identisch.

Live-Shop: https://www.mein-shop.de/
Test-Shop: https://www.mein-shop.de/TEST

Shopware 5.5.8
Shopware Security Plugin 1.1.29

Host: identisch
Virtuelle URL: /TEST
Pfad: leer
SSL: ja

Habe ich was relevantes vergessen?

Liebe Grüße

Hey, hast du recht!
Kannst du bitte auch deine php.ini überprüfen? Diese darf auch keine Fehler werden. (‚error_reporting‘ und ‚display_errors‘)

Hallo @NextMike

ich nehme an, „TEST“ ist dann auch wirklich ein physikalischer Unterordner?

Dann wäre der Weg über die virtuelle URL nicht korrekt. Diese wird eher genutzt, um z.B. Sprachshops von einander zu unterscheiden „/de“ oder „/en“, die aber dann letztlich keinen wirklichen Ordner entsprechen, eben virtuell sind.

Da deine Test-Instanz in einem wirklich vorhandenen Unterordner liegt, musst du hier die Pfad-Konfiguration nutzen. Also einmal den Wert aus „Virtuelle URL“ in „Pfad“ rüber packen.

Anschließend sollte es funktionieren. Ich bin auf dein Feedback gespannt.

Viele Grüße aus Schöppingen
Michael Telgmann

Hallo @Michael_Telgmann,

danke, ja so passt es und es macht im Nachhinein Sinn :slight_smile:

Der Ordner ist sogar ein Symlink. Falls es etwas zur Sache tut. Aber so bekommt der Cookie den Path und es scheint damit keine Probleme mehr zu geben.

Liebe Grüße

2 „Gefällt mir“

Hallo @P.Thesing,
ich verwende php 8.0.18 und plesk obsidian 18.

display_errors sind off (standard) und error_reporting E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED (standard).
Auch wenn ich letzteren auf None oder 0 stelle, entsteht der CSRF-Token-Fehler, wodurch im Live-Shop 5.7.10 keine Bestellung mehr möglich ist. - Es sei denn, in der config.php ist die csrfProtection fürs frontend auf false gestellt.

Inzwischen melden ja weitere Shopbetreiber das selbe Problem…

Hier das gleiche Problem mit 5.6.10 in drei unterschiedlichen Shops.
Issue wurde geschlossen, weil nicht nachzustellen.
Nun ja, ich kann es gerne vorführen, bei Bedarf.
Ich soll ein Ticket aufmachen - nun Community Shop > Ticket?

base_path und base_url passen hier auch, damit hat das nichts zu tun.
Cookies wurden gelöscht und wir haben das an verschiedenen Rechnern an drei Firmenstandorten nachstellen können.
Ebenfalls leider auch etliche Kunden, die unsere Hotline dann beruhigen und die Aufträge händisch aufnehmen mussten.

Nach positiven Tests habe ich heute auch aktualisiert. Unter Win 10 und Chrome hatte ich keine Probleme. Jetzt unter Android und Firefox und Chrome kann ich mich auch nicht anmelden. Daten und Cookies gelöscht, es bleibt beim Tokenfehler. Morgen mal weiter nachforschen.

Stell die Fixes doch zurück :wink:

Dann hast Du Ruhe.

Hallo,
Wie kann ich denn auf Version 1.1.27 das Plugin zurücksetzen? Kann ich das irgendwo runterladen?
Muss ich das alte dann deinstallieren und die Version 1.1.27 erneut installieren?

Würde ich gerne machen, da ich nicht wirklich ausschließen kann, ob bei uns alles reibungslos funktioniert. Seit dem Update haben wir deutlich weniger Bestellungen, obwohl ich die letzten beiden Punkte im Plugin deaktiviert habe

Danke für Hilfe
Lieben Gruß