CSRF Token Problem mit Adblocker

Auf http://www.shopwaredemo.de/ lässt sich ein CSRF Fehler provozieren in Firefox mit aktiviertem ublock origin. Cookies löschen, Seite aufrufen, klick auf „Mein Konto“, klick auf „Anmelden“.
Kann das jemand bestätigen? Ggf. auch mit anderen Adblockern / Browsern?

Um das noch zu betonen, grundsätzlich funktioniert der CSRF Schutz mit ublock origin. Wenn man nach dem Fehler beispielsweise auf das Logo klickt, dann über die Homepage wieder das Anmeldeformular klickt und absendet erscheint KEIN Fehler.

So:
1) Firefox 47 und ublock origin
2) Die Startseite von meinem Shop aufgerufen - durchgängig SSL
3) Cookies und Cache gelöscht
4) auf „mein Account“ geklickt
5) eingeloggt
Keine Probleme - auch beim Tausch von 2 und 3

Gleiches mit www.shopwaredemo.de => keine Probleme

Ich tippe da eher auf sowas wie Internetsecurity ala gdata oder kasper

Danke. Das lässt hoffen. AV Kram läuft hier nicht, muss irgendwas anderes sein im Zusammenspiel mit ublock.

Sind beim uBlock nur Standard Listen Aktiv?

Wie ist es mit Firefox: sind die Standardeinstellung in about:config unverändert?

Bei mir ist „Https Everywhere“ schuld, nicht uBlock.

Tauchen diese Probleme erst seit der 5.2 Version auf, oder gab es die auch schon bei 5.1?

Wenn nicht Blocker oder AV, gehen wir mal eine Ebene tiefer:
Win7 64 - obiges Verhalten nicht mit Chrome und Firefox (beide ublock origin, Chrome bei Bedarf noch Adblock Plus und Ghostery) reproduzierbar

In der 5.1 gabs doch noch keine csrf protection?

Hier läuft OSX. Teste das heute abend mal unter Windows 10.

Ich kann den Fehler auch auf meinem Windows 10 Rechner nachstellen, Firefox mit ublock, auf shopwaredemo.de. Kann das tatsächlich niemand bestätigen?

csrf cookie ist gesetzt und wird beim request mitgeschickt. als antwort kommt ein “invalidate-xcsrf-token” cookie.

chrome mit ublock ebenso

OK:

  1. Chrome mit uBlock cookies von www.shopwaredemo.de entfernt
  2. wie im ersten Beitrag vorgegangen
  3. *UPS* bekommen !

Ohne uBlock geht es durch
Komisch, muss aber auch eine Kombination aus *Mysterium* - Browser - Domain & u.A. uBlock sein

Nur bei mir im Shop kommt der UPS dann nicht.

@sonic schrieb:

OK:

  1. Chrome mit uBlock cookies von www.shopwaredemo.de entfernt
  2. wie im ersten Beitrag vorgegangen
  3. *UPS* bekommen !

aktuell läuft  www.shopwaredemo.de ohne SSL, war das schon immer so?

unsere shops laufen komplett auf ssl, das kann nicht die ursache sein

@senor_dingdong schrieb:

unsere shops laufen komplett auf ssl, das kann nicht die ursache sein

ich hatte vermutet der Übergang von http nach https könnte Probleme verursachen. Da wäre evtl. eine mögliche Lösung den Shop strickt über https auszuliefern. 

Ich habe jetzt kreuz und quer rumgestestet, ich kann den Fehler auf www.shopwaredemo.de auch mit uBlock nicht 100% - eher 99% - reproduzieren.
Ohne uBlock schaffe ich es nicht, auf dem obigen Weg den *UPS* zu produzieren.
Und warum bekomme ich es auch mit uBlock auf einer anderen Seite nicht reproduziert?

Was mir auffällt: Rufe ich www.shopwaredemo.de erstmalig auf, kommt dieses Overlay mit dem Hinweis „Backend *blabla* zurücksetzen *blabla*“
Wo merkt sich der Demoshop, dass ich die Seite erstmals aufgerufen habe? Selbst wenn ich alle Kekse zu www.shopwaredemo.de lösche, kommt das Overlay erst wieder, wenn ich den Browser einmal ganz geschlossen habe. Hier werden doch noch irgendwo Dritt-Cookies gesetzt?!?

Das Overlay steckt im Session Storage, “demoOverlay-hide”.

[OT]
Ist wohl #Neuland für mich :slight_smile:
Ich habe diese Daten:


Wenn ich die alle lösche, dürfte es doch keine Session mehr geben mit diesen Daten ?!?!?

Auf deiner Mallorca Seite kann ich es auch nicht nachstellen. Auf den ersten Blick auffallend ist nur piwik statt ga.

Jo. Piwik ist Lokal
*Hmm* - wäre krude - aber vielleicht sorgt das Ausfiltern vom Piwik uBlock daran, Cookies zu vermurksen *Ich stell es mal grade ab*

 

[Edit]
Nein, auch mit Piwik „aus“ lässt sich der Fehler grad nicht sehen. Wäre auch sehr krude gewesen :wink: