2448 Spams in 20 Minuten

Ronald Nickel

Ronald Nickel

Legendäres Mitglied
Hallo
gestern rief mich ein Kund an und berichtete mir er habe über 2400 Spammails über sein kontaktformular erhalten. Dieses ist aber eigendlich nur asulösbar wenn ein Mathe-Captcha richtig gelöst eingtragen wird.
Laut Logfile wurde dieses Formular aber bis zu 20x in einer Sekunde aufglöst. Das Logfile gibt keinen Referrer bei diesen Aufrufen an, was mir sagt, dass dieses Kontaktformular direkt und nicht von einem Bot oder crawler aufgerufen wurde.

Logeintrag:
2011-10-12 12:14:29 212.59.40.1 - POST /kontakt.cfm - HTTP/1.0 302 949 - Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.1.4322)

Normalerweise wird nach dem verschicken der Kontaktseite auf eine "Vielen dank für Ihre Intresse..."-Seite weitergeleitet. Die Logeinträge für den Aufruf dieser Seite fehlen aber!

So langsam wird es echt nervig denn leider war unter den 2400+ Spams auch ein großer Auftrag, den der Kunde glücklicherweise doch gefunden hat.

Was kann ich noch tun um dieses permanenten Spamangriffe abzuwehren? Wäre es ein Idee wenn ich dafür sorgen würde wenn die Seite im Referrer die eigene Domin beinhalten muss - die seite also nicht extern/direkt
augerufen werden kann sonder nur durch einen Link auf der Page selber. Oder lässt sich das auch einfach aushebeln?
Gruß Ronny
 
Hm, das klingt mir erstmal danach, dass das Kontaktformular einen Fehlprogrammierung bzw. Lücke aufweist, wenn es aufgerufen werden kann (und dabei normal reagiert), ohne dass dieses Mathe-Captcha aufgerufen wird.
Der Referer kann gefälscht werden, ist also kein wirklicher Schutz, allerdings müsste der Spambot sich daran anpassen - ob er das tut?
Ist es denn immer dieselbe IP oder immer wechselnde IP?
Ich würde als erstes das Kontaktformular auf Fehler in der Programmierung prüfen. Alternativ bzw. zusätzlich würde ich eine Zeitsperre einbauen, dass das Kontaktformular von derselben IP nur maximal alle x Sekunden aufgerufen werden kann o.ä.

HTH
Alex

 
Oder über eine Session validieren, dass das Formular nicht unmittelbar nach dem Seitenaufruf, resp. ganz ohne Seitenaufruf versendet werden kann. Ein paar Sekunden braucht ja selbst der schnellste Tipper für das ausfüllen.

Nachtrag;
Ist das Kontaktformular auch so aufgebaut wie das auf deiner Seite? Dort wird ja die Lösung des Captchas bereits auch als Formularfeld übergeben..
 
Also ich würde bei solchen Fällen rasch ein order,deny einbauen und die IP sperren, wenn es immer die gleiche ist.
Ansonsten Script zweiseitig gestalten mit einem Captcha, das "checken" die Bots i.d.R. nicht.
 
Klingt nach einer programmiertechnischen Unschoenheit.
Da gibt es einige Moeglichkeiten, solche Aktivitaeten zu unterbinden.

Richtigkeit der Captcha-Einbindung ueberpruefen und allenfalls anpassen.

Formular soll nur gesendet werden koennen, wenn sessionCookies erlaubt sind. Beim Laden des Formulars schreibst du einen Token in die Session und gleich auch als Hiddenfield in das Formular. Nach dem Absenden ueberpruefst du ob ein Token in der Session vorhanden ist und dieser mit dem Token aus dem Formular uebereinstimmen.

Um es den Bots noch etwas schwerer zu gestalten, berechnest und befuellst via JavaScript ein Hiddenfield. Am besten nimmst dafuer gleich den Token, aenderst diesen via JS etwas ab (Base64, MD5, SHA1, StringReverse ...). Am besten die Aenderungssyntax dynamisieren. Dann wieder die serverseitige Ueberpruefung (serverseitig gleiche Aenderungssyntax verwenden fuer den Wert aus der Session).

Und einfach noch generell: Keine Werte aus dem Formular in den Mailheader schreiben, denn sonst ist das Unterbinden, dass das Formular fuer CrossMail Zwecke missbraucht werden kann, enorm schwer.

Schreib mich via PM (oder gleich Email) an, wenn du Hilfe benoetigst.
 
so mein derzeitiger Workaurount

Das formular kann nur über einen link innerhalb der Seite und nicht direkt über URL aufgerufen werden.

Das Mathe Captcha wurde durch ein Bildcaptch ersetzt welches mittels UUID() eine 4stellige Kombination aus Uahlen und Buchstaben zurückgibt dir schon im Formularfeld mittels Regex überprüft wird.

Das Formularfeld "Mail" wird per Regex auf Plausibilität überprüft.

Das hiddenfield mit dem Captchergebnis wurde natürlich entfernt!

Dann habe ich mit die Idee von Wasi zu Herzen genommen und meim Laden des Formulars eine dynamische sessionvariable (createUUiD()) gestzt und die in ein Hiiddenlfield mitgegeben. Session und Hiddenfield werde nach abschicken verglichen.

weiterhin werden alle relevanten Formfelder auf eine Eingbabe von mind. 5 Zeichen überprüft.

Noch eine kleine Anmerkung: Die logifiles haben ergeben, dass für die Suche nach Schwachstellen in Webapplikationen der "Acunetix"-Scanner verwendet worden ist.


Vielen Dank an alle
Lieben Gruß
Ronny
 
Wasi Idee mit dem Token finde ich eher grenzwertig, die lässt sich mittels kurzen Nachdenken, schnell aushebeln. Auch würde man mittels JavaScript die Benutzerfreundlichkeit sinken, da nicht unbedingt jeder JavaScript aktiviert, denn dann stellt sich die Frage, ob so ein Formular überhaupt zielführend ist.


PS: Roland Du haste PM.
wink.gif
 
Gibts denn irgendwo einen guten Workarround über Mailsecurity, um nicht vollends blöd zu sterben?

Gruß Ronny
 
Also ich habe sehr gute Erfahrungen mit "Honypot-Traps" gemacht, sprich:
Du baust ein verstecktes Formularfeld ein, dem du einen attraktiven Namen gibst (z.B. URL, email).
Das Feld wird dann mittels stylesheet versteckt und nach Absenden des Formulars kannst du den Inhalt des Feldes (Bot: irgendwas; user: leer) prüfen.

Bei mir werden hierdurch bereits fast alle automatisierten Angriffe abgewehrt.

Eine weitere, effektive Möglichkeit besteht in der zeitlichen Begrenzung. Dies fängt insbesondere auch diejenigen Nutzer ab, die "wegen Verbindungsproblemen" einfach mal die Seite refreshen.
Also Session/IP X darf nur alle 30 Sek eine Mail schreiben. Ich habe das so auf einem Projekt gelöst und komme seither ohne Captcha aus und habe pro Monat max. 3-5 Fehler.
 
QUOTE (André Griepenburg @ Fr 14.10.2011, 13:54)Also ich habe sehr gute Erfahrungen mit "Honypot-Traps" gemacht, sprich:
Du baust ein verstecktes Formularfeld ein, dem du einen attraktiven Namen gibst (z.B. URL, email).
Das Feld wird dann mittels stylesheet versteckt und nach Absenden des Formulars kannst du den Inhalt des Feldes (Bot: irgendwas; user: leer) prüfen. [...]

Das ist eine nette Idee, und sinnig um Bots und unerfahrene Angreifer zu fangen, damit deren IP für X Minuten zu bannen, aber wer das Formular manuell auseinander nimmt, hat damit leider auch leichtes Spiel.

Andere Sperrungen, von maximal X Mal senden in X Minuten sollte Standard sein, aber durch neue Angriffmethoden (Bot-Netze) nicht mehr so wirksam.

Eine Lösung neben einen Captcha, die auch vorgenommen werden kann, wäre es ein Spamfilter an das Formular anzubinden, also gleich nochmal durch den normalen E-Mail-Spamfilter durchschleußen per Pipe, der Filter darf halt nur keinen Bounce Richtung Absender schicken, und das Format sollte als E-Mail vorliegen (bzw. man versichtet auf die Headerchecks). Auch eine Anbindung an Akismet wäre denkbar, wenn man den Anbieter diese Daten anvertrauen mag.
 
@Sascha: Bei richtiger Implementierung erfuellen Tokens den Zweck, dass fuer jedes Absenden erst das Formular geladen werden muss. Somit muessen jedesmal mindestens zwei Requests gesendet werden. Auf Session-, IP- und/oder UserAgent-Sperren kannst auch nur schlecht gehen, wenn der 'SpamBot' ueber unzaehlige Proxies geht, jedes mal die Cookies entfernt und nen anderen Useragent benutzt. Klar kann man ueberpruefen ob der Angreifer nen 'Proxy' benutzt, doch dann leidet wieder die Usability darunter, wie das auch bei JS, Captchas, genereller Formular Submit Timeouts etc. der Fall ist. Ist halt immer ein Abwaegen zwischen Security und Usability. JS und Konstrukte wie Tokens und Captchas sind definitiv gute Loesungen.
 
QUOTE (Wasi @ Fr 14.10.2011, 20:05)[...] JS und Konstrukte wie Tokens und Captchas sind definitiv gute Loesungen.

@Wasi: Dann ruft man es eben 2x auf, interessiert ein Bot-Netz auch nicht wirklich. Daher bleibt bei einen Kontakt-Formular nur die Absicherung mittels Captcha, selbst wenn die Usability drunter leidet, und es auch keine 100% Absicherung ist. Doch leidet sie nicht so dermaßen, wie mit einen System das zusätzlich auf JavaScript aufbaut.

Ich persönlich bin eigentlich eher für das gegebene E-Mail-System statt Kontaktformular, nur wenn dann nicht mit unnötigen Maßnahmen, die die Usability weiter senken, die dann auch wohl noch mit kurzen eingreifen eines Benutzer leicht ausgehebelt werden.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben