Neu SPAM durch die Eingabeseite bei den Kundendaten

[css-umsetzung]

Danke, ich versuche es mal mit der IP sperren. Ist ja interessanterweise eine deutsche IP.

Ja es waren auch deutsche IP Adressen dabei, aber es sind unterschiedliche auch aus anderen Ländern, daher macht eine IP Sperre nicht wirklich Sinn.

 

[Shop-Schmied]

Ich will Euch ja nicht auch noch vollspammen ... aber mir ist gerade gestern wieder eine dreiste Kopie von unseren Angeboten (ganze Kategorieinhalte mit Bildern und teilweise unserem Namen drunter) aufgefallen, die ich auch entsprechend gemeldet habe. Trotzdem frage ich mich immer wieder was das ganze soll .

 

[lilfoot.software]

Moin liebe Nutzer der SpamProtector-Plugins, es ist geschafft. Die Updates der Plugins wurden soeben veröffentlicht. Folgendes wurde nun sowohl für die Lite- als auch für die Kauf-Version umgesetzt:

• Optimierung der BadBot- und BadIP-Erkennung durch Verbesserung des Cachings der Dateien
• BotFallen für TextInput und Checkbox werden nun automatisch um einen zufälligen Code ergänzt um eine Erkennung per Skript zu erschweren
• Neue BotFallen hinzugefügt:
  • Überprüfung des Referers (ist der Referer leer oder enthält nicht die Shop-Domain schnappt die Falle zu)
  • Überprüfung der Zeit bis zum Absenden des Formulars (im Standard sind 5 Sekunden gesetzt, wird das Formular schneller versendet schnappt die Falle zu, der Zeitwert kann im Millisekunden-Bereich gesetzt werden: Standard = 5000)

Ich hoffe damit können wir den Spammern erstmal wieder ein wenig das Wasser abgraben.

Wie schon angeteasert laufen aktuell Tests mit der Erkennung von Spam per KI. Sobald hier ein zuverlässiger Stand erreicht ist der für die Produktion geeignet ist wird diese Funktion ebenfalls Einzug in die Plugins finden

Ich wünsche euch ein Spam-freies Wochenende. Sollte euch etwas auffallen scheut euch nicht mich per Mail zu kontaktieren

 

[wawi-dl]

VIELEN DANK, gleich mal Update gezogen und das Wochenende abwarten.

Gibt es keine Kaffeekasse?

 

[Entenfurz]

Moin liebe Nutzer der SpamProtector-Plugins, es ist geschafft. Die Updates der Plugins wurden soeben veröffentlicht. Folgendes wurde nun sowohl für die Lite- als auch für die Kauf-Version umgesetzt:

• Optimierung der BadBot- und BadIP-Erkennung durch Verbesserung des Cachings der Dateien
• BotFallen für TextInput und Checkbox werden nun automatisch um einen zufälligen Code ergänzt um eine Erkennung per Skript zu erschweren
• Neue BotFallen hinzugefügt:
  • Überprüfung des Referers (ist der Referer leer oder enthält nicht die Shop-Domain schnappt die Falle zu)
  • Überprüfung der Zeit bis zum Absenden des Formulars (im Standard sind 5 Sekunden gesetzt, wird das Formular schneller versendet schnappt die Falle zu, der Zeitwert kann im Millisekunden-Bereich gesetzt werden: Standard = 5000)

Ich hoffe damit können wir den Spammern erstmal wieder ein wenig das Wasser abgraben.

Wie schon angeteasert laufen aktuell Tests mit der Erkennung von Spam per KI. Sobald hier ein zuverlässiger Stand erreicht ist der für die Produktion geeignet ist wird diese Funktion ebenfalls Einzug in die Plugins finden

Ich wünsche euch ein Spam-freies Wochenende. Sollte euch etwas auffallen scheut euch nicht mich per Mail zu kontaktieren

Vielen Dank für die Mühe.
War aber wohl leider nichts. 5 Minuten nach Installation kam wieder eine SPAM durchs Anmeldeformular an.

 

[lilfoot.software]

@Entenfurz Meld dich gerne mal per Mail bei mir (support@lilfoot.software). Vielleicht können wir bei dir die Tage ja auch mal ein Logging einbauen um zu sehen was da genau passiert. Aufgeben ist keine Option

 

[wawi-dl]

wir hatten auch direkt 4 danach ich warte mal das Wochenende ab

komisch ist, es ist nicht jeder Shop betroffen von uns, nur 1 von 3

 

[lilfoot.software]

@wawi-dl Meld dich auch gerne damit wir bei dir mal loggen können. Jede Auswertung zeigt uns das Verhalten der Spammer deutlicher und wir können (hoffentlich) etwas dagegen unternehmen

 

[Entenfurz]

Bei uns hat folgendes kurzfristig geholfen und seit da an haben wir keine Spamanmeldungen mehr:

URL des Registrationsformulars von /Registrieren auf irgend eine beliebige andere URL ändern. Es scheint als grast der Bot einfach alle Shops auf /Registrieren ab und füllt die Formulare aus.

Die Spamanmeldungen kamen immer über folgende IP rein: 80.71.157.31. -> evtl sperren oder gleich ganzer IP Bereich sperren.

Hallo
Wie kann man das ändern? Die Seite registrierung ist ja als feste Spezialseite hinterlegt und ich kann im Backend keine andere URL angeben.

 

[MKis84]

Du kannst die URL im Shop Backend ändern. Eigene Inhalte -> Seiten -> (Bei mir heisst die Seite Anmelden und ist im Kopfbereich). Dann nach unten scrollen und gewünschte URL bei "Name für Suchmaschinen" eintragen.

 

[Entenfurz]

Du kannst die URL im Shop Backend ändern. Eigene Inhalte -> Seiten -> (Bei mir heisst die Seite Anmelden und ist im Kopfbereich). Dann nach unten scrollen und gewünschte URL bei "Name für Suchmaschinen" eintragen.

Danke, aber damit ändert man ja nur die Überschrift für die Suchmaschine, bringt bei diesem Problem nichts. Ich suche eine Möglichkeit die URL die aufgerufen wird zu verändern, also zB statt registrieren.php regischrtrien.php, wenn der Kunde auf der Seite auf Registrieren aufruft.

 

[MKis84]

Bei mir war das Registrationsformular standardmässig unter /Registrieren erreichbar. Nach Änderung dieses Felds war auch die URL entsprechend. Was hast du für eine Shopversion?

 

[Entenfurz]

Bei mir war das Registrationsformular standardmässig unter /Registrieren erreichbar. Nach Änderung dieses Felds war auch die URL entsprechend. Was hast du für eine Shopversion?

Habe es auch ausprobiert, funktioniert tatsächlich. Die Beschriftung des Feldes mit "Name für Suchmaschinen" ist da dann irgendwie absolut idiotisch und führt in die Irre.

 

[martinwolf]

Habe es auch ausprobiert, funktioniert tatsächlich. Die Beschriftung des Feldes mit "Name für Suchmaschinen" ist da dann irgendwie absolut idiotisch und führt in die Irre.

Funktioniert solange bis die Bots sich die Sitemap anschauen, dann finden Sie diese URL auch wieder. Machen wir uns doch nichts vor, JTL muss hier die Eingabe serverseitig validieren. Alles andere ist doch nur eine temporäre Lösung,

 

[Greenman]

Funktioniert solange bis die Bots sich die Sitemap anschauen, dann finden Sie diese URL auch wieder. Machen wir uns doch nichts vor, JTL muss hier die Eingabe serverseitig validieren. Alles andere ist doch nur eine temporäre Lösung,

Denke mal, so wie ich die Sache sehe, dass auch JTL seinen Teil dazu betragen muss, um dieses Problem zu lösen. css-umsetzung und lillfoot.software machen eine gute und notwendige Arbeit. Seit dem Update des SpamProtectors hat es die ungesunden Besucher minimiert. Den Anmeldespam bekomme ich aber trotzdem weiterhin.

Es wäre schon sinnvoll, wenn JTL zumindest an der Wurzel dieses Problems, dem Formular, einen Riegel vorschiebt. Da bin ich auch schon bei martinwolf. Wie das technisch umsetzbar ist weiß ich nicht. Aber logisch hört sich das schon an.

 

[sjk]

Machen wir uns doch nichts vor, JTL muss hier die Eingabe serverseitig validieren.

Genau dazu hab ich kürzlich ein Ticket erstellt und wurde in der ersten Antwort auf das Recaptcha Plugin verwiesen.

JTL ist da wahrscheinlich zurückhaltend weil, je nach Umfang der Validierung, sicherlich edge cases auftreten würden. Es wäre aber schon viel damit geschafft, Unicode-Zeichen und URLs (außer im Website-Feld) nicht zuzulassen. Zumindest den aktuellen Anmeldespam würde das verhindern.

Zusätzlich könnte man Shopbetreibern ein Regexfeld zur Verfügung stellen. Damit könnte man sich auf eigene Verantwortung ad hoc selbst helfen.

 

[css-umsetzung]

Zusätzlich könnte man Shopbetreibern ein Regexfeld zur Verfügung stellen. Damit könnte man sich auf eigene Verantwortung ad hoc selbst helfen.

Lieber nicht, es gibt nicht viele Shop Besitzer die wüssten was sie damit anfangen sollen, am Ende fragen sie irgendeine KI und wundern sich das keine Bestellungen mehr reinkommen und belasten den JTL Support.

JTL hat bereits eigene Vorkehrungen, aber eben auch extra Hooks erstellt, die dann von Plugins,
die schneller auf Veränderungen reagieren können als ein komplexes Shopsystem, genutzt werden können.

Von daher ist es aus meiner Sicht besser, auf solche Plugins zu setzen.

 

[Greenman]

JTL hat bereits eigene Vorkehrungen, aber eben auch extra Hooks erstellt, die dann von Plugins,
die schneller auf Veränderungen reagieren können als ein komplexes Shopsystem, genutzt werden können.

Hört sich auch schlüssig und logisch an.

Hauptsache es findet sich eine Lösung

 

[wawi-dl]

Ich finde das Plugin Recaptcha zwar gut, aber ich möchte das keinem Kunden zumuten, dann haste sicher 10-15% wieder weniger Kunden

 

[martinwolf]

Zusätzlich könnte man Shopbetreibern ein Regexfeld zur Verfügung stellen. Damit könnte man sich auf eigene Verantwortung ad hoc selbst helfen.

Siehe: https://forum.jtl-software.de/threa...ei-den-kundendaten.244526/page-2#post-1332713
Da habe ich eine Lösung angeboten. Will nur irgendwie niemand einsetzen.