nicht angemeldet Dieter Raber
MudGuard
Dieter Raber
MudGuard
at
at
Hallo,
ich möchte an dieser Stelle mal ein kleines Brainstorming über das Thema Formularspam machen. Konkret geht es darum, ein Formular für Benutzerkommentare bzw -nachrichten (Kontaktformular) zu entwickeln, dass ohne allzu viel Aufwand und out-of-the-box halbwegs resistent gegen Spam ist.
Welche Möglichkeiten zur Absicherung gibt es, welche sind sinnvoll, und von welchen sollte man sich fernhalten:
1. Timestamp
Beim Betreten des Formulars wird der aktuelle Timestamp erfasst und beim Absenden geprüft. Ist die Differenz sehr klein, etwa <2 Sek, kann man davon ausgehen, dass kein normaler Nutzer das Formular ausgefüllt hat. Ist er zu groß, etwa >30 Min, könnte das ein recht sicherer Anhaltspunkt dafür sein, dass das Formular von einem Spider erfasst wurde und nun "von außen" (mit dem bei der Erfassung aktuellen Timestamp) gespammt wird.
Fazit: leicht zu implementierende Methode. Der Timestamp darf allerdings nicht im Klartext erfasst werden. Der normale Benutzer erfährt keine nennenswerten Einschränkungen -> sollte sein Ausfüllen mal über 30 Minuten gebraucht haben, bekommt er einen entsprechenden Hinweis und kann über den Back-Button zurück zu seiner Eingabe, um sie dann erneut abzusetzen. Zu bedenken: ein frisch gespidertes Formular kann für den Zeitraum bis zum zweiten Wert, hier 30 Minuten, für Spam genutzt werden. Außerdem bleibt die Frage, ob nicht vielleicht auch ein Spambot in der Lage ist, den Back-Button zu drücken? ;)
2. Vorschau
Hat sich beim Blogtool Textpattern als sinnvoll erwiesen: die "Zwangsvorschau" der eingegebenen Formulardaten. Das eigentliche Senden der Daten erfolgt also erst im zweiten Schritt beim Submit der Vorschauseite. Durch ein Weiterreichen von generierten Formularwerten lässt sich verifizieren, dass der Benutzer/der Spambot zwangsläufig das erste Formular benutzt haben muss, um zum zweiten Formular (der Vorschau) zu gelangen. Ein Direktzugriff auf das zweite Formular und Spam "von außen" kann dadurch ausgeschlossen werden.
Für den Benutzer entsteht allerdings eine leichte Einschränkung: es ist nicht mehr nur ein Klick bis zum Ergebnis, sondern aufgrund der Zwangsvorschau zwei Klicks. Und sollte die Vorschau nicht auffällig genug sein, "verliert" man als Betreiber evtl ein paar Benutzer, weil sie das finale Absenden in der Vorschau nicht bemerken und davon ausgegangen sind, dass ihr Kommentar bereits beim ersten Klick versendet wurde.
3. Analyse des Benutzerkommentars
Prüfung auf Badwords, zu viele Links oder sonstige "böse" Inhalte. In meinen Augen nicht sonderlich sinnvoll, da zum einen nicht allzu leicht zu implementieren (etwa bei Badwords: die Datenbank muss aktuell gehalten werden, Varianten von Badwords müssen erfasst werden, z.B. V1agra), und zum anderen nicht eindeutig, etwa im Fall von zu vielen Links: werden mehr als z.B. 3 erkannt, wird Spam vermutet, kann aber nicht eindeutig bestimmt werden. Unterm Strich also längst keine nachhaltige Methode, um Spam einzudämmen.
4. Abgleich mit Spamlisten
Vorm Absenden des Formulars wird die IP-Adresse mit den diversen Spamlisten abgeglichen, die im Netz verfügbar sind (etwa Spamhaus.org).
Probleme/Nachteile: 1. Die Listen sind nur bedingt aktuell, 2. sie enthalten vermutlich nur einen Teil der Spam-IPs, 3. sie müssen beim Versenden des Formulars abgefragt werden (Performanceverlust), 4. sie sind nicht immer verfügbar (Serverausfall), 5. sie schließen u.U. ganze Nutzergruppen aus und 6. sie sind "user generated", so dass immer auch die Gefahr von Manipulation besteht und auch "gute" Benutzer-IPs ausgeschlossen werden könnten.
5. Prüfung auf Massenversand
Typische "Flooding"-Maßnahmen, etwa, dass ein Benutzer maximal x Kommentare innerhalb eines bestimmten Zeitraums hinterlassen darf.
Problematisch: bezieht sich auf IP-Adressen, ist damit kein sicherer Schutz vor Spam mit wechselnden IPs, und schließt zudem u.U. ganze Nutzergruppen aus.
6. CATCHPAs
generierte Grafiken, die Zeichen abbilden, die vom Nutzer im Klartext eingegeben werden müssen, um ein Formular zu versenden.
Positiv: bieten zurzeit noch recht hohe Sicherheit, die jedoch zukünftig nachlassen wird, sobald die automatische Erkennung von Zeichen wirksamer wird.
Besonders negativ: deutliche Einschränkung des Benutzers.
Das sind ein paar gängige Methoden zur Absicherung, die mir gerade eingefallen sind. Sicherlich gibt es viele weitere.. ich hoffe, dass möglichst viele davon hier im Thread aufgeführt und diskutiert werden. Interessant zu wissen ist vielleicht auch, welche Vorkehrungen Wordpress' bekanntestes Anti-Spam-Plugin Asikmet trifft - nach eigener Aussage "hundreds of tests". In der Praxis schlägt es sich damit ganz gut, auch wenn viele dieser Tests vermutlich "Schüssen ins Blaue" gleichen und allenfalls per Zufall Spamkommentare finden.
Mir scheint es zurzeit ganz sinnvoll, mindestens auf den Timestamp zu setzen, weil die Methode schnell zu implementieren ist und den Nutzer nicht einschränkt, und zusätzlich die Vorschau zu aktivieren, um ohne viel Aufwand den vorbeirauschenden 1st-click-Spam zu unterbinden.
Bin gespannt auf eure Rückmeldungen!
Viele Grüße!
_ds
Hallo Schuer,
Ich stelle mir vor, dass es eine gute Idee wäre, wenn wir uns bei diesem Brainstorming möglichst die Denke der bösen Buben zueigen machen würden, will sagen, wir sollten für jede Abwehrtechnik, die vorgeschlagen wird nach einer Möglichkeit suchen, diese zu umschiffen.
Gruß,
Dieter
Hello,
Ich stelle mir vor, dass es eine gute Idee wäre, wenn wir uns bei diesem Brainstorming möglichst die Denke der bösen Buben zueigen machen würden, will sagen, wir sollten für jede Abwehrtechnik, die vorgeschlagen wird nach einer Möglichkeit suchen, diese zu umschiffen.
Sehr gute Idee!
Die "pösen Pupen" tuns ja ohnehin. Oder glaubt jemand ernsthaft, dass die hier nicht mitlesen?
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
habe d'ehre Tom
Sehr gute Idee!
Die "pösen Pupen" tuns ja ohnehin. Oder glaubt jemand ernsthaft, dass die hier nicht mitlesen?
Neigst Du oefter zur Uebertreibung :-)
Ich kann mir nur schwer vorstellen, dass Spamschmieden in China, Russland (oder wo auch sonst noch) SELFHTML *so* im Blickfeld haben.
Ein bisschen viel der Ehre.
man liest sich
Wilhelm
Ich stelle mir vor, dass es eine gute Idee wäre, wenn wir uns bei diesem Brainstorming möglichst die Denke der bösen Buben zueigen machen würden, will sagen, wir sollten für jede Abwehrtechnik, die vorgeschlagen wird nach einer Möglichkeit suchen, diese zu umschiffen.
Sehr gerne!
Absicht dieses gesamten Brainstormings soll sein, ein Bündel von Techniken zu finden, das wirksam ist und sich dabei verhältnismäßig einfach anwenden und implementieren lässt, ohne den Benutzer einzuschränken.
Viele Grüße!
_ds
Hallo Schuer.
7. Freischaltung der Kommentare
Getätigte Kommentare werden zwar in der Datenkbank abgelegt, jedoch als versteckt gekennzeichnet. Hat der Autor der Site den Kommentar als nicht-Spam identifiziert, schaltet er ihn frei, ansonsten löscht er ihn einfach.
Vorteil: Trefferquote 100%.
Einen schönen Dienstag noch.
Gruß, Mathias
Hello Mathias,
- Freischaltung der Kommentare
Getätigte Kommentare werden zwar in der Datenkbank abgelegt, jedoch als versteckt gekennzeichnet. Hat der Autor der Site den Kommentar als nicht-Spam identifiziert, schaltet er ihn frei, ansonsten löscht er ihn einfach.Vorteil: Trefferquote 100%.
Nachteil:
Der Betreuer muss die Kommentare doch lesen und wird damit als potentieller Spam-Empfänger auch erreicht. Bei ca. 200 bis 400 derartiger Zugänge täglich wird Dir die Lust dazu dann automatisch vergehen und Du wirst nach Möglichketien suchen, eben genau die Filterung zu automatisieren, so wie Schuer es hier tut.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hallo Tom.
- Freischaltung der Kommentare
Getätigte Kommentare werden zwar in der Datenkbank abgelegt, jedoch als versteckt gekennzeichnet. Hat der Autor der Site den Kommentar als nicht-Spam identifiziert, schaltet er ihn frei, ansonsten löscht er ihn einfach.Vorteil: Trefferquote 100%.
Nachteil:
Der Betreuer muss die Kommentare doch lesen und wird damit als potentieller Spam-Empfänger auch erreicht.
Der Betr(eiber|euer) wird die Kommentare sowieso lesen wollen, also kann er sie auch gleich auf Spam untersuchen.
Bei ca. 200 bis 400 derartiger Zugänge täglich wird Dir die Lust dazu dann automatisch vergehen und Du wirst nach Möglichketien suchen, eben genau die Filterung zu automatisieren, so wie Schuer es hier tut.
Womöglich. Mit allen ihren Nachteilen.
Einen schönen Dienstag noch.
Gruß, Mathias
Hello,
Der Betr(eiber|euer) wird die Kommentare sowieso lesen wollen, also kann er sie auch gleich auf Spam untersuchen.
Eben nicht.
Viele eMail-Kontaktmöglichkeiten sind heute auf Formular umgestellt, weil email zu spamanfällig ist. Wenn aber Forms inzwischen auch zum Spammen genutzt werden, hat man nichts mehr gewonnen.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hallo Tom.
Viele eMail-Kontaktmöglichkeiten sind heute auf Formular umgestellt, weil email zu spamanfällig ist.
Zumindest in Deutschland ist dies aber nicht zulässig. Die E-Mail-Adresse *muss* angegeben werden. Ein Kontaktformular kann eine angenehme Ergänzung sein.
Wenn aber Forms inzwischen auch zum Spammen genutzt werden, hat man nichts mehr gewonnen.
Was genau meinst du hiermit? Dass sie als Spamschleuder missbraucht werden?
Einen schönen Dienstag noch.
Gruß, Mathias
hi,
- Freischaltung der Kommentare
Getätigte Kommentare werden zwar in der Datenkbank abgelegt, jedoch als versteckt gekennzeichnet. Hat der Autor der Site den Kommentar als nicht-Spam identifiziert, schaltet er ihn frei, ansonsten löscht er ihn einfach.Vorteil: Trefferquote 100%.
Ja, mache ich aktuell in meinem Blog so.
Nachteil:
Der Betreuer muss die Kommentare doch lesen und wird damit als potentieller Spam-Empfänger auch erreicht.
Weiterer Nachteil: Die zeitliche Verzögerung, bis andere Nutzer die Kommentare lesen können.
In der nächsten Version meines Blog-Scriptes werde ich folgenden erweiterten Ansatz verfolgen:
Jeder neue Kommentar bekommt eine zusätzliche, zufällige Unique-ID in der Datendank.
Nach dem Abspeichern wird diese Unique-ID in einem Cookie auf dem Client abgelegt.
Wird jetzt (Tage, Wochen) später ein weiterer Kommentar verfasst und dabei im Cookie eine solche Unique-ID übermittelt, schaue ich zunächst nach, ob ich bereits in der Vergangenheit einen Kommentar mit dieser Unique-ID freigeschaltet habe - wenn ja, kann ich davon ausgehen, dass ich diesen Benutzer (exakter: den Client) bereits "kenne" und ihm "vertraue", und der neue Kommentar wird automatisch freigeschaltet. Wenn nein, muss er nach wie vor warten.
Vorteile:
Nachteile:
Wer sich einmal mit einem "vernünftigen" Kommentar in mein Vertrauen geschlichen hat, _und_ das Verfahren kennt, kann diese Unique-ID jetzt nutzen, um weitere, "böse" Kommentare abzusetzen, die sofort freigeschaltet werden. Wenn das vorkommt, kann ich beim ersten Kommentar die Unique-ID wieder entfernen - somit wird bei den nächsten Post-Versuchen kein freigeschalteter Kommentar zur übermittelten Unique-ID mehr gefunden, der neue Versuch landet also wieder auf dem Wartehaufen.
(leichte) Datenschutz-Bedenken. Mehrere solche Kommentare mit gleicher Unique-ID kann ich einem Benutzer (Client) zuordnen, auch wenn dieser das nicht wünschen sollte. Aber dagegen hilft ein kurzer Hinweis, sowie Nichtannahme oder Löschung des Cookies.
gruß,
wahsaga
- Freischaltung der Kommentare
Getätigte Kommentare werden zwar in der Datenkbank abgelegt, jedoch als versteckt gekennzeichnet. Hat der Autor der Site den Kommentar als nicht-Spam identifiziert, schaltet er ihn frei, ansonsten löscht er ihn einfach.
Mir geht's eigentlich mehr um Maßnahmen gegen den Versand/Erhalt von Spamnachrichten, nicht darum, sie vor anderen Nutzern zu verstecken, wenn sie bereits angekommen sind.
Wirklich sicher ist man natürlich nur dann, wenn irgendeine Form von manueller Prüfung hinzugezogen wird, aber Ziel des Brainstormings hier soll sein, soviel wie möglich schon automatisiert dagegen zu tun, dass Spam geblockt wird - ohne dabei den Nutzer einzuschränken oder einen Riesenaufwand an Implementierung zu haben.
Viele Grüße!
_ds
Hallo
... aber Ziel des Brainstormings hier soll sein, soviel wie möglich schon automatisiert dagegen zu tun, dass Spam geblockt wird ....
Das ist pupenatzeneinfach:
Tue nichts, und du tust automatisch alles dagegen, dass Spam geblockt wird.
;-)
Tschö, Auge
Hello,
- Timestamp
Finde ich eine sinnvolle Ergänzung des Maßnahmenbündels.
- Vorschau
Scheint mir trotzdem sehr sinnvoll zu sein. Auch der Benutzer benötigt eine Kontrolle seiner Daten.
Außerdem könnte man die "Vorschau" auch als druckbare Bestätigungsseite auslegen, und dann den Nutzer einen Submit-Button von mehreren klicken lassen, um das Einreichen zu bestätigen.
- Analyse des Benutzerkommentars
Prüfung auf Badwords,
... Checkboxen, wie "ich bin ein Spammer", "Mein Kommentar soll gelöscht werden", "Bitte Formular berücksichtigen", "Bedingungen gelesen", usw im Wechsel, gelegentlich mit Schreibfehlern, zusätzlichen Zeichen, Sternchen, Bindestrichen etc. versehen einbauen.
... Textfelder einbauen, die _nicht_ ausgefüllt werden dürfen, oder deren Inhalt nicht verändert werden darf. Ggf. mittels Form und Farbe bzw. CSS unsichtbar machen für Browser.
- Abgleich mit Spamlisten
Gute Idee, aber nicht wirklich gerecht. Viele für Spam missbrauchte IPs haben auch noch "normale" Benutzer.
- Prüfung auf Massenversand
???
- CATCHPAs
Manchmal kaum noch zu entziffern
7. Formulare im netz nicht mit "*.php" oder ähnlichen Endungen speichern, sondern lieber dem Server beibringen, dass er *.html oder *.pdf (oder sonstiges) im jeweiligen Verzeichnis als PHP (oder sonstige aktive Seiten) interpretiert. Das verhindert zumindest das gezielte Spidern nach aktiven Seiten. Allerdings ist das Wort "<form>" für den Spider aussagefähig genug
Den erhöften Traffic kann man damit leider nicht verhindern, sondern nur die Arbeit für den Empfänger.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hello,
Nachtrag:
8: Sessions verwenden
9: Field Name Translating verwenden mittels Session, also nicht "Kommentar" und "email-Name" als Caption verwenden, sondern "F1308-axp" und "F32-0815" (Beispiele)
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Moin!
9: Field Name Translating verwenden mittels Session, also nicht "Kommentar" und "email-Name" als Caption verwenden, sondern "F1308-axp" und "F32-0815" (Beispiele)
Bringt nicht sehr viel. Spam-Bots gehen sehr häufig nach Feldtyp, nicht nach Name.
- Sven Rautenberg
hi,
9: Field Name Translating verwenden mittels Session, also nicht "Kommentar" und "email-Name" als Caption verwenden, sondern "F1308-axp" und "F32-0815" (Beispiele)
Bringt nicht sehr viel. Spam-Bots gehen sehr häufig nach Feldtyp, nicht nach Name.
Darüber hinaus kommt es in meinen Augen einer Kapitulation vor den Spammern gleich, wenn man ihnen "zuliebe" jetzt schon legliche _sinnvolle_ Benennung von Formularfeldern über Bord wirft.
gruß,
wahsaga
Hello,
Darüber hinaus kommt es in meinen Augen einer Kapitulation vor den Spammern gleich, wenn man ihnen "zuliebe" jetzt schon legliche _sinnvolle_ Benennung von Formularfeldern über Bord wirft.
Dann hast Du Dein lokales Netz sicher auch tranparent ins Internet eingebunden? *gg*
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hello,
9: Field Name Translating verwenden mittels Session, also nicht "Kommentar" und "email-Name" als Caption verwenden, sondern "F1308-axp" und "F32-0815" (Beispiele)
Bringt nicht sehr viel. Spam-Bots gehen sehr häufig nach Feldtyp, nicht nach Name.
... müssen dann aber den Namen aus der Session wieder mit zurücksenden. Das funktioniert genauso wie die Portübersetzung bei NAT. Zwischensoeichern und Scanning werden dadurch enorm erschwert.
Wenn der translated fieldname in der Session nicht mehr offen ist, ist ein Fehler (oder eben ein Robot) aufgetreten.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Moin!
9: Field Name Translating verwenden mittels Session, also nicht "Kommentar" und "email-Name" als Caption verwenden, sondern "F1308-axp" und "F32-0815" (Beispiele)
Bringt nicht sehr viel. Spam-Bots gehen sehr häufig nach Feldtyp, nicht nach Name.
... müssen dann aber den Namen aus der Session wieder mit zurücksenden. Das funktioniert genauso wie die Portübersetzung bei NAT. Zwischensoeichern und Scanning werden dadurch enorm erschwert.
Zwischenspeichern ja. Scanning und Spamming nach meiner Ansicht nicht.
Gehe nicht davon aus, dass die Spam-Mafia nur automatisierte Verfahren einsetzt. Lohnende Spam-Ziele werden mit Sicherheit auch mit menschlicher Interaktion ausfindig gemacht. Oder durch das Suchen passender Stichworte in Suchmaschinen: "Gästebuch, Wiki, Formular, Kontakt, Impressum,..." Diese Worte kann man ja bei der eigenen Verlinkung auf die Bereiche nicht weglassen, weil man seine menschlichen Besucher ja aufklären muß, wohin er gehen kann - auch wenn die URL dann eben nicht /cgi-bin/guestbook.pl heißt.
Und ansonsten wird in der Tat schon heute ein Formular tatsächlich erstmal mit GET abgefordert, und dann mit POST zurückgeschickt. Wie intelligent sich Bots dabei anstellen, liegt in der Intelligenz der Botprogrammierer.
Und die können mit Sicherheit auch mit Sessions umgehen. Und mit ziemlich vielen der hier vorgeschlagenen Mechanismen dann irgendwann auch, wenn sich das lohnt.
- Sven Rautenberg
Hello,
Und die können mit Sicherheit auch mit Sessions umgehen. Und mit ziemlich vielen der hier vorgeschlagenen Mechanismen dann irgendwann auch, wenn sich das lohnt.
DAS genau befürchte ich auch. Wir machen sie nach und nach schlau...
Und das Ganze dann auch noch kostenlos.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
DAS genau befürchte ich auch. Wir machen sie nach und nach schlau...
Und das Ganze dann auch noch kostenlos.
Wir machen sie schlau? Indem sie Postings in diesem Forum lesen, meinst du? Ich glaube, da irrst du dich. Dieses Forum hat keine Relevanz und wird von der Masse der Webentwickler da draußen recht durchgängig gemieden *. Das betrifft umso mehr alle deutschunkundigen Webentwickler, die wiederum relevant für den Bereich des Spamkontakts sind.
Du könntest vermutlich deine Bankdaten als <h1> in diesem Forum hinterlegen und müsstest keinen Missbrauch fürchten. Ganz im Gegensatz zum Weblog übrigens, das vor allem dank Matthias' imposantem Einsatz schon jetzt über eine deutliche Relevanz "da draußen" verfügt.
(* für meiner Sicht vor allem aus zwei Gründen: der klassischen Baumstruktur und unserem sicheren Gefühl für schlechte Kommunikation)
Viele Grüße!
_ds
Hi,
- Timestamp
Fazit: leicht zu implementierende Methode. Der Timestamp darf allerdings nicht im Klartext erfasst werden.
Vorschlag: Der Timestamp wird serverseitig in der Session gehalten und nicht zum Client gesendet, wo er manipuliert werden könnte.
- Analyse des Benutzerkommentars
Die Spams nicht löschen, sondern in "Spamverdacht" zwischenspeichern.
Dort dann manuell entscheiden, ob löschen oder wiederherstellen.
- Prüfung auf Massenversand
Typische "Flooding"-Maßnahmen, etwa, dass ein Benutzer maximal x Kommentare innerhalb eines bestimmten Zeitraums hinterlassen darf.
Problematisch: bezieht sich auf IP-Adressen,
Session.
- CATCHPAs
Jag den Vater? Captcha ...
Das sind ein paar gängige Methoden zur Absicherung, die mir gerade eingefallen sind. Sicherlich gibt es viele weitere..
Per CSS verstecktes Eingabefeld, das nicht ausgefüllt werden darf.
cu,
Andreas
Hallo MudGuard,
Die Spams nicht löschen, sondern in "Spamverdacht" zwischenspeichern.
Dort dann manuell entscheiden, ob löschen oder wiederherstellen.
Extraarbeit fuer den Admin, läuft der Idee zuwider, den Vorgang möglichst automatisch ablaufen zu lassen
Gruß,
Dieter
habe d'ehre Dieter
Extraarbeit fuer den Admin, läuft der Idee zuwider, den Vorgang möglichst automatisch ablaufen zu lassen
Wobei dieser dann aber wegen anderweitiger Eintraege u.U. schon mit einem Bein vor dem Richter stehen kann.
man liest sich
Wilhelm
Hello,
Extraarbeit fuer den Admin, läuft der Idee zuwider, den Vorgang möglichst automatisch ablaufen zu lassen
Wobei dieser dann aber wegen anderweitiger Eintraege u.U. schon mit einem Bein vor dem Richter stehen kann.
Nö!
_Erst_ automatisch filtern und dann erst personell kontrollieren.
Anders hätte sowas keinen Sinn, bestenfalls für kleine private Seiten.
Hier ging's doch aber wohl um das Brainstorming für professionelle Lösungen auch vielbesuchter und benutzter Seiten. Stell Dir mal vor, 1&1 oder sonst ein Anbieter dieses Gewichts würde personell aussortieren müssen...
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hi there,
Per CSS verstecktes Eingabefeld, das nicht ausgefüllt werden darf.
Sehr gute Überlegung! Obwohl ein sehr verfeinerter Spammer damit uU klarkommen könnte , ein cleverer Ansatz...
hi,
Vorschlag: Der Timestamp wird serverseitig in der Session gehalten und nicht zum Client gesendet, wo er manipuliert werden könnte.
Alternative (weil man ja vielleicht nicht immer das Geschütz Session für triviale Aufgaben zusätzlich auffahren möchte):
Timestamp im Klartext übertragen, plus MD5 (oder sonstigen Hash) von Timestamp plus $geheimWort.
Empfängerseitig abgleich, ob Hash von Klartext-Timestamp plus $geheimWort mit dem Kontrollwert übereinstimmt.
gruß,
wahsaga
Per CSS verstecktes Eingabefeld, das nicht ausgefüllt werden darf.
Die Methode hat sich beim Sunflyer (zurzeit nur im Google-Cache verfügbar) vor einiger Zeit schon als sehr wirksam erwiesen.
Die Einschränkungen des Benutzer sind hier recht gering, wenn man das Feld auffällig genug kennzeichnet, so dass die Information, es NICHT zu befüllen, eindeutig vermittelt wird (Stichwort Screenreader). Sicherlich eine gute Maßnahme, die zudem sehr wirksam ist.
Viele Grüße!
_ds
Hi there,
Die Einschränkungen des Benutzer sind hier recht gering, wenn man das Feld auffällig genug kennzeichnet, so dass die Information, es NICHT zu befüllen, eindeutig vermittelt wird (Stichwort Screenreader).
Wie soll denn Deiner Meinung nach der Benutzer ein mit CSS verstecktes Feld versehentlich befüllen?
hi,
Die Einschränkungen des Benutzer sind hier recht gering, wenn man das Feld auffällig genug kennzeichnet, so dass die Information, es NICHT zu befüllen, eindeutig vermittelt wird (Stichwort Screenreader).
Wie soll denn Deiner Meinung nach der Benutzer ein mit CSS verstecktes Feld versehentlich befüllen?
"Stichwort Screenreader" deutet die Problematik an - nicht alle dafür benutzen Programme interpretieren die jeweiligen CSS-Formatierungen derart, dass sie versteckte Elemente nicht vorlesen.
Und in einem Textbrowser o.ä. ist mit CSS auch wenig zu verstecken.
gruß,
wahsaga
Hi there,
"Stichwort Screenreader" deutet die Problematik an - nicht alle dafür benutzen Programme interpretieren die jeweiligen CSS-Formatierungen derart, dass sie versteckte Elemente nicht vorlesen.
ja, nicht mitgedacht, ist wohl noch etwas zu früh für mich...
Hi,
Wie soll denn Deiner Meinung nach der Benutzer ein mit CSS verstecktes Feld versehentlich befüllen?
Nicht jeder Browser kann oder darf das vom Webseiten-Autor vorgegebene CSS anwenden.
Es gibt Browser, die gar kein CSS können,
es gibt Browser, die CSS nur teilweise können,
es gibt Browser, die CSS falsch anwenden,
es gibt Browser, die ihrem Nutzer erlauben, eigene Stylesheets in die Darstellung mit einfließen zu lassen,
usw.
cu,
Andreas
Hallo.
Hab schon verschiedene Möglichkeiten probiert und kombiniert (Timestamp, IPs). Aber der erfolgreichste Ansatz war bislang das Prüfen von eingegebenen URLs gegen eine Blacklist.
PEAR:Net_DNSBL leistet da gute Unterstützung
http://pear.php.net/package/Net_DNSBL
Grüße aus Würzburg
Julian
Hallo Schuer,
ich möchte an dieser Stelle mal ein kleines Brainstorming über das Thema Formularspam machen. Konkret geht es darum, ein Formular für Benutzerkommentare bzw -nachrichten (Kontaktformular) zu entwickeln, dass ohne allzu viel Aufwand und out-of-the-box halbwegs resistent gegen Spam ist.
hierbei wäre es m.E. nach ein Muss, einen Feature-Artikel für die SELFHTML-Doku zu schreiben, so dass auch weniger begnadete Programmierer ein Recht auf spamfreie Formulare / Mailboxen bekommen (Ich nehme mich da nicht aus). Der Wille zum erlernen der Techniken hat zumindest in den Anfangstagen nichts mit Zuverlässigkeit zu tun. Und bevor man sich ominöse Skripte aus dem Netz lädt und verwendet, sollte SELFHML einen Schritt weitergehen und aufzeigen, wie man es richtig macht. Es tummeln sich hier unendliche viele Fachleute, da wird sich doch ein relativ spamsicheres Formular entwickeln lassen?! Und selbst wenn die Spammafia hier mitliest, nach den ersten erfolgreichen Attacken gegen das Skript kann der Artikel ja erweitert werden.
Vielen Dank für Aufmerksamkeit.
Mit freundlichen Grüßen,
André
Hallo.
hierbei wäre es m.E. nach ein Muss, einen Feature-Artikel für die SELFHTML-Doku zu schreiben,
Da widerspreche ich etwas. Die bisherigen feature-Artikel sind m.E. langfristig angelegt, d.h. unterliegen kaum Änderungen, und können so ewig im Netz stehen ohne weiterer Pflege zu bedürfen.
Ein Artikel über den Kampf gegen Spam-Bots unterliegt aber zwangsläufig der dem Aktualisierungszwang, da die Spam-Bots mit jeder Gegenmaßnahme intelligenter werden, d.h. versuchen, diese zu umgehen wenn sie nur verbreitet genug ist (Siehe hierzu z.B. "Breaking a Visual CAPTCHA", http://www.cs.sfu.ca/~mori/research/gimpy/).
Wer etwas Zeit aufwändet, der wird im Netz schon jetzt schnell fündig auf der Suche nach möglichen Maßnahmen. Z.B. gibt's bei Dr. Web eine Artikelreihe zu (http://www.drweb.de/webmaster/sichere-formulare-teil4.shtml).
Grüße aus Würzburg
Julian
Wer etwas Zeit aufwändet, der wird im Netz schon jetzt schnell fündig auf der Suche nach möglichen Maßnahmen. Z.B. gibt's bei Dr. Web eine Artikelreihe zu (http://www.drweb.de/webmaster/sichere-formulare-teil4.shtml).
Danke für den Link! Im dortigen Artikel wird die Möglichkeit mit Timestamp + Werteübergabe sehr schön aufgezeigt. Das dort eingesetze Formular ist vermutlich sehr sicher gegen Spam von außen, bietet also schonmal einen gesunden Basisschutz.
Viele Grüße!
_ds
hi,
- Vorschau [...]
Für den Benutzer entsteht allerdings eine leichte Einschränkung: es ist nicht mehr nur ein Klick bis zum Ergebnis, sondern aufgrund der Zwangsvorschau zwei Klicks. Und sollte die Vorschau nicht auffällig genug sein, "verliert" man als Betreiber evtl ein paar Benutzer, weil sie das finale Absenden in der Vorschau nicht bemerken und davon ausgegangen sind, dass ihr Kommentar bereits beim ersten Klick versendet wurde.
Ja, deutlicher Hinweis ist erforderlich.
Ich persönlich kann mit so einer "Zwangs-Vorschau" gut leben - ich schaue mir ohnehin gerne erst noch mal an, wie eine Formulareingabe "aufbereitet" ausschaut, weil ich da Tippfehler etc. leichter finde, als beim Scrollen in einer (oftmals zu kleinen) Textarea.
- Analyse des Benutzerkommentars
Prüfung auf Badwords, zu viele Links oder sonstige "böse" Inhalte. In meinen Augen nicht sonderlich sinnvoll, da zum einen nicht allzu leicht zu implementieren (etwa bei Badwords: die Datenbank muss aktuell gehalten werden, Varianten von Badwords müssen erfasst werden, z.B. V1agra)
Gerade Badword-Filter habe ich noch nie für sonderlich sinnvoll erachtet.
Die Phantasie zur "Unkenntlichmachung" bzw. Variation kennt kaum Grenzen, und ein Algorithmus (mit vertretbarem Aufwand) dürfte dagegen fast immer verlieren.
- Abgleich mit Spamlisten
Vorm Absenden des Formulars wird die IP-Adresse mit den diversen Spamlisten abgeglichen, die im Netz verfügbar sind
Aufwendig und teuer (Traffic/Zeit).
- Prüfung auf Massenversand
Typische "Flooding"-Maßnahmen, etwa, dass ein Benutzer maximal x Kommentare innerhalb eines bestimmten Zeitraums hinterlassen darf.
Problematisch: bezieht sich auf IP-Adressen, ist damit kein sicherer Schutz vor Spam mit wechselnden IPs, und schließt zudem u.U. ganze Nutzergruppen aus.
Ja, könnte nur bei eindeutiger Identifikation des Clients überhaupt sinnvoll sein - liefe also auf vorherige Registrierung oder zwangsweise anzunehmenden Cookie hinaus.
Außerdem zeigt die Erfahrung, dass die Spammer inzwischen nicht mehr nur auf Quantität in kürzesten Intervallen setzen - sondern sich teilweise inzwischen extra Zeit lassen und es "gemütlich angehen" lassen, um weniger aufzufallen.
- CATCHPAs [...]
Besonders negativ: deutliche Einschränkung des Benutzers.
Die grafische Variante scheidet m.E. vollkommen aus.
"Textaufgaben" á la "bitte geben sie hier die Summe von $x und $y ein" sind von der Barrierearmut her noch eher vertretbar.
Möglichkeiten zu finden, die den "echten" Nutzer möglichst wenig einschränken, scheint mir am wichtigsten zu sein - und zugleich am schwierigsten.
Aber es kann ja nicht sein, dass dieser "Konflikt" auf dem Rücken der Nutzer ausgetragen wird, die damit nichts zu tun haben.
gruß,
wahsaga
- Vorschau [...]
Ja, deutlicher Hinweis ist erforderlich.
Deutlicher Hinweis und vor allem eine gut nutzbare Handlungsfolge: einige Textpattern-Blogs leiden darunter, dass die Vorschau - weil nicht als feste Aktion bedacht - im Template untergeht. Man stelle sich die Situation vor: bereits 30 Kommentare vorhanden, darunter das Formular und nach dem ersten Submit erscheint die Vorschau über einen Anker angesprungen irgendwo unten am Dokumentenende zwischen Kommentar 30 und dem neuen Formular. Das ist kaum benutzerfreundlich. Wenn also Vorschau, dann mit eindeutiger Abhandlung (die anderen 30 Kommentare werden ausgeblendet, kein Sprung über Anker) und ausreichend gekennzeichnet.
Außerdem zeigt die Erfahrung, dass die Spammer inzwischen nicht mehr nur auf Quantität in kürzesten Intervallen setzen - sondern sich teilweise inzwischen extra Zeit lassen und es "gemütlich angehen" lassen, um weniger aufzufallen.
Das sehe ich auch so. Positiv für uns bleibt dabei, dass sie den Vorgang des Ausfüllens eines Formulars bishin zum Absenden bisher noch nicht "gemütlich" vollziehen, so dass die Timestamp-Methode für Schnellposter noch greifen kann -> ist ein Formular innerhalb von 1-2 Sekunden komplett ausgefüllt, ist es recht sicher Spam.
Die grafische Variante scheidet m.E. vollkommen aus.
"Textaufgaben" á la "bitte geben sie hier die Summe von $x und $y ein" sind von der Barrierearmut her noch eher vertretbar.
Die Popnutten fragen zu dem Zweck, wie Adam Green mit Vornamen heißt ;)
Viele Grüße!
_ds
Hi,
Welche Möglichkeiten zur Absicherung gibt es, welche sind sinnvoll, und von welchen sollte man sich fernhalten:
- Timestamp
Jo.
- Vorschau
Na ja. "Zwingt" halt den Benutzer.
- Analyse des Benutzerkommentars
Yep.
- Abgleich mit Spamlisten
Hmm ...
- Prüfung auf Massenversand
Yep.
- CATCHPAs
Naaah.
Besonders negativ: deutliche Einschränkung des Benutzers.
Schlimm.
Das sind ein paar gängige Methoden zur Absicherung, die mir gerade eingefallen sind. Sicherlich gibt es viele weitere.. ich hoffe, dass möglichst viele davon hier im Thread aufgeführt und diskutiert werden.
HIDDEN INPUT. Wenn das (blindlings) gefüllt wird, dann war's ein stupider Bot, der alles füllt, was ihm so vor die Flinte kommt. ;-)
Gruß, Cybaer
Eine vielleicht laienhafte Frage. Wie kommt es eigentlich, dass hier im SelfHTML-Forum nie SPAM aufzufinden ist? Werden die Beiträge so stark moderiert oder warum sieht man hier nie was?
Und außerdem würde mich interessieren, warum Menschen überhaupt Gästebücher spammen. Einen guten Werbeeffekt für die Produkte hat das wohl kaum.
Rafael
Moin!
Eine vielleicht laienhafte Frage. Wie kommt es eigentlich, dass hier im SelfHTML-Forum nie SPAM aufzufinden ist? Werden die Beiträge so stark moderiert oder warum sieht man hier nie was?
Ich habe auch keine Ahnung, warum nichts kommt. Offenbar ist die Forumsstruktur für Bots nicht sehr zugänglich. Oder das Forum taucht nicht bei Google auf (die Startseite wird nicht indiziert, nur das Archiv).
Wir müssen jedenfalls nur extrem selten Spam löschen - weil ein Hirni das manuell hier eingetragen hat.
Und außerdem würde mich interessieren, warum Menschen überhaupt Gästebücher spammen. Einen guten Werbeeffekt für die Produkte hat das wohl kaum.
Linkpopularität = Besseres Google-Ranking = mehr Verkauf
Wenn du zwanzig Seiten zum Produkt auf die ersten zehn Google-Seiten gepusht hast, dann interessieren die tausend Gästebuchseiten, die eventuell gleiche Stichworte enthalten, auf den hinteren Seiten nicht mehr, weil so weit keiner durchklickt.
- Sven Rautenberg
- Vorschau
Sinnvoll. Vermindert auch Tippfehler.
- Analyse des Benutzerkommentars
Eingeschränkt sinnvoll als Ergänzung, wenn nicht zu rigide gefiltert wird. Muss ich nach Linz *via Gra*z fahren?
- Prüfung auf Massenversand
Sinnvoll.
- CAPTCHAs
… finde ich geil. ;-)
Weiterer Vorschlag: Prüfung der Linkanzahl bzw. der Relation zum restlichen Text. Die wenigen Spam-Einträge, die es bisher ins Weblog geschafft haben (ca. einer pro Woche) enthielten mehr als zehn Links und kaum sonstigen Text.
Grüße
Roland
Hallo.
Weiterer Vorschlag: Prüfung der Linkanzahl bzw. der Relation zum restlichen Text.
Stimme ich zu. Auf die Idee kam ich inzwischen auch. Und auch bei mir hat sich sich (bislang) bewährt.
Bleibt nur abzuwarten, wann die Bots dann ihre URLs mit Buchstabensalat auffüllen...
Grüße aus Würzburg
Julian
hi,
Weiterer Vorschlag: Prüfung der Linkanzahl bzw. der Relation zum restlichen Text. Die wenigen Spam-Einträge, die es bisher ins Weblog geschafft haben (ca. einer pro Woche) enthielten mehr als zehn Links und kaum sonstigen Text.
Und wenn ich dir in einem Kommentar weitere Links zu der Thematik über die du dich gerade bloggenderweise ausgelassen hast präsentieren möchte, ohne dabei allzu viele Worte zu verschwenden?
gruß,
wahsaga
Hallo wahsaga,
Prüfung der Linkanzahl bzw. der Relation zum restlichen Text.
Und wenn ich dir in einem Kommentar weitere Links zu der Thematik über die du dich gerade bloggenderweise ausgelassen hast präsentieren möchte, ohne dabei allzu viele Worte zu verschwenden?
Der Begriff „Verschwendung“ irritiert mich. Da ich unverschämt eine ansprechende Präsentation deiner Leseempfehlungen und somit eine gewisse Wertschätzung meiner beschwerlich geordneten und formulierten Gedanken erwarte, wirst du wohl nicht umhinkommen, dir damit etwas Mühe zu geben.
Grüße
Roland
Weiterer Vorschlag: Prüfung der Linkanzahl bzw. der Relation zum restlichen Text. Die wenigen Spam-Einträge, die es bisher ins Weblog geschafft haben (ca. einer pro Woche) enthielten mehr als zehn Links und kaum sonstigen Text.
Finde ich aus gleichen Gründen wie wahsaga erstmal bedenklich. Wenn man jedoch eine weitere Prüfung/Maßnahme hinterher schicken könnte, die nur dann erscheint, wenn eine zu hohe Linkdichte erkannt wurde, hätte der normale Nutzer, der dir 10 tolle Links senden will, weiterhin die Möglichkeit, damit durchzukommen.
Viele Grüße!
_ds
Hallo.
Die Liste der zu kombinierenden Maßnahmen stimmt doch schon recht zuversichtlich.
Als zusätzliches Mittel ist mir Javascript noch ganz sympathisch, um zumindest feststellen zu können, ob das Formular von einem Menschen an einem Browser mit aktiviertem Javascript ausgefüllt worden ist. Diese Formularinhalte könnten sicher schon als weit weniger bedenklich eingestuft werden, so dass Captchas, Rechenaufgaben oder andere Rätsel sowie vielleicht auch die Vorschau oder die Abfrage von Spammer-Listen entfallen könnten, sobald Mausbewegungen oder Tastendrücke registriert werden.
MfG, at
Als zusätzliches Mittel ist mir Javascript noch ganz sympathisch, um zumindest feststellen zu können, ob das Formular von einem Menschen an einem Browser mit aktiviertem Javascript ausgefüllt worden ist.
Gute Idee, aber ich bin mir nicht sicher, ob man das Feature Javascript sinnvoll nutzen kann, um Bots auszuschließen. Letztere sind vermutlich auch in der Lage, JS zu interpretieren. An welche Maßnahmen/Prüfungen denkst du dabei konkret? Mir kam beim Lesen deines Postings etwa in den Sinn, bestimmte Inhaltsbereiche und/oder Hidden Fields erst durch JS zu aktivieren, um sie danach auszuwerten, oder aber den Submit-Button auszutauschen und mit zusätzlichen Parametern zu versehen: das alles hat aber nicht die gewünschte Wirkung, wenn auch der Bots JS interpretiert.
Viele Grüße!
_ds
Hallo.
An welche Maßnahmen/Prüfungen denkst du dabei konkret? Mir kam beim Lesen deines Postings etwa in den Sinn, bestimmte Inhaltsbereiche und/oder Hidden Fields erst durch JS zu aktivieren, um sie danach auszuwerten, oder aber den Submit-Button auszutauschen und mit zusätzlichen Parametern zu versehen: das alles hat aber nicht die gewünschte Wirkung, wenn auch der Bots JS interpretiert.
Ich dachte eher an subtilere Methoden wie die regelmäßige Übergabe von Cursor-Koordinaten oder die Übermittlung von Tastendrucken. Das hätte den Vorteil, dass man server-seitig entscheiden könnte, welche Werte man für plausibel hält. Wenn etwa weder der Bereich um zwei Felder herum mit dem Cursor berührt, noch die Tabulatortaste betätigt wird, aber beide Felder inhaltlich verändert worden sind, sprich das gegen einen menschlichen Nutzer. Ähnliches gilt für weitgehend konstante Mausbewegungen, Mausbewegungen während schnellen Tippens etc.
Um versehentliche Fehleinschätzungen auszuschließen könnte man die einzelnen Kriterien auch beim Absenden server-seitig gewichten und verrechnen. Viel Aufwand, aber Captchas werden ja auch keine Handarbeit.
Noch ein Schuss aus der Hüfte: Mausberührung oder Tastendruck ändert Klasse des berührten Objektes. -> Über den CSS-Selektor ändert sich die Eigenschaft eines Tochterelementes. -> Eigenschaft des Tochterelementes wird ausgelesen. Damit müsste der Bot zumindest Javascript beherrschen, CSS interpretieren können, und wissen, wie sich welche Eigenschaften auf Tochterelemente auswirken. Der Autor allerdings auch.
MfG, at
Auge