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?
Nach der Änderung hab ich in den Systeminfos den Hinweis, dass die CSRFTokenValidator.php verfügbar ist. Jedoch Status deaktiviert ist. Bedenklich oder nicht?
Ups, das ist hier auch so!
Der zeigt ja nur an, dass die Datei verändert wurde, aber das ist ja auch so 
Der zeigt ja nur an, dass die Datei verändert wurde, aber das ist ja auch so
Wir sehen da erstmal nur ein rotes Kreuz ohne Info und erschrecken uns. Wenn es nur der Hinweis auf eine Änderung ist, bin ich ja beruhigt.
Normalerweise löcht oder verliert man einen Cookie doch nicht, wenn man den nicht mutwillig löscht oder? Kann man anhand der Fehlermeldung nur prüfen ob der Cookie gelöscht wurde und wenn ja statt “ups, es ist ein Fehler…” eine Info ausgibt das der User die Seite neu laden soll?
Normalerweise löcht oder verliert man einen Cookie doch nicht, wenn man den nicht mutwillig löscht oder? Kann man anhand der Fehlermeldung nur prüfen ob der Cookie gelöscht wurde und wenn ja statt „ups, es ist ein Fehler…“ eine Info ausgibt das der User die Seite neu laden soll?
oder noch besser ein automatisches Neuladen erzwingen, ganz ohne Fehlermeldung?
Normalerweise löcht oder verliert man einen Cookie doch nicht, wenn man den nicht mutwillig löscht oder? Kann man anhand der Fehlermeldung nur prüfen ob der Cookie gelöscht wurde und wenn ja statt „ups, es ist ein Fehler…“ eine Info ausgibt das der User die Seite neu laden soll?
Vielleicht „normalerweise“…
Ein neuer Besucher würde mit dem Fehler jedenfalls immer einen 2. Verusch brauchen.
@raschu schrieb:
da ich die CSRF Token Fehlermeldungen grundsätzlich für sinnvoll halte, hätte ich mal eine Frage zur Standard-Fehlermeldung „Upps, …“:
kann ich eine spezielle Fehlerseite für die CSRF Token Fehlermeldung anzeigen lassen? Bei uns tritt der Fehler auf, wenn längere Zeit Inaktivität herrschte und dann der Kunde „weiter machen“ will (wurde in diesem Thread schon beschrieben). Deshalb hätte ich gerne eine spezielle Fehlerseite z.B. „Session abgelaufen - bitte Seite neu laden“ oder so ähnlich. Dann weiß der Nutzer worum es geht und wird nicht durch eine allgemeine Fehlermeldung verschreckt. Andere Websites machen das auch so, wenn man längere Zeit inaktiv ist.
Kann mir jemand sagen, wo ich das ändern kann?
Das mit der Fehlermeldung hatte ich weiter oben auch schon mal angesprochen.
Der Token-Fehler wird ja nicht aus Spaß erzeugt - wenn er vom System erzeugt wird, sollte das dann auch dem Kunden gegenüber kommuniziert werden.
Das sind ja alles separate Tasks.
Erstmal schauen wir mal, dass wir das Problem in den Griff geben. Im zweiten Schritt wird dann erstmal geschaut, ob man die Meldung noch weiter anpassen kann.
Generell könnt ihr aber die Upps… Meldung auch als Textbaustein anpassen. Soetwas wie „Bitte versuchen Sie den Vorgang nach einem Reload der Seite erneut“ (oder vergleichbares) kann man da ja jederzeit reinschreiben.
Ich bin ja Anwender und kein Programmierer - aber wenn ich das bisher richtig verstehe, soll der CSRF-Token doch vor unerwünschten Angriffen bzw. Aktionen schützen. Wenn ich die Kommentare hier im Forum richtig deute, entstehen diese Fehlermeldungen ja immer dann, wenn etwas mit dem Token nicht stimmt. Bei uns z.B. tritt der Fehler auf, wenn tatsächlich ein Bot auf die Newsletter-Anmeldung zugriff - da schützt der Token wie er es soll. Wir haben die IP gesperrt und gut war’s. Dann tritt der Fehler noch sporadisch auf, wenn anscheinend die Session abgelaufen ist, sprich der User war aus irgendwelchen Gründen eine zeitlang inaktiv und füllt dann das Formular - egal welche Post-Aktion - weiter aus. Fehlermeldung ist auch hier richtig, wenn auch ärgerlich.
Und für diese Fälle - Session abgelaufen - wäre die separate Fehlermeldung doch sinnvoll. Die “Upps…”-Standardmeldung kann ja auch in anderen Fällen erzeugt werden (hoffentlich nicht), weshalb der Text dafür dann ja wieder passt. Deshalb möchte ich den Textbaustein eigentlich gar nicht verändern, sondern eine extra spezielle Fehlermeldung für den speziellen Token-Fehler.
In den anderen Fällen, wo evtl. überhaupt keine Anmeldungen oder Post-Aktionen in Shopware mehr möglich sind (gibt es die überhaupt?) liegt natürlich der Fehlerauslöser wahrscheinlich woanders, aber das versucht Ihr ja zu lösen…
Übrigend bekam ich den Fehler bzgl. BE-Login heute Vormittag wieder:
Shopware\Components\CSRFTokenValidationException: The provided CSRF-Token is invalid. If you’re sure that the request to path “/backend/Login?file=app&no-cache=1489247157” 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}
Bis zu dem Zeitpunt hatte ich mich aber noch nicht ein einziges Mal dort angemeldet.
Allerdings lief genau zu der Zeit ein File-Backup.
Grüße, Ralph
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)
Habt Ihr den Fix zufällig auf shopwaredemo.de eingebaut? Falls ja, gerade hatte ich wieder den Fehler als ich auf Newsletter gedrückt habe 
Theoretisch kann ich aber den CSRF Schutz auch umgehen. Mit lynx ne session erstellt und die Daten an Curl übergeben:
curl 'http://www.shopwaredemo.de/newsletter' -H 'Cookie: PHPSESSID=1qtod182d45v9l2ocpmhikuc62; __utmt=1;__ csrf_token-1=K64PCgN7QqqIAPOsDKn8INc4Q5uwEP; x-ua-device=desktop; __utma=262308046.1400214471.1489420800.1489420800.1489424022.2;__ utmb=262308046.3.10.1489424022; __utmc=262308046;__ utmz=262308046.1489420800.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _ga=GA1.2.1400214471.1489420800; session-1=f1c6b60d3104386313b138f7ae9c5caf4cba856b8de8a0a46cb17a11357c9c62' -H 'Origin: http://www.shopwaredemo.de' -H 'Accept-Encoding: gzip, deflate' -H 'Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Referer: http://www.shopwaredemo.de/newsletter' -H 'Connection: keep-alive' --data 'subscribeToNewsletter=1&newsletter=asd%40asd.de&salutation=&firstname=&lastname=&street=&zipcode=&city=&Speichern=&__csrf_token=K64PCgN7QqqIAPOsDKn8INc4Q5uwEP' --compressed
Als Antwort bekomme ich über die Console: “Vielen Dank. Wir haben Ihre Adresse eingetragen.”
Mir wird noch nicht ganz klar wofür der Schutz nun genau da ist. Hier wird übrigens noch nicht mal geprüft ob der CSRF Token / Session auch zur IP passt.
Ich bin klar dafür, dass erweiterte Captcha Eingaben wie reCAPTCHA bei Formularen eingebaut werden, oder eine Funktion zur verfügung gestellt wird, damit man diese Schutzmaßnamen hinzufügen kann.
Oder auch jetzt neu: https://www.google.com/recaptcha/intro/comingsoon/invisible.html invisible reCAPTCHA
Invisible reCAPTCHA | Google Developers
P.S.: Die Vorlage habe ich aus google chrome 
Habt Ihr den Fix zufällig auf shopwaredemo.de eingebaut? Falls ja, gerade hatte ich wieder den Fehler als ich auf Newsletter gedrückt habe
Mir wird noch nicht ganz klar wofür der Schutz nun genau da ist. Hier wird übrigens noch nicht mal geprüft ob der CSRF Token / Session auch zur IP passt.
Moin Rico.
Der Fix ist auch auf Shopwaredemo eingebaut. Aktuell kann ich das auch nicht nachvollziehen, grundsätzlich kommt der Fehler nun wenn Du entweder Deinen Cookie verlierst oder veränderst oder etwas verhindert, dass Javascript den Token ins Formular überträgt.
CSRF Protection schützt nicht dagegen, dass man automatisiert Formulare füllen kann. Es geht darum, dass eine dritte Seite nicht die Session eines Kunden übernehmen kann.
Ich habe im Zuge der ganzen Geschichte eine Testseite gebaut, mit der Folgendes möglich ist, wenn man den Schutz ausschaltet:
Genau dagegen schützt CSRF Protection, gegen nichts anderes. Captcha ist ein anderes Themengebiet, da lohnt sich für Dich ein Blick in den 5.3er Branch auf github. 
Falls Englisch kein Problem für Dich ist, ist der folgende Artikel auch interessant: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
Ich hatte den Fehler mit ublock origin nachstellen können, sofern das tatsächlich zusammenhing - kann ich auf shopwaredemo.de jetzt nicht mehr nachstellen. Danke, dass das Thema mal intensiv angesehen wurde.
Vielen Dank für die tollen Infos. Das mit der 5.3er Version hört sich sehr interessant an
Zum Thema shopwaredemo.de! Dort bin ich ganz normal drauf gegangen und dann habe ich auf Newsletter gedrückt. Normalerweise sollte der erste Besuch doch schon alles bereinigen so dass es dort nicht zu einem Fehler kommt.
Also der Patch hat zumindest dann nichts gebracht. Ich werde aber nochmal weiter testen. Da der Fehler nicht einfach so reproduzierbar ist, gehe ich davon aus, dass es auch mit dem Shopcache zusammenhängt.
Wenn mir dort nochmal ein Fehler angezeigt wird, werde ich Ihn hier posten. Mit Zeitstempel, falls das eine Hilfe ist.