Versuch eines Sammelthreads zu X-CSRF-Token / Validierungsproblem

Habe die config.php runtergeladen und sie mit einem Texteditor geöffnet … steht aber trotzdem nicht mehr drin.

Ich lass die Finger davon, bevor ich was “zerschieße”

Danke an Euch für die Tips.

@Vitago GmbH schrieb:

Verstehe die Aufregung auch nicht ganz, abschalten und gut ist.

Was ich auch nicht ganz verstehe, warum immer gleich alle Updaten müssen, wir verwenden immer noch die 5.1.6 und haben keine Probleme. Smile Ein Update kommt für uns wenn überhaupt erst nächstes Jahr in Frage, bzw. wenn wir uns sicher sein können dass alle Kinderkrankheiten beseitigt wurden. 

Bei der 5.2 wurde sehr viel geändert, da hätte eigentlich jedem klar sein müssen das die nicht gleich fehlerfrei laufen wird, ist bei fast jeder Software so. Und das manche Fehler erst im laufenden Betrieb endeckt werden, ist auch nix neues. ;)

abschalten ist nicht gut, warum kann man hier im Forum nachlesen.

Und die Einstellung, dass wenn etwas neu ist auch fehlerhaft ist, ist traurig aber wohl wahr. Wenn man für etwas bezahlt erwartet man auch eine entsprechende Gegenleistung.

Wenn ein neues Auto auf den Markt kommt, geht man ja auch davon aus, dass wenn man nach links lenkt, das Auto dann auch nach links fährt, oder akzepiert man das dann weil es ein neues Modell ist und dann halt nur noch rechts herum im Kreis fährt?

Die Version 5.2.xx ist ja schließlich keine Betaversion, entsprechend sind dann auch die Erwartungen.

 

@Moritz Naczenski schrieb:

Wir können natürlich jetzt über das “hätte, würde, könnte” diskutieren oder einfach konstruktiv zusammen an einer Lösung arbeiten. 

nein, darüber müssen wir nicht diskutieren, schickt doch einfach eine Mail an Eure Kunden mit dem Hinweis auf dieses Problem und wie man das mit der config.php macht und alles ist erst mal gut. Eure Kunden wissen, dass das Problem bekannt ist und man daran arbeitet, das wäre sehr beruhigend. Anstatt den Kunden verzweifelt nach dem Fehler suchen zu lassen und ihn dann endlich, nachdem unzählige andere Kunden den Fehler hier im Forum besprochen haben, hier im Forum fündig werden zu lassen. Wer weiß wie viele Eurer Kunden von dem Fehler noch nichts wissen und sich wundern warum so viele Bestellabrüche vorhanden sind? Es ist eher seltener der Fall, dass der Kunde anruft und darauf aufmerksam macht.

1 Like

@VELNCS schrieb:

Habe die config.php runtergeladen und sie mit einem Texteditor geöffnet … steht aber trotzdem nicht mehr drin.

xxxxxxxxxxxx  ersetzen mit Deinen Daten, dann passt das (mit dem Text-Editor, damit da keine Sonderzeichen reinkommen):

<?php return array (
  'db' =\>    array (     'host' =\> 'localhost',     'port' =\> '3306',     'username' =\> 'xxxxxxxxxxxx',     'password' =\> 'xxxxxxxxxxxx',     'dbname' =\> 'xxxxxxxxxxx',   ), 'csrfProtection' =\> [     'frontend' =\> false,     'backend' =\> true ], );

@MichaelVD schrieb:

@VELNCS schrieb:

Habe die config.php runtergeladen und sie mit einem Texteditor geöffnet … steht aber trotzdem nicht mehr drin.

xxxxxxxxxxxx  ersetzen mit Deinen Daten, dann passt das (mit dem Text-Editor, damit da keine Sonderzeichen reinkommen):

<?php return array (
  'db' =\>    array (     'host' =\> 'localhost',     'port' =\> '3306',     'username' =\> 'xxxxxxxxxxxx',     'password' =\> 'xxxxxxxxxxxx',     'dbname' =\> 'xxxxxxxxxxx',   ), 'csrfProtection' =\> [     'frontend' =\> false,     'backend' =\> true ], );

danke die xxxxxx habe ich hier eingesetzt da ich meine Passwort usw. nicht öffentlich zigen wollte.

vertehe ich das nun richtig, in dieser Datei darunter hinzufügen :

‚csrfProtection‘ => [
    ‚frontend‘ => false,
    ‚backend‘ => true
],

);

@VELNCS schrieb:

danke die xxxxxx habe ich hier eingesetzt da ich meine Passwort usw. nicht öffentlich zigen wollte.

vertehe ich das nun richtig, in dieser Datei darunter hinzufügen :

‘csrfProtection’ => [
    ‘frontend’ => false,
    ‘backend’ => true
],

);

also um sicher zu gehen, so sieht das komplett aus (xxxx halt eben deine Daten):

  array (
    'host' => 'localhost',
    'port' => '3306',
    'username' => 'xxxxxxxxxxxx',
    'password' => 'xxxxxxxxxxxx',
    'dbname' => 'xxxxxxxxxxx',
  ),


'csrfProtection' => [
    'frontend' => false,
    'backend' => true
],


);

 alles was neu eingefügt wird vor der letzten schließenden Klammer mit semikolon ist das hier:

'csrfProtection' => [
    'frontend' => false,
    'backend' => true
],

 

Du kannst ja, wenn Du unsicher bist, die config.php erst mal runterladen und lokal speichern, falls du doch einen Tippfehler haben solltest hast du dann das Original

1 Like

SUPER !

Danke !!!

so einfach erklärt hätte ich mir das von SW gewünscht.

Hatte mir nen „Wolf gesucht“  nach

'csrfProtection' => [
    'frontend' => false,
    'backend' => true

hätte ich gewußt das es lediglich hinzugefügt wird ....

OK, die mit Programierkentnissen schmunzeln jetzt wohl

Funktioniert einwandfrei

@VELNCS schrieb:

SUPER !

Danke !!!

so einfach erklärt hätte ich mir das von SW gewünscht.

Hatte mir nen „Wolf gesucht“  nach

‚csrfProtection‘ => [
‚frontend‘ => false,
‚backend‘ => true

hätte ich gewußt das es lediglich hinzugefügt wird ....

OK, die mit Programierkentnissen schmunzeln jetzt wohl

Super, ich freue mich jemandem habe helfen zu können :slight_smile:

Hallo SW-Team, das ist jetzt ein typisches Beispiel, genau das hätte ich von Euch auch erwartet, nicht jeder ist Programmierer der einen Onlinehandel betreibt,

warum nicht einfach eine Infomail an alle Eure Kunden mit einer einfachen Anleitung und Info darüber, dass das Problem bekannt ist und ein Bugfix in Arbeit ist?

Dann wäre Euer Forum auch nicht so zugemüllt mit klagenden und hilfesuchenden Shopware-Usern die das CSRF Problem haben. Und Eure Kunden wären glücklicher!

 

2 Likes

Erstaunlich, was hier manche für eine Anspruchshaltung an den Tag legen!
Bei soviel Gemecker wären inhaltsvolle Beiträge, die SW helfen könnten, das Problem einzugrenzen, auch nicht schlecht - kann ich nach wie vor aber nichts von lesen.

Wer grundlegende Basics nicht beherrscht, wäre bei einem Dienstleister besser aufgehoben - oder um obiges aufzugreiffen: Wenn man keine Ahnung von der Technik hat, sollte man sich ein KFZ nicht als Bausatz kaufen. Wer nichtmal nach mehrfachen Anleitungen die config.php anpassen kann, der sollte sich wirklich dem Verkaufen hingeben, und seinen Shop vom dem warten lassen, der wenigsten EIN WENIG Ahnung hat.

Ist es wirklich so schwer zu verstehen, dass das Problem kein allgemeines, alle betreffendes ist, sondern von besonderen Faktoren abhängt?
Keine 10 Beiträge, aber ein Fass aufmachen… da bekommt nan richtig Lust, “Neulingen” im Forum noch zu helfen.  Thumb-down

Auch wieder so ein nutzloser Seitenhieb: Hättest Du mal in die Doku geguckt, hättest Du Die keinen Wolf suchen müssen:
CSRF Protection

2 Likes

Sonic, ich gebe Dir recht, wenn man keine Ahnung hat, einfach mal Klappe halten!

Denn hier handelt es sich sehr wohl um ein Problem, das seit Version 5.2.17 aufwärts alle betrifft…

1 Like

DEIN Beispiel ist konstruiert und trifft nicht das Problem im Allgemeinem, aber hauptsache mal aufgespielt.
Komisch, dass es nach wie vor 5.2.20 Shops gibt, die keine Probleme haben.

Der Eindeutigkeit halber wurden die Tests mit frisch aufgesetzten Basis-Installationen der jeweiligen Shopware-Versionen (5.2.16, 5.2.17 und 5.2.20) auf ein und demselben System zeitgleich durchgeführt. Sprich: keine Plugins, keine Themes, keine Daten, keine Konfiguration, keine unterschiedliche Arbeitsumgebung vorhanden, die den Fehler hätten verursachen können. Es handelt sich somit definitiv um einen Fehler, der seit der Version 5.2.17 mit Shopware ausgeliefert wird und seitdem zuverlässig auftritt, und zwar bei JEDER bislang getesteten Shopware-Installation.

@kkr8 schrieb:

Sonic, ich gebe Dir recht, wenn man keine Ahnung hat, einfach mal Klappe halten!

Denn hier handelt es sich sehr wohl um ein Problem, das seit Version 5.2.17 aufwärts alle betrifft…

Hallo,

da muss ich sonic Recht geben - alle Shops ab Shopware Version 5.2.17 betrifft es ganz sicher nicht, das kann ich bestätigen. Es gibt genug Shops ab Shopware Version 5.2.17, bei denen keine CSRF-Token-Fehler oder ähnliches kommen (das kann man ja recht einfach sehen, wenn man in die Server-Logs schaut - wenn dort keine Fehler drin sind, gibt es auch keine). Ein grundlegendes Problem ist es also nicht, also würde ich mit dem Begriff “alle” etwas vorsichtiger umgehen, da ich nicht glaube, das du alle Shopware-Shops betreust.

Beste Grüße

Sebastian

Ich schreibe die Informationen mal zusammen, dann braucht man sich den Thread auch nicht komplett durchlesen.

 

Hallo,

aktuell gibt es vermehrt Hinweise darauf, dass es während der Registrierung/Anmeldung in einigen Fällen zu einer Fehlermeldung kommt, die durch den CSRF-Token verursacht wird. Dieses Verhalten prüfen wir im Rahmen des Tickets SW-17932.
Anbei möchte ich euch einige Informationen auf den Weg geben, wir Ihr den Fehler eingrenzen könnt.

Zweck:

Der CSRF-Token ist ein Sicherheitsmechanismus der verhindert, dass ein POST-Request ohne Token ausgeführt wird. Ein typisches Beispiel wären Spam-Registrierungen von Bots ohne Session/Cookie. Damit wird aber auch verhindert, dass per Link ein POST-Request ausgeführt wird der bspw. eine Aktion im Backend ausführt.

 

Ausnutzung :

Das Feature besteht erst ab SW5.2 und bisher sind keine Fälle bekannt, die explizit auf einen fehlenden Token zurück zu führen sind. Shopware hat weitere Mechanismen die das Einspielen von Schadcode verhindern. Wenn man also etwas die Augen offen hält und nicht jeden x-beliebigen Link anklickt, gibt es auch ohne den Token erstmal keine bekannten Probleme. Es ist ein zusätzlicher Sicherheitslayer. Nach Deaktivierung hat man das Verhalten wie in SW5.1.

 

Fehlersuche :

Damit ihr zunächst herausbekommt, ob ihr von dieser Problematik betroffen seid, solltet ihr einen Blick in das SW-Log werfen (Verzeichnis /var/log) oder die Option „Fehlermeldung an Shopbetreiber senden“ aktivieren. Auf keinen Fall solltet ihr das erweiterte Debugging aktiv lassen (nur zur temporären überprüfung gedacht), da dies verhindert, dass im Fehlerfall der Token erneuert wird. Mit erweitertem Debugging bekommt der potentielle Kunde dann immer diese Fehlermeldung! Mit der Option „Fehlermeldung an Shopbetreiber senden“ werden auch weitere Parameter wie bspw. die Formulardaten mit übermittelt, damit man eingrenzen kann, ob ein Kunde den Fehler erzeugt hat oder ein Bot.

Deaktivierung:

Die Deaktivierung kann einfach über die config.php im Hauptverzeichnis des Shops vorgenommen werden. Der Code sieht wie folgt aus:

'csrfProtection' => [
    'frontend' => false,
    'backend' => true
],

Ein direktes Beispiel einer fertigen config.php:

 [
        'username' => '%db.user%',
        'password' => '%db.password%',
        'dbname' => '%db.database%',
        'host' => '%db.host%',
        'port' => '%db.port%'
    ],
	'csrfProtection' => [
    	'frontend' => false,
    	'backend' => true
	],
];

Es macht keinen Sinn den Schutz für das Backend zu deaktivieren, wenn man dort keine Probleme hat.

Sonstiges:

Nur weil eine solche Meldung im Log steht, ist man noch lange nicht von einem akuten Problem betroffen. Hier sollte man speziell auf die POST-Daten der Fehlermeldung, sowie die URL in den Logs überprüfen. Um eine detaillierte individuelle Überprüfung wird man hier nicht drum herum kommen. Es heißt nicht, dass der Fehler in den Logs unbedingt mit o.g. Problem etwas zu tun hat. Die Fehlermeldung kann alle Bereiche von SW betreffen.

Viele Grüße
Moritz

4 Likes

sschreier: kann ich technisch ausschliessen. Daher würde ich mich doch gerne selbst davon überzeugen, hast Du einen Link zu einem derartigen Shop?

@kkr8 schrieb:

sschreier: kann ich technisch ausschliessen. Daher würde ich mich doch gerne selbst davon überzeugen, hast Du einen Link zu einem derartigen Shop?

Höchstwahrscheinlich wurde die CSFR Geschichte dort deaktiviert ;-) 

@kkr8 schrieb:

Der Eindeutigkeit halber wurden die Tests mit frisch aufgesetzten Basis-Installationen der jeweiligen Shopware-Versionen (5.2.16, 5.2.17 und 5.2.20) auf ein und demselben System zeitgleich durchgeführt. Sprich: keine Plugins, keine Themes, keine Daten, keine Konfiguration, keine unterschiedliche Arbeitsumgebung vorhanden, die den Fehler hätten verursachen können. Es handelt sich somit definitiv um einen Fehler, der seit der Version 5.2.17 mit Shopware ausgeliefert wird und seitdem zuverlässig auftritt, und zwar bei JEDER bislang getesteten Shopware-Installation.

Das bestreitet doch auch niemand. Er tritt nur nicht immer auf, d.h. der Fehler bedeutet nicht, dass sich niemand mehr registrieren oder anmelden kann. Mag sein, dass es Shops gibt, wo es häufig dazu kommt, aufgrund der Konstellation, in anderen vielleicht nicht so häufig. 

@kkr8 schrieb:

sschreier: kann ich technisch ausschliessen. Daher würde ich mich doch gerne selbst davon überzeugen, hast Du einen Link zu einem derartigen Shop?

Hallo,

ich wüsste jetzt keinen sinnvollen Grund, warum ich dir einen Link zu einem betreuenden Shop geben sollte, vorallem wenn du nicht einmal FTP-Zugangsdaten oder anderes besitzt, um die Logs zu prüfen. Wie gesagt, es gibt keinerlei Fehlermeldungen in den Server-Logs, vor allem nicht, die den CSRF-Token betreffen. Und die Shopware - Version ist die 5.2.20 . Somit kann ich da doch davon ausgehen, das kein CSRF-Problem besteht. Und nachweisen muss ich es dir auch nicht, da das überhaupt nichts zur Sache tut, da ich kein Shopware - Mitarbeiter oder ähnliches bin, der dich von irgendetwas überzeugen will oder muss. Du kannst es glauben oder eben nicht. Und natürlich ist die CSRF-Protection aktiv, die config.php ist weiterhin unverändert und jungfräulich.

Würden bei den Shops CSRF-Fehler in den Server-Logs auftauchen, würde man das ja sehen, wenn entweder eine Log-Datei erstellt worden wäre oder in einer bestehenden Log-Datei ein CSRF-Fehler drin stehen würde - dies trifft aber nicht zu (und das obwohl die CSRF-Protection aktiv und die config.php-Datei unverändert ist). Wie gesagt, für mich besteht kein sinnvoller Grund zu lügen oder jemand vom Gegenteil überzeugen zu müssen.

Ich würde einfach die Prüfung von Shopware abwarten.

Beste Grüße

Sebastian

sschreier, nein, beweisen musst Du mir genauso wenig, wie ich Dir. Steht jedem frei, seine These zu untermauern oder als blosse Beahauptung im Raum stehen zu lassen…

Wenn Du Dir meinen Test mal genauer anschaust, wirst Du feststellen, dass es hierfür keinen Zugriff auf Logfiles bedarf. Und er funktioniert sogar, wenn die CSFR-Validierung zuvor deaktiviert wurde.

Was die Prüfung seitens Shopware angeht, ist der Bug als zu fixen eingestuft worden: https://issues.shopware.com/issues/SW-17932?_ga=1.37025824.109096974.1486991205

Das ist, was ich wollte. Ob mein Beitrag von Einzelnen hier persönlichen Zuspruch erfährt oder nicht, tut nichts zur Sache.