Versuch eines Sammelthreads zu X-CSRF-Token / Validierungsproblem

@dakl schrieb:

Könntet ihr ja gerne auf einem neutralen Testsystem machen. Das Angebot steht ja, habt ihr aber abgewiesen, da es sich um eine extra Installation handelt auf der lizensierten Domain, dort wäre nach der Aktivierung alles schön reproduzierbar gewesen und das seit Januar 2017, also, so ganz richtig läuft da was nicht bei euch oder es gibt Verständigungsprobleme. 

Ich glaube wir reden etwas aneinander vorbei. Ist aber auch nicht weiter tragisch.  Hier geht es erstmal primär um den CSRF-Token. Mein Einwurf hatte damit konkret ziemlich wenig zu tun, es ging eher darum, dass man für einen Support auch zugriff auf das System des Kunden braucht. Wenn man den nicht bekommt, wird Support - egal in welcher Form - natürlich schwierig. Hat aber nicht wirklich etwas mit dem CSRF-Problem zu tun.

Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.

3 Likes

@Moritz Naczenski schrieb:

Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.

Hallo Moritz,

gibt es zu den möglichen Patches bereits irgendwelche Infos? Wir brennen vor Neugierde… :wink:

 

@kkr8 schrieb:

@Moritz Naczenski schrieb:

Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.

Hallo Moritz,

gibt es zu den möglichen Patches bereits irgendwelche Infos? Wir brennen vor Neugierde… :wink:

 

Ja, mir liegen die neuesten Infos vor, dass CSRF in der Version 5.2.21 entfernt wird. Für alle die, die früher in den Genuß des tollen Features kommen wollen:  CSRF Protection

#alternativefacts #fakenews

@kkr8 schrieb:

@Moritz Naczenski schrieb:

Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.

gibt es zu den möglichen Patches bereits irgendwelche Infos? Wir brennen vor Neugierde… :wink:

Erstmal muss das ausreichend getestet/evaluiert werden. Dann gfibt es auch Informationen dazu. 

@NextMike schrieb:

@kkr8 schrieb:

@Moritz Naczenski schrieb:

Meine Kollegen werden morgen einen möglichen Patch einmal in ein paar Kundensystemen (natürlich mit vorherige Nachfrage) testen. Dann haben wir ggf. schon einen potentiellen Fix, der ein paar Probleme beheben wird. Zumindest Probleme die mit einer verlorenen Session zu tun haben. Alles andere wird sich dann noch separat angeschaut.

Hallo Moritz,

gibt es zu den möglichen Patches bereits irgendwelche Infos? Wir brennen vor Neugierde… :wink:

 

Ja, mir liegen die neuesten Infos vor, dass CSRF in der Version 5.2.21 entfernt wird. Für alle die, die früher in den Genuß des tollen Features kommen wollen:  https://developers.shopware.com/developers-guide/csrf-protection/#disable-the-protection

Das ist kompletter Quatsch.

Hallo,

wir haben unseren potentiellen Fix gestern bereits bei einigen Kunden ausprobiert. Dieser Fix behebt Probleme mit einer abgelaufenen/geänderten Session. Konkret sollte dies also die Probleme mit der Registrierung beheben. Andere Bereiche, die nicht direkt durch dieses Session-Problem einen Fehler werfen, werden noch separat geprüft (bspw. Newsletter). Wir haben die Prüfung auf den Token etwas geändert, sodass nun auf den Inhalt des Cookies geprüft wird und nicht mehr auf den Inhalt der Session. Sollte also aus irgendwelchen Gründen die Session verloren gehen, ist die Prüfung weiterhin erfolgreich.

Ihr könnt das selbst bereits einmal testen.

Datei: /engine/Shopware/Components/CSRFTokenValidator.php
​Zeile: 146-149

Aktuell:

if ($request->isPost()) {
/** @var \Enlight_Components_Session_Namespace $session */
$session = $this->container->get('session');
$token = $session->offsetGet('X-CSRF-Token');

Ändern in:

if ($request->isPost() && !$request->isXmlHttpRequest()) {
$context = $this->container->get('shopware_storefront.context_service')->getShopContext();
$token = $request->getCookie('__csrf_token-' . $context->getShop()->getId());

Bei unseren Testshops war danach kein Fehler mehr in den Core-Logs erkennbar. Wichtig ist natürlich, dass ihr dann den CSRF-Token im Frontend wieder aktiviert.
Wie beschrieben wird dies nicht an jeder Stelle, jede Meldung beheben. Es gibt weiterhin Plugins die einen solchen Fehler werfen und Bereiche, die von uns separat geprüft werden (bspw. die Newsletteranmeldung). Die Registrierungsprobleme sollten dadurch allerdings behoben sein.

Moritz

2 Likes

Also Shop auf HTTPS SSL umstellen klappt auf jeden Fall. Damit konnte man den Fehler schnell umgehen. Ist zwar nicht geklärt warum, aber Fall gelöst und noch HTTPS für den Kunden aktiviert. Mit: https://certbot.eff.org/ auf Linux Root Server fix erledigt. Sollte man in Erwägung ziehen!

Kann ich mir nicht vorstellen, da mein Shop schon immer auf SSL läuft

Das „klappt auf jeden Fall“ können wir auch nicht bestätigen. Wie schon eingangs des Threads erwähnt, hatten wir auch den Eindruck der „Linderung“ nach Komplettumstellung auf https, aber keineswegs war dieses dann die Lösung. D.h., jeder kann und sollte das gerne mal probieren und beobachten was passiert. Allerdings muss man Usern die eine Lösung suchen mitteilen, dass diese Aussage von dkBits in der Pauschalität schlichtweg falsch ist.

 

 

Guten Abend Shopware Community,

 

die Zeilen erreichen Euch aus Tiflis (Georgien). Der ferne Kaukasus benötigt Eure Unterstützung. Ich habe mehrere Stunden aufgewendet um mich im Forum informieren zu lassen. Habe viel versucht und entschlossen mit meinem Anliegen an Euch zu wenden. Habe keinen Nerv mehrJ))

Es geht um folgendes:

Ich versuche einen georgischen Shopwareshop zu meistern.

Ich habe 2 gleiche Versionen von Shopware 5.2.18 auf 2 unterschiedlichen Servern installiert. Einmal bei von Shopware als Test angebotenem Server Profihost und die 2 auf dem Server in Georgien.

Auf dem deutschen Server funktioniert die Kundenlogin soweit einwandfrei. Auf dem georgischen kam immer wieder zu ups meldung mit X-CSRF-Token geschichte und ich habe wie im Forum empfohlen

’csrfProtection’ => [

    ‘frontend’ => false,

    ‘backend’ => true

  ],

benutzt.

Ups Fehlermeldung erscheint nicht mehr, aber das Login funktioniert wieder nicht. Das hat also noch kein einziges mal geklappt. Man wird nicht eingelogt und bleibt auf der gleichen Seite gefesselt.

Die Registrierung funktioniert halbwegs gut. Ich bekomme als Shopbetreiber die „Kundendaten“ auf die Email zugeschickt aber direkt auf der Web Seite bekommt der „Kunde“ keine Meldung nach der Registrierung. (ich weiss nicht ob es so sein soll). Möchte man mit der gleichen Emai adresse neu registrieren kommt die Meldung dass die Adresse bereits registriert ist.

Ich habe dem georgischen Hostinganbieter alles optimieren lassen. Es läuft PHP 7 auf dem server und ion Loader ist auch installiert.

Habe pingelig darauf geachtet, dass bei der  Installation auf dem georgischen Server alle von Shopware angegebene Voraussetzungen erfüllt waren.

Das einzige was nicht passen könnte ist
dass APCu und Zend OPcache nicht aktiviert angezeigt werden. Kann es daran liegen, dass die Anmeldung nicht funktioniert?

Die shop Adresse auf dem deutschen Server lautet

http://glimtrex.ge.shopware-hosting.com/

auf dem georgischen

www.enamelart.in

Habe auch mit

 

if ($request->isPost() && !$request->isXmlHttpRequest()) {

$context = $this->container->get(‘shopware_storefront.context_service’)->getShopContext();

$token = $request->getCookie(’__csrf_token-’ . $context->getShop()->getId()); versucht, aber ohne Erfolg.  

 

Kennt Ihr eventuell einen Rat?

 

Ich danke im Voraus

@coarsy schrieb:

Kann ich mir nicht vorstellen, da mein Shop schon immer auf SSL läuft

Ebenso hier, Shop läuft komplett auf SSL, sind trotzdem auf die Nase gefallen.
Sollte ich morgen die Zeit finden, werde ich den Fix einmal testen.

Hat von euch schon jemand den pot. Fix im Einsatz und kann uns hier etwas Feedback geben?

Also, habe den Fix eben getestet - bisher alles prima - keine Fehler mehr - 5.2.20

  • CSRF-Token wieder aktiviert

  • Code in der CSRFTokenValidator.php geändert

  • Shop Cache gelöscht

  • Browser (Firefox) Cache gelöscht

  • Kekse für den Shop gelöscht

  • Backend Login ok (vor dem Login vergessen, die Seite neu zu laden - klar, Fehler)

  • Shopseite neu geladen

  • Mein Konto > Login - ok

  • Testbestellung bis Paypal - ok

  • Testbestellung ohne Konto bis Paypal - ok

Alles im ersten Anlauf und ohne Fehlermeldung.

Hoffentlich bleibt es so :wink:

Grüße, Ralph

Ich kann es leider nicht testen, da ich ja auch ohne Patch keine Probleme habe.

Aber mir ist heute erstmals etwas passiert, was ich nicht ganz zuordnen kann:
Beim Aufruf vom Backend kam gleich das Fenster, dass etwas nicht funktioniert, und im Fenster war CSRF
Soweit - so schlecht - denn: Cookies löschen und Browser neu starten hat nicht geholfen (Chrome). Ein anderer Browser funktionierte.
Nur “Dateien im Cache” löschen brachte mir das Login zurück.

Werden noch irgendwelche Token-Daten in JS-Datein eingesetzt, die ggf. die Sitzung im Browser überleben?

@Moritz Naczenski schrieb:

Hat von euch schon jemand den pot. Fix im Einsatz und kann uns hier etwas Feedback geben?

Version 5.2.20 hat nach dem vorhin genannten Patch

Habe auf der folgenden Seite im Checkout https://www.aboveall.me/checkout/shippingPayment > 30 Minuten abgewartet und mich dann ohne Probleme einloggen können. Vorhin vorhin gab es dort die CSRF-Meldung.

 

Hallo Moritz,

ich habe den Fix soeben getestet (mit einer 5.2.18) und es zeigt sich leider keine Besserung. Die Anmeldung/Registrierung schlägt nach wie vor fehl, sobald die Session zuvor abgelaufen ist. Der Wert wird beim Aufrufen der Login-Seite nicht erneuert. Und in dem entsprechenden Blob-Eintrag in s_core_sesssions (wo der Token-Wert ja abgelegt wird bzw. werden sollte), ist von einem neuen Token-Eintrag immer noch nichts zu sehen.

Daher leider negativ.

edit: diesmal war ich wohl zu voreilig. Nachdem die Cache-Verzeichnisse unter /var/cache/production… gelöscht wurden, scheint der Fix zumindest teilweise zu greifen. Beim Anmelden/Registrieren habe ich nun auch nach einer verlorenen Session keine Fehlermeldung mehr (dem galt der Fix wohl auch). Ich werde das mal aktiviert lassen und beobachten, bei Gelegenheit weiter testen und weiteres Feedback geben, sobald sich weitere Rückschlüsse ergeben.

Fehler nach BE Login, FE bisher weiter sauber…
Passiert nach Löschen des Browser Caches und Löschen Shop Cookies:

Shopware\Components\CSRFTokenValidationException: The provided CSRF-Token is invalid. If you’re sure that the request to path “/backend/Login?file=app&no-cache=1489153799” should be valid, the called controller action needs to be whitelisted using the CSRFWhitelistAware interface. in /engine/Shopware/Components/CSRFTokenValidator.php:118 Stack trace:
#0 /engine/Library/Enlight/Event/Handler/Default.php(91): Shopware\Components\CSRFTokenValidator->checkBackendTokenValidation(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 /engine/Shopware/Components/HttpCache/AppCache.php(103): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true)
#10 /www/htdocs/w00f7e6a/shop.pepari.de/shopware.php(117): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
#11 {main}

Bei uns läuft alles bis auf das was mein Vorredner schrieb.

Nach der Änderung hab ich in den Systeminfos den Hinweis, dass die CSRFTokenValidator.php verfügbar ist. Jedoch Status deaktiviert ist. Bedenklich oder nicht?