Es wird kein Registierformular benutzt, somit bringt mir das Honeypot Modul, welches ich installiert habe auch nichts!
Was kann ich noch tun, um dies zu unterbinden?
Derzeit bekommt der Kunde immer nur Fehlermails vom Server, da die angegebene Emailadresse nicht existent ist. Dann sperre ich die IP, bis zum nächsten mal!
das OXID eigene Chaptcha Modul, welches ich natürlich im Einsatz habe, sieht für das register.tpl kein Chaptcha vor! Gegen ein Google Re-Chaptcha sperrt sich der Kunde wegen Datenschutz :-(.
Im Formular ist wie schon geschrieben, ein verstecktes Feld drin und die OptIn Checkbox auch.
Im Serverlog sieht man auch keinen Zugriff auf die Seite /index.php?cl=register.
Da steht im Log eigentlich die Domain des Shops, die habe ich nur unkenntlich gemacht. Der Spamer gibt keine gültigen Emailadressen an, daher dann die Fehlermeldungen vom Emailserver. Wenn es die nicht gäbe würde man die Angiffe gar nicht mitbekommen.
@TumTumi
Fan2ban müsste ich mir auf dem Server einrichten lassen. Aber da die Anfrage HTTP-Statuscode 200 beantwortet wird, wird das auch nichts bringen!
Du kannst das ja umdrehen. Ich nehme an du hast ein leeres Input und falls jemand etwas reinschreibt wird es abgelehnt. Wenn du im Register-Formular ein hidden input “from_register_form” mit value 1 reinschreibst kannst du es ablehnen falls dieses Feld nicht gesendet wird, der Spammer sich das Formular also gar nicht angesehen hat.
Mir ist das ganze schon etwas peinlich aber so ein Feld ist eigentlich schon drin!
Die Checkbox von OptIn Modul hat als value=“1”. Ein normaler User bekommt das Formular nicht versendet ohne Haken.
Edit: Ich glaube ja fast, das der Spammer das Formular gar nicht benutzt, sondern das direkt an den Server schickt!
Sicher, das geht auch je nach Anwendung über URL und bedarf dann keiner Form. Die Hacker hängen die Variablen aus einer Form an die URL und testen alles durch, bis eine Lücke entdeckt wird. Dafür gibt’s natürlich Scripte.
Gibt es da technische Möglichkeiten das zu unterbinden? Man liest ja hier bei OXID wenig bis gar nichts über solche Fälle. In dem Fall nützen ja dann auch keine Spammaßnahmen im Formular!
Aber wenn man Tante Google nach “spammer registierung” fragt findet man einiges drüber.
Wie oben erwähnt, müsstest das Captcha einbauen. Danach sollte ruhe sein. Ich habe das bei einem Shop überall hingesetzt, wo Daten einzugeben sind. Funktioniert.
Dazu reicht es, folgendes in den Controller zu legen und den Rest aus dem Template zu kopieren:
protected $_oCaptcha = null;
public function getCaptcha()
{
if ($this->_oCaptcha === null) {
$this->_oCaptcha = oxNew(‘oxCaptcha’);
}
return $this->_oCaptcha;
}
und über
$oCaptcha = $this->getCaptcha();
if (!$oCaptcha->pass($sMac, $sMacHash)) {
// even if there is no exception, use this as a default display method
oxRegistry::get("oxUtilsView")->addErrorToDisplay('MESSAGE_WRONG_VERIFICATION_CODE');
return false;
}
Die ist aber im Standard ja drin. Wenn du da ein eigenes Feld machst was sich evtl. immer wieder ändern lässt, kann man zumindest nicht mehr spammen ohne sich das Formular vorher anzuschauen. Was du auch machen könntest, ist die Registrier-Mails abzustellen, das verhindert zwar nicht die Registrierung, aber zumindest wird dann niemand mehr belästigt: Keine E-Mail bei Registrierung CE/PE | 6.x | WEB-Grips Shop
Ansonsten hilft wohl nur Captcha einbauen.
ich gebe zu ist ein kleiner Konfigration aufwand. Die Idee wäre mit der Funktion getLogger() die Registierungs Prozesse zu loggen. Und diese Logdatei mit fan2Ban zu analysieren. Wenn in einem bestimmten Zeitraum von der selben IP Adresse registierungen rein gehen. Die IP für 24h zu sperren.
Hallo Tum Tumi,
das ist sicher auch ein guter Ansatz aber für mich programmiertechnisch, mangels Kenntnissen, nicht durchführbar.
Ich versuche jetzt gerade im Captcha Modul von Oxid das Registrierformular einzubinden.
Angezeigt bekomme ich es schon mal im Formular! Leider habe ich es noch nicht geschafft, daß man auch gezwungen ist es auszuführen.
Aber das ist hier schon etwas OT.
$sMac = oxRegistry::getConfig()->getRequestParameter('c_mac');
$sMacHash = oxRegistry::getConfig()->getRequestParameter('c_mach');
$oCaptcha = $this->getCaptcha();
if (!$oCaptcha->pass($sMac, $sMacHash)) {
// even if there is no exception, use this as a default display method
oxRegistry::get("oxUtilsView")->addErrorToDisplay('MESSAGE_WRONG_VERIFICATION_CODE');
return false;
}
Ich greife hier mal die alte Diskussion auf. Ich habe auch das captcha-modul angepasst und soweit abgeändert, dass auch die Registrierung abgefangen wird. Funktioniert soweit auch, allerdings kommt trotzdem Spam rein. Ich vermute, dass die Bots hier nicht über ein Formular eindringen, sondern direkt einen Link schicken der - so meine Vermutung - vom Server nicht geprüft wird. Quasi über den alten, “ungeschützen” Link. Das captcha scheint auch keine Werte zur Auswertung zu übergeben - auch nicht, bei den ursprünglich geschützten Seiten.
Jemand eine Idee, wie ich das abfangen kann?
Das bisherige Modul von Volker Dörk (ReCaptcha v3) läuft übrigens seit kurzem nicht mehr (auf diesem Server) wegen SMTP-Fehlern, die ich auch nicht weg bekomme.
Das hatte ich ja oben bereits geschrieben, ist aber lange her.
So etwas ist sehr nervig und kostet Zeit. Ich habe dafür ein Tool eingesetzt, das jeden Aufruf am Shop anzeigt, So konnte ich dann gezielt zu einem Controller vorgehen: FOXIDO.DE | CustomerWatch | Oxid Module
Je nach Hoster kannst die Besuche aber auch dort anzeigen lassen.
An der Stelle muss das Captcha halt auch ausgewertet werden - ich denke das geschieht halt nicht. Wo muss ich da gucken? Vom Namen her in der order.php - wobei mir das dann doch komisch vorkommt…
aber so ein Feld ist eigentlich schon drin!