Aus gegebenem Anlass fasse ich mal zusammen, wie man effektiv Formularspam verhindern kann, ohne den Komfort für die Benutzer einzuschränken.


1. Aus Subject, From und To unbedingt die Zeilenumbrüche entfernen

s/[\r\n]//g


2. Alle Felder unbedingt auf Plausibilität prüfen.

Im Zeitalter der regulären Ausdrücke sollte das kein Problem sein.

Einige Beispiele:

email prüfen: /^([a-zA-Z0-9\-\.\_]+)@([a-zA-Z0-9\-\.]+\.[a-zA-Z]{2, 4})$/
Telefonnummer prüfen: /[\d-\/()+\/ ]+/

3. HTTP-Header auf Existenz/Gültigkeit prüfen

HTTP_USER_AGENT
HTTP_ACCEPT
HTTP_ACCEPT_LANGUAGE
HTTP_ACCEPT_CHARSET

4. Ein Zeitfenster bestimmen, in dem die Formulardaten gültig sind.

In einem HIDDEN-Feld wird beim Formularaufruf ein Zeitstempel mitgeschickt.
Dieser wird beim Empfang der Daten überprüft. Es müssen sowohl eine Mindestzeit als auch eine Maximalzeit abgeprüft werden.
(Nach meinen Erfahrungen ist als Mindestzeit 8 Sekunden und als Maximalzeit 20 Minuten ausreichend)

5. Mehrfaches Abschicken von Formularen verhindern.

Mit einem zusätzlichen HIDDEN-Feld eine UNIQUE_ID mitschicken und beim Empfang
prüfen, ob diese Formular-ID schon verarbeitet wurde.

6. Punkt 4 und 5 sollten kombiniert werden.

und bei jeder Scriptinstallation geringfügig variieren. Damit wird automatischer Spam ganz erheblich erschwert.

7. Keine E-Mail Adressen in HIDDEN-Feldern übergeben.

Das sollte selbstverständlich sein.

8. Ausschließlich nur POST Variablen verarbeiten.

Das sollte selbstverständlich sein.

9. Wenn möglich, nur eingeloggte Benutzer zulassen

Das ist nicht immer realisierbar, sollte aber bevorzugt werden.


10. Eine Kopie der Fehlversuche an einen Überwachungsaccount senden.

Damit besteht die Möglichkeit, zu erkennen, wenn Spamversuche stattfinden.
Gegebenenfalls können die betreffenden IP-Nummern rechtzeitig gesperrt werden.

Alle Punkte ergeben, zusammen angewendet, ein sehr hohes Maß an Schutz.

Update:
In der Zwischenzeit sind noch einige pfiffige Tricks dazugekommen

11. Trigger einbauen
Bei der Formularauswertung wird geprüft, ob in einem bestimmten Zeitraum eine vorgegebene Seite aufgerufen wurde. Wenn nicht, ist es ein untrügliches Anzeichen für einen Spider/Bot.

12. Anbieten einer Vorschau
Automatische Spider können nicht unterscheiden, welcher Button das endgültige Abschicken auslöst.
So wird immer nur die Vorschau aufgerufen und damit keine weitere Wirkung erzielt.

---

Grüße Oesi
Ich weiß, dass ich nicht weiß... (Sokrates)

Hi Oesi,
hast du auch mal einen 0815 Formmailer in dem das alles eingebaut ist, ich als PHP Laie bin ein wenig überfordert damit.


MfG

---

Webdesign Dortmund
T-Shirts bedrucken
Antispam

hi buzzbomb,

ich habe keinen 0815 Formmailer, weil das oben beschriebene nur die Grundregeln(das Grundprinzip) sind, nach denen man alle Formulare prüfen sollte. Das ist total unabhängig von der Programmiersprache.

Das wichtigste ist ja auch, daß es keine 0815 Formmailer geben sollte, damit die Angriffsfläche nicht zu groß wird und sich eine Automatik lohnt.

Wenn ich jetzt ein Script veröffentliche, ist davon auszugehen, daß es nach einiger Zeit unverändert auf mehreren Servern läuft. Und genau das ist zu vermeiden, um die Angriffsfläche so klein wie möglich zu halten.

Jedes Formular erfordert eine individuelle Plausibilitätsprüfung.


PS:
Döner "mit alles" kostet extra :-)

---

Grüße Oesi
Ich weiß, dass ich nicht weiß... (Sokrates)

Hi oesi,
ich dachte mehr so an Name, E-Mail, Text und wie dann die Prüfung für die Felder so aussieht.
Bei mir mache ich es zur Zeit z.B. so
$email = preg_replace( "/(content-type:|bcc:|cc:|to:|from:)/im", "", $email );

Hab ich von irgendeiner Seite, weiss leider nicht mehr von welcher. Ich bekomme aber immer noch jede Menge automatisch ausgefüllter Formulare zugeschickt, die Frage ist nur ob die nur bei mir landen oder ob darüber Spam an Fremde versendet wird.


MfG

---

Webdesign Dortmund
T-Shirts bedrucken
Antispam

hi buzzbomb,

du machst den gleichen Fehler, der von den Meisten gemacht wird.

Dieser Fehler besteht darin, immer nur unerwünschte Inhalte herauszufiltern. Diese Vorgehensweise führt zwangsläufig dazu, daß eben nicht alles Unerwünschte herausgefiltert wird. Entweder ist das Unerwünschte noch unbekannt, oder man hat's schlicht vergessen.

Bei einer echten Plausibilitätsprüfung werden, im Gegensatz dazu, nur die Daten angenommen, die genau den gewünschten Kriterien entsprechen.


Beispiel E-Mail:

Filtern: /(content-type:|bcc:|cc:|to:|from:)/

hier werden verschiedene Zeichenkombinationen herausgefiltert.
Weißt du, ob es nicht doch noch andere gibt?

Prüfen: /^([a-zA-Z0-9\-\.\_]+)@([a-zA-Z0-9\-\.]+\.[a-zA-Z]{2, 4})$/

damit wird geprüft, ob die E-Mail genau so aussieht: 'fred@example.com'.

Wenn hier also Daten der Form: 'bcc:fred@example.com' ankommen, dann sind sie automatisch ungültig.


Für die restlichen Datenfelder gilt das Gleiche sinngemäß.

Zusätzlich ist natürlich auch noch zu prüfen, ob der Ablauf der Dateneingabe plausibel ist. Aber das habe ich ja oben schon beschrieben.


PS.
In Perl gibt es sogar einen taint-Modus dafür. Da wird überwacht, welchen Variablen man trauen kann und welchen nicht.

---

Grüße Oesi
Ich weiß, dass ich nicht weiß... (Sokrates)

Na das ist ja eine Freude!

Eben muss ich feststellen, daß bei DrWeb meine Vorschläge aufgegriffen und ein Artikel drüber geschrieben wurde.

Jetzt ist es noch wichtiger, die Kodierungen je Installation geringfügig zu ändern, und nicht die Scripte 1 zu 1 von DrWeb zu übernehmen.

---

Grüße Oesi
Ich weiß, dass ich nicht weiß... (Sokrates)

Ich betreibe momentan ein Gästebuch auf einer PHP-basierten Website (http://www.jsvindonissa.jemk.ch/index.php?&cat=uns&subcat=gb.php). Ich habe das "Human-Check"-Script von SmiledSoft.com (freeware) eingefügt. Am Anfang funktionierte das super, leider haben die Bots in letzter Zeit gelernt, den Code irgendwie zu lesen...

Die 4. Möglichkeit scheint mir sinnvoll und einfach umsetzbar zu sein. Leider bin ich auf dem Gebiet ein ziemliches Greenhorn. Könntest du evtl. sagen, wie ich das anstellen muss?

Vielen Dank schon im Voraus!

Wenn ich mir die Frage erlauben darf: wie genau könnte eine Umsetzung von Punk 3 aussehen? Ich kann mir momentan nicht viel darunter vorstellen.

Die Spam-Scripte sind im Regelfall sehr einfach programmiert.
Deshalb werden in 95% aller Fälle die Headerinformationen nicht oder nur unzureichend gesendet.
Wenn man jetzt das Vorhandensein und die Gültigkeit prüft, ergibt das einen ziemlich wirkungsvollen Filter.

Einfaches Beispiel mit Perl:

Code

$ENV{HTTP_ACCEPT}) or die "Spam"; 

Natürlich ergibt sich die Wirkung nur daraus dass so viel wie möglich Kombinationen erfasst werden.
Dazu muss man analysieren/wissen, welche Werte das Programm erhalten darf und welche nicht.

---

Grüße Oesi
Ich weiß, dass ich nicht weiß... (Sokrates)

Hm, ja, das überprüfen, ob überhaupt etwas übergeben wurde ist ja noch einfach.

Aber wenn ich noch genauer überprüfen wollte, müsste ich bei HTTP_USER_AGENT ja quasi jeden Browser überprüfen (obwohl das wahrscheinlich nicht sehr sinnvoll ist, denn wenn der Spambot HTTP_USER_AGENT mitschickt, wird er dort wohl auch was plausibles drinstehen haben).

Und wie sieht es mit den anderen variablen aus? Kann man bei accept_language guten gewissens einfach nur bspw. deutsch und englisch akzeptieren lassen? :).

Beim user agent ist zum Beispiel folgende Zeichenkette ungültig: "Mozilla".

Beispiele für gültige Werte:

Code

"Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12" 
"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 
"Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12" 
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" 

für HTTP_ACCEPT_LANGUAGE gilt diese Regel:

/(((\w+,\w\+-\w+)|(\w+));q=\d+)/

allerding kann HTTP_ACCEPT_LANGUAGE auch komplett fehlen.

---

Grüße Oesi
Ich weiß, dass ich nicht weiß... (Sokrates)