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)
(Dieser Beitrag wurde von oesi50 am 28. Apr 2008, 16:55 geändert)
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)
(Dieser Beitrag wurde von oesi50 am 16. Mär 2006, 11:13 geändert)
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.
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?
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)
(Dieser Beitrag wurde von oesi50 am 17. Mär 2006, 12:05 geändert)
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?
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:
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)
(Dieser Beitrag wurde von oesi50 am 1. Mär 2008, 18:28 geändert)
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? :).