Und jedes Mal ein komplettes Backup in der Frequenz, wie die Backups teilweise kommen - schafft und macht das Jeder?
Jeder sicher nicht. Aber wir machen automatisiert jede Nacht ein Full-Backup und speichern das auf einen externen Daten-Server. Und das macht auch definitiv Sinn.
@baseline-toner: Ich muss dir zu 100% zustimmen.
Statt massenhaft die entsprechenden Tickets im Issue-Tracker zu voten um Shopware ganz deutlich die Dringlichkeit zu verdeutlichen, wird einfach ein Sicherheitsfeature abgestellt.
Absolute Zustimmung. Hast du vielleicht ein Paar Links zu entsprechenden Tickets. Hab schon einiges gevotet, aber vielleicht gibts noch mehr passende.
Irgendwo müsst Ihr auch mal die Kirche im Dorf lassen.
Wenn einer dauernd Probleme mit CSRF hat, sollte man der Sache individuell auf den Grund gehen. Pauschal “geht nicht” ist einfach nicht wahr.
Und wenn gar nichts hilft, einfach abschalten.
Wer sagt, er wisse nicht, wieviele Kunden ggf. abgesprungen sind, hat ganz andere Probleme: Er kontrolliert seine Systeme einfach nicht, denn im Backend kann man - wenn sie eh nicht per EMail eintrudeln - jeden Fehler im Log einsehen.
Und nicht jeder Fehler ist ein Fehler. Bei mir z.B. hat die Sperre einer IP - “85.195.84.13” von velia.net geholfen, für Ruhe zu sorgen - der Spambot schert sich nämlich nicht um die Token. Ebenso, wie sich die abuse Abteilung von velia.net nicht um Beschwerden schert…
Shopware kann die Sache auch nur dann genau untersuchen, wenn konkrete Daten vorliegen - SW Version, PHP-Version - Apache, nginx - apache-mod oder CGI, geblockte Cookies.
Es gibt nur eine pauschale Antwort auf pauschal “geht nicht”: ABSCHALTEN
Es gibt nur eine pauschale Antwort auf pauschal „geht nicht“: ABSCHALTEN
Das ist quatsch! Wenn ein paar User Probleme mit dem Login haben, schaltet man auch nicht die Authentifizierung ab. Es mag sein dass, das Problem individuell unter bestimmten Shop-Konfigurationen auftritt oder auch Shopware hier generell Probleme hat. Die Lösung muss sein den Fehler zu suchen und nicht die Symptome zu unterdrücken.
Wer sagt, er wisse nicht, wieviele Kunden ggf. abgesprungen sind, hat ganz andere Probleme: Er kontrolliert seine Systeme einfach nicht, denn im Backend kann man - wenn sie eh nicht per EMail eintrudeln - jeden Fehler im Log einsehen.
So ein quatsch!
Wieviel % der Betreiber können die Fehlermeldungen zum CSRF-Token so deuten?
Einen Eintrag als „Absprung“ gibt es schließlich nicht, wenn ein potentieller Kunde nach dem ersten Registrierungs- oder Login-Versuch sofort das Weite sucht.
Außerdem kann man auch nicht alle Shopbetreiber bzgl. Know how über einen Kamm scheren.
Wir haben uns dieses Thema auch vemehrt im Rahmen des SW-Supportes angehen. Es stimmt, dass der Login eine Stelle ist, wo es vermehrt zu diesen Meldungen kommt, i.d.R. ist es aber auch die erste Stelle wo ein Kunde einen POST-Request absendet, also auch die erste Stelle, wo der Fehler überhaupt auftreten kann. Auf den individuellen Kundensystemen war ziemlich häufig ein Plugin Schuld - und nicht ein eindeutiges, sondern zahlreiche.
Darüber hinaus gibt es natürlich auch hunderte andere Gründe, warum es zu einer solchen Meldung kommt und die Meldung dann auch vollkommen valide ist:
Natürlich kann man hier den Schutz als “schnelle Lösung” abschalten, damit man erstmal Ruhe hat. Aber dann sollte man in einer Testumgebung der Ursache auf den Grund gehen. Ja, hier im Forum haben viele Kunden das Problem - aber da muss man einfach individuell dran gehen.
Wenn es einen eindeutigen Klickweg gibt, dann gerne in ein Issue gießen.
Das Problem schauen wir uns ständig auf Kundensystemen an im Rahmen des supportes und genauso individuell sind die Ursachen.
Wer sagt, er wisse nicht, wieviele Kunden ggf. abgesprungen sind, hat ganz andere Probleme: Er kontrolliert seine Systeme einfach nicht, denn im Backend kann man - wenn sie eh nicht per EMail eintrudeln - jeden Fehler im Log einsehen.
So ein quatsch!
Wieviel % der Betreiber können die Fehlermeldungen zum CSRF-Token so deuten?
Einen Eintrag als „Absprung“ gibt es schließlich nicht, wenn ein potentieller Kunde nach dem ersten Registrierungs- oder Login-Versuch sofort das Weite sucht.
Außerdem kann man auch nicht alle Shopbetreiber bzgl. Know how über einen Kamm scheren.
wessen Problem ist es dann wenn er es nicht deuten kann? Die Fehler werden jedenfalls alle geloggt. Es ist also möglich sich über das Ausmaß ein Bild zu machen. Setz mal einen Spezialisten dran. Ferrari ist auch nicht schuld, wenn Du es nicht fahren kannst.
Schaltet man CSRF ab, so hat man den Zustand wie vor 5.2. Kriegt man es sauber zum Laufen ist man sicherer unterwegs. Ich kenne 3 häufigsten Ursachen, auch in dieser Reihenfolge nach der Auftrittshäufigkeit:
wessen Problem ist es dann wenn er es nicht deuten kann? Die Fehler werden jedenfalls alle geloggt. Es ist also möglich sich über das Ausmaß ein Bild zu machen. Setz mal einen Spezialisten dran. Ferrari ist auch nicht schuld, wenn Du es nicht fahren kannst.
- Bots (zur Hölle mit den)
- abgelaufene Sessions (eine Lösung muss dringend her)
- inkompatible Plugins
Ich dachte bisher dieses Forum soll/kann auch denen ein bisschen helfen, die nicht so viel Ahnung haben - zähle mich gerne dazu.
Ich wüsste jetzt z.b. weder wie (wahrscheinlich per ip-adresse in der .htaccess), noch welche ich ausperren sollte.
Gibt es dazu Quellen?
Zunächst würde ich die Shopwarelogs mit den Serverlogs vergleichen. Da siehst Du schon, ob es ggf. ein Bot war - in wenigen Sekunden mehrere Zugriffe? Da siehst Du auch in den Serverlogs, ob die IP vorher im Artikel war, etwas in den Warenkorb gelegt hat etc. Du könntest auch lokal Piwik installieren - sofern der Kunde keinen Adblocker etc. hat, kannst Du auch die Historie verfolgen. Wenn es z.B. ein Bot ist, kann Shopware schlicht nichts degagen unternehmen. „POST“ ohne Token soll je gerade rausgefiltert werden. Ist es z.B: immer die gleiche IP (s.o.) wäre in der Tat ein Eintrag in die .htaccess ein erster Schritt, wenn es nicht zuviele werden. Wenn Du eine verdächtige IP gefunden hast, mal nach „whois ip“ googlen, ggf. ist diese auf Abuse-Seiten schon bekannt.
Bsp. an obiger IP für .htaccess
order allow,deny
deny from 85.195.84.13
allow from all
Es ist halt schwer, für „geht bei mir nicht“ eine allgemeine Lösung zu liefern.
Bei POST durch Bots kann man nichts machen.
Was mich z.B. interessieren würde, ob SSL nur im Checkout oder auf der ganzen Seite verwendet wird, ist gar ein SSL-Proxy im Einsatz? Das könnten z.B: Problemstellen sein. Hier hilft wirklich nur eine Flut an Informationen, um einheitliche Fehlerquellen ausfindig machen zu können.
Zu deny z.B.: Deny visitors by IP address - Apache .htaccess Guide, Tutorials & Examples
Was mich z.B. interessieren würde, ob SSL nur im Checkout oder auf der ganzen Seite verwendet wird, ist gar ein SSL-Proxy im Einsatz? Das könnten z.B: Problemstellen sein. Hier hilft wirklich nur eine Flut an Informationen, um einheitliche Fehlerquellen ausfindig machen zu können.
Danke!
Proxy nein, SSL im kompletten Shop ja. Ist das für Dich ein bekannter Verursacher?
Konkret: Beim Hoster ist “SSL erzwingen” aktiviert und in den Shopeinstellungen ist “Überall SSL verwenden” ausgewählt.
Nachtrag: Und wie überschaubar sind die Folgen, SSL nur auf die “relevanten” Bereiche umzustellen?
z.b. Google - der Shop ist noch recht jung, aber gut 340 Seiten sind bereits mit https beginnend indexiert.