Wie sichert ihr euch gegen Formular-Spam ab?

[Julian von Mendel]

Hi,

ich hatte neulich schon eine Thread gestartet, wie man chinesische IP-Adressen filtert, weil ständig wechselnde, chinesische IP-Adressen die Formulare meiner Internetseite mit zufälligen Daten ausfüllen. Heute Nacht 40 mal. Ich hatte vor ein paar Tagen schon einmal etwas programmiert, dass das primitive Schema dieser Nachrichten erkennt und diese gar nicht erst abschickt. Jetzt hat es gewechselt, und es kamen die Nachrichten wieder durch. Ich habe mein Programm jetzt erneut angepasst, damit es diese ebenfalls filtert. Aber ich kann nicht jede Woche etwas neues schreiben. Ich muss mir eine langfristige Lösung überlegen. IP-Adressen-Filtern hilft nichts, weil diese ständig wechseln. Ich könnte allgemein festlegen, das nicht mehr als 10 Nachrichten pro Stunde rausgehen dürfen. Aber eine tolle Lösung ist das immer noch nicht. Was macht ihr, um euch gegen Formular-Spam zu wehren?

Schöne Grüße
Julian

[Metaphore]

Hi Julian,

ich finde die Pflicht zur Eingabe von Zeichen, die in einer Grafik kryptisch dargestellt werden, sehr effektiv.

Du weißt was ich meine, oder?

Schöne Grüße
Meta

[Julian von Mendel]

Hi,

ich finde die Pflicht zur Eingabe von Zeichen, die in einer Grafik kryptisch dargestellt werden, sehr effektiv.

Du weißt was ich meine, oder?

ja. Eine Lösung die sicher gut schützt, jedoch besonders auf kommerziellen Seiten nicht gerade gut auf die Kunden wirkt.

Mir ist auch noch was eingefallen: Man könnte auf den Nicht-Formular-Seiten eine Session initialisieren, und die Formularseiten funktionieren nur, wenn diese Session bereits läuft. Man kann ja davon ausgehen, dass solche Bots keine Cookies akzeptieren. Die Mehrheit der Benutzer hingegen schon. Man würde mit dieser Lösung aber auch ein paar "liebe" Menschen aussperren (wobei das praktisch niemand mehr sein wird - viele andere Webseiten funktionieren ohne Cookies ja gar nicht).

Schöne Grüße
Julian

[Jonathan]

Du kannst auch verschiedene andere Möglichkeiten probieren.

Z.B. von der Formular-Seite aus ein Cookie setzen, dass das bei einer Bestätigungsseite oder so überprüft wird, oder du könntest ein <input type="hidden"> auf deiner Formular-Seite verstecken, und dann beim Formular-Auswerten überprüfen, ob wirklich der Inhalt des versteckten input-Feldes wirklich richtig rübergesendet wurde.

Vielleicht lassen sich die Bots auch anhand des UserAgents oder eines anderen HTTP-headers filtern.

[XaraX]

Hallo,

die Verarbeitung von Cookies ist eine programmiertechische Arbeit von vielleicht 10 min. Das interpretieren von CSS (möglichst mehrere externe Datein) dagegen ist abschreckend aufwändig ;)

Gruß aus Berlin!
eddi

[Julian von Mendel]

Hi,

du könntest ein <input type="hidden"> auf deiner Formular-Seite verstecken, und dann beim Formular-Auswerten überprüfen, ob wirklich der Inhalt des versteckten input-Feldes wirklich richtig rübergesendet wurde.

ich glaube nicht dass das funktioniert. Wenn der Bot nicht ganz dumm ist, liest er ja die Formular-Seite aus um zu bestimmen, was für Felder vorkommen: für die text-Felder wählt er einen zufälligen Wert aus und die anderen sendet er halt mit. D. h. ein hidden-Feld würde nichts bringen.

Schöne Grüße
Julian

[Julian von Mendel]

Hi,

Vielleicht lassen sich die Bots auch anhand des UserAgents oder eines anderen HTTP-headers filtern.

Diese Lösung ist sicher möglich, aber funktioniert dann wohl wieder nicht allgemein, weil sich das bei jedem Bot unterscheidet und bei sinnvoller Programmierung des Bots (Tarnung als InternetExplorer z. B.) eh nicht funktioniert. Die Session-Lösung kombiniert mit der zum Ausfüllen des Formulars benötigten Zeit bevorzuge ich momentan.

Schöne Grüße
Julian

[Kalle]

Hallo.

Man kann ja davon ausgehen, dass solche Bots keine Cookies akzeptieren.

Was spricht -- aus Sicht der Spammer -- dagegen, daß ihre Bots Cookies annehmen? Ich kann mir sogar vorstellen, daß sie die akzeptieren, um eben solche Sicherherungsmethoden auszuhebeln. Stellt ja kein großes Problem dar.

Die Mehrheit der Benutzer hingegen schon. Man würde mit dieser Lösung aber auch ein paar "liebe" Menschen aussperren (wobei das praktisch niemand mehr sein wird - viele andere Webseiten funktionieren ohne Cookies ja gar nicht).

Sehr gewagten Behauptung...

Solltest du tatsächlich diese cookiebasierte Lösung mit Sessions benutzen, wäre meiner Meinung nach auf alle Fälle ein Hinweis für die Besucher fällig, daß bestimmte Bereiche deiner Seite ohne Cookies nicht funktionieren. So sperrst du sicher weniger der "lieben Menschen" aus.

[XaraX]

Hallo Julian,

hierzu gibt es mehrere Ansetze. (Wenn ich mich recht erinnere, wird Dein Formular mit PHP verarbeitet.)

Du hast Die Möglichkeit durch eine "Bestätigungsseite" dem Spuk ein Ende zu bereiten, wenn es automatisch generierte Mails sind.

1.) Nach senden des datenaufnehmenden HTML-Formulars Stellst Du die Informationen
    nochmals dem Benutzer zur Bestätigung zusammen. Erst Durch Betätigung mittels
    Formulars wird dann eine Mail ausgelöst.

2.) Im Formular der Bestätigungsseite werden alle Eingaben in <input> vom Typ
    hidden vorgehalten nebst einem weiteren Feld, das sessionartigen Werte
    und Namen herbergen.

3.) Auf der Bestätigungsseite regenerierst Du 10 solcher Formulare, wobei nur
    eines (identifizierbar am Sessionwert/-Name) über CSS angezeigt wird.

4.) Die Position des Formulars dar nicht Statisch sein, sondern sollte unter den
    10 Formularen auch immer wechseln.

Schade um den Overhead, aber bei gut konfigurierter zlib PHPs, hät sich das noch in erträglichen Grenzen.

Gruß aus Berlin!
eddi

[Jonathan]

Hallo,

Nur doof, dass dann Leute mit alten Browsern oder Screenreadern dann zig überflüssige Formularelemente sehen, was für eine 'professionelle' Seite mindestens genauso unpassend ist wie eine Captcha-Überprüfung (das mit dem Code abtippen).

Die Methode, die Zeit zum Absenden zu überprüfen, scheint mir auch nicht wirklich sinvoll zu sein. Bots können sicher einen künstlichen delay verursachern.

Davor zu gucken, ob der Benutzer schon vorher auf einer anderen Seite war (mit Sessions oder so) erscheint mir schon sinnvoller, aber auch hier kann ein intelligenter Bot sich einfach die nötige Startseite einmal runterladen bevor er dein Formular ausfüllt.

[XaraX]

Hallo,

Nur doof, dass dann Leute mit alten Browsern oder Screenreadern dann zig überflüssige Formularelemente sehen, was für eine 'professionelle' Seite mindestens genauso unpassend ist wie eine Captcha-Überprüfung (das mit dem Code abtippen).

Screenreader interpretieren ebenso CSS http://de.selfhtml.org/css/formate/einbinden.htm#link_media und Wasserpumpen für die Pferde habe ich auch schon lange nicht mehr an einer Autobahn beobachten dürfen.

Die Methode, die Zeit zum Absenden zu überprüfen, scheint mir auch nicht wirklich sinvoll zu sein. Bots können sicher einen künstlichen delay verursachern.

Davor zu gucken, ob der Benutzer schon vorher auf einer anderen Seite war (mit Sessions oder so) erscheint mir schon sinnvoller, aber auch hier kann ein intelligenter Bot sich einfach die nötige Startseite einmal runterladen bevor er dein Formular ausfüllt.

Da stimme ich Dir absolut zu.

Gruß aus Berlin!
eddi

[O'Brien]

Hi Julian,

Ich könnte allgemein festlegen, das nicht mehr als 10 Nachrichten pro Stunde rausgehen dürfen.

könntest du nicht die Zeit zwischen dem Aufrufen der Seite mit dem Formular und dem Absenden überprüfen und bei zu kurzer Dauer das Absenden unterbinden? Ich weiß zwar nicht, um was es in deinem Formular geht, aber ein menschlicher Bot© wird wohl eine gewisse Zeit benötigen, die von einem künstlichen Bot sicher unterboten wird.

Schönen Sonntag noch!
O'Brien

[Julian von Mendel]

Zusammenfassung:

• Captcha ist wirklich sicher, aber unkomfortabel
• Viele Formulare, von denen nur eines per CSS sichtbar gemacht wird und funktioniert geht wohl, macht aber insbesondere mit Textbrowsern Probleme und erzeugt größeren Overhead
• Filtern chinesischer IP-Adressen schränkt den Spam ein wenig ein und kann u. U. in seltenen Fällen falsche Benutzer ausschließen
• Verstecke Formularfelder, kombiniert mit benötigten Sessions und überprüfter Zeit zum Ausfüllen des Formulars kann erstmal gut helfen, wenn der Bot intelligent genug ist bringt es jedoch nichts
• Überprüfen des UserAgents bzw. spezieller HTTP-Header kann einzelne Bots filtern, man muss es jedoch auf jeden einzelnen anpassen

Schöne Grüße
Julian

[lulu]

Huhu Julian,

Was macht ihr, um euch gegen Formular-Spam zu wehren?

Man kann z.B. folgende Kriterien prüfen:

• Werte von Formularfeldern (nicht Textarea) enthalten Zeilenumbrüche
• alle Formularfelder zusammen enthalten mehr als z.B. drei @s
• Formularfelder enthalten einen 32-Zeichen Hexadezimal-String (boundary)

Das funktioniert recht zuverlässig um Spam-Versuche zu erkennen.
Man kann dann diese Post-Requests z.B. in eine Text-Datei umleiten.
Muss man aber nicht ;-)

Viele Grüße

lulu

[Julian von Mendel]

Hi,

• Werte von Formularfeldern (nicht Textarea) enthalten Zeilenumbrüche
• alle Formularfelder zusammen enthalten mehr als z.B. drei @s

etwas in der Art diesre beiden Regeln habe ich bereits implementiert, und bin seitdem Spamfrei. Aber man kann lanfristig davon ausgehen, dass nicht alle Bots Nachrichten in diesem Format schreiben. Letztere Regel, für sich gesehen, kann außerdem auch noch unschuldige User für Spambots halten.

• Formularfelder enthalten einen 32-Zeichen Hexadezimal-String (boundary)

Ich hab mal eine blöde Frage... Warum schreiben diese Bots diesen Hex-String eigentlich in ihre Mails?

Das funktioniert recht zuverlässig um Spam-Versuche zu erkennen.
Man kann dann diese Post-Requests z.B. in eine Text-Datei umleiten.

Ich leite sie direkt in meine Lieblingstextdatei /dev/null.

Schöne Grüße
Julian

[fastix®]

Moin!

Was macht ihr, um euch gegen Formular-Spam zu wehren?

Hier hätte Dir die Suche (Oben links) weitergeholfen:
http://forum.de.selfhtml.org/archiv/2005/9/t115144/#m735060

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[XaraX]

Moi moin!

http://forum.de.selfhtml.org/archiv/2005/9/t115144/#m735060

habe mir die Funktion mal angesehen und bin etwas ratlos:

Warum prüft die Funktion nach einer gefundenen $_POST-Varablen nochmal, ob auch ein entsprechende $_GET-Variable existiert?
Warum bricht die Funktion mit "true" ab, wenn in einer Textarea das erste Zeichen ein Umbruch <LF> ist?
Warum wird auf <CR> geprüft?

Gruß aus Berlin!
eddi