Guten Tag,
ich habe mal eine Frage. Gibt es eine Möglichkeit, mehrere Newsletter-Empfänger auf einmal zu löschen? Wir hatten leider einen Bot Angriff auf unsere Anmeldung und haben nun Massenhaft Einträge, die wieder rausmüssen. Ich hatte schon mal nach einer Erweiterung für eine Massenbearbeitung von Newsletter-Empfänger gesucht, aber bedauerlicherweise nichts gefunden.
Ich hoffe das mir jemand einen Tipp geben kann.
Beste Grüße
Wir haben haargenau das gleiche Problem, Bot Angriff und 67.000 Newsletterempfänger.
Schaut sich das Forum hier keiner an oder was ist los?
Einfach über die Datenbank löschen. Eine Massenverarbeitung bei 67.000 Einträgen bringt dir auch nicht mehr viel. Das sind nach wie vor 670 Klicks bei 100 Einträgen.
Ich habe mir das schon fast gedacht, dass es nur über die Datenbank funktionieren wird. Dann werde ich mir das mal anschauen. Ich hoffe, man kommt mit der Erweiterung " Adminer für das Admin" an die Einträge ran.
Hallo, habe akut das selbe Problem. Und würde es gerne abstellen da ich auch tausende Mails bekomme.
Pro Sekunde habe ich ca. 5 neue Anmeldungen.
Wie konntet Ihr es stoppen?
Hast du in den Stammdaten relativ weit unten ein Captcha aktiviert?
„einfaches Captcha“ War die Antwort. Hatte die Agentur bereits genau in dem Moment eingestellt. Vielen vielen Dank für deine Antwort. Hätte ich es selbst gemacht wäre es günstiger geworden …
Erstmal gelöst!
Jetzt muss ich nur die Fake Empfänger entfernen.
Kann ich da mit Export / Import arbeiten?
Schön, wenn das Problem gelöst wurde. Ich denke, dass das Entfernen der Einträge am schnellsten über die Datenbank geht.
Gleiches Problem eben bei mir. Aber andere Frage: warum sind Links im Namen erlaubt? Jemand eine Lösung wie man das schnell und einfach unterbindet?
Leider geht das nicht per Export / Import, aber die Erweiterung " Adminer für das Admin" ist sehr gut. Damit habe ich die Einträge in 10min raus gehabt.
Ja, diese Frage habe ich mir auch gestellt. Ich finde es schon seltsam das Shopware HTML Elemente im Formularfeld zulässt.
@Nico_Ch deine Aussage hat mit der technischen Realität leider nicht viel zu tun. Damit andere das nicht glauben, meine Antwort hierzu:
Das ist zum einen keine Sicherheitslücke, da lediglich Spam, im Rahmen des Erlaubten – nicht gleichzusetzen mit dem Gewünschtem – eingetragen werden kann.
Shopware hat einen einfachen Honeyport implementiert. Dieser kann deaktiviert werden. Ob das hier der Fall ist, wer weiß.
Unabhängig davon werden Bots über die Jahre besser, einfache Honeypots und Captchas halten diese nicht mehr ab.
Heute ist es schlechthin ein abwägen von Bots ausschließen und Kunden vertreiben. Die richtige Mischung muss jeder selbst finden.
Mit Sicherheitslücke hat das aber rein gar nichts zu tun!
Ich habe meine Aussage geändert. Ich hoffe doch zu deiner Zufriedenheit 
Sind leider auch Opfer davon geworden, Obwohl ein Honeypot aktiviert war. Sind nun auf Recpatcha V3 umgestiegen.
ich hab jetzt alles aus der datenbankgeputzt.
bin aber schon etwas enttäuscht, dass ich diesem prozess per curl alles(!) als emailadresse zum fraß vorwerfen kann. captcha ist jetzt aktiv und regelt hoffentlich.
aber man könnte urls in mailadressen doch vielleicht unterbinden.
Das Problem ist, dass die standardisierte Definition von E-Mail-Adressen nicht dem „allgemeinen“ Verständnis entspricht. Wenn man nach dem Standard validiert, dann geht da so viel durch, was „man“ vermutlich nicht als E-Mail verstehen würde.
Daher müsstest du nach deinen eigenen Regeln ein E-Mail-Filter implementieren.
Und klar, per CURL geht so einiges, da es alle JavaScript-Maßnahmen umgeht.
Die Frage, die ich mir stelle ist:
Wenn ich da eine Validierung hab, die ich per HTML/JS streng setze und die dann in php nicht auf die gleichen Kriterien scharf ist.
Hab ich dann ein Security-Thema aus Bequemlichkeit an den Client übergeben, das doch am Server eigentlich mindestens gleich streng sein sollte?
Also der Fix wäre ja, dass der eingesetzte Endpunkt, der die Daten entgegennimmt sich eben nicht durch CURL verarschen lässt,
sondern mindestens die selben Kriterien ansetzt, wie sein clientseitiger Kollege.
mal so grds. Curl kann weder etwas noch jemanden verarschen. Ob Du den Request als „normalen“ Post/Get absetzt oder dafür z.B. Curl verwendest ist egal. Schwachpunkt ist an dieser Stelle tatsächlich der „Endpunkt“, welcher offensichtlich bereits verifizierte und validierte Daten erwartet. Beides einem Client zu überlassen ist, diplomatisch formuliert, wenig optimal. Insofern ist es sicher richtig und zu empfehlen, den „Newsletter-Dienst“ zu extenden und um eine syntaktische Validierung einen DNS- und DNS-Reverse-Abgleich sowie einen MX-Check zu erweitern. Sollte insgesamt nicht so aufwändig sein.
Die Mail-Adresse prüfen macht nur begrenzt Sinn. Die Spammer wollen ja von der OptIn-Mail profitieren und setzen darauf, dass die Nachricht an gültige Adressen geht; denn die Empfänger sollen ja dann auf die eingeschleusten Links klicken.
Sinnvoller wäre es, wie oben schon geschrieben, „Badwords“ wie z.B. „http:“ oder „https:“ in den verbundenen Formularfeldern zu verbieten.
Ich habe mich selbst auch schon an einem Plugin versucht, aber dafür hab ich zu wenig Ahnung.
Ein Problem dabei: Es gibt ein Event „newsletterRegister“ (oder so ähnlich) - das wird aber erst ausgelöst, nachdem der Eintrag schon in der Datenbank gelandet ist und die Mail verschickt wurde.
Genau das - DB-Eintrag und Versand der Mail - soll aber ja gerade verhindert werden.
Es wär ja schon für Opfer von Bot-Attacken hilfreich, wenn man wenigstens im Backend z.B. anhand der Filter Massen-Löschungen von Einträgen durchführen könnte, z.B. alle „Wartet auf Aktivierung“, die älter sind als 2 Tage oder so. Aber nö…
