Discussion:
Gefragt: Erfahrungen mit Web-Spam
(zu alt für eine Antwort)
Martin Lemke
2007-01-10 20:31:34 UTC
Permalink
Was mich mal hinsichtlich Gästebuch-, Foren- und Blog-Kommentar-Spam
interessieren würde, sind die Erfahrungen damit. Besteht das Spam-Problem
nur bei Standard-Software (also typischerweise Open source-Software) oder
auch bei selbst entwickenten Lösungen?

In ersterem Fall würde es den Spammern ja genügen, die Parameter der
jeweiligen Software zu kennen (z. B. für Wordpress oder phpBB), um per Post
request beliebig viele Kommentare bzw. Beiträge an den URL posten zu
können.

Ein individuelles Formular zu analysieren, bereitet etwas mehr Aufwand,
wobei dies nicht unmöglich ist. Da Spamming und Despammiung immer auch
einen Wettlauf darstellt, bedeutet dies natürlich, dass Algorithmen, die
heute greifen, schon morgen unwirksam sein können.

Hintergrund meiner Frage: Derzeit könnte die Umbenenntung von
Formularfeldern von Standardsoftware noch immer einen wirksamen
Schutzbieten.

Beispiel punBB:
Das Feld für den Usernamen heißt $_POST['req_username']. Benennt man dieses
Feld um zu meinetwergen $_POST['username'] fällt jeder Spammer bei der
Längenprüfung des Usernamen durch, weil nichts ankommt und folglich sind
Spammer, die die Standardfeldnamen zur Grundlage nehmen, ausgegrenzt.

Das ist auf jede ander Standardsoftware übertragbar. Aber es ist zu
erwarten, dass diese Lösung möglicherweise nicht bis alle Ewigkeit
funktioniert. Aber derzeit scheint das noch eine wirksame Strategie
darzustellen.

Vorteil dieses Verfahrens: Es gibt praktisch keine false positives.

Martin
--
homepage: http://newblog.maaaddin.de/
feed: http://newblog.maaaddin.de/rss/descfeed.xml
Andreas Kohlbach
2007-01-10 22:27:23 UTC
Permalink
Post by Martin Lemke
Was mich mal hinsichtlich Gästebuch-, Foren- und Blog-Kommentar-Spam
interessieren würde, sind die Erfahrungen damit. Besteht das Spam-Problem
nur bei Standard-Software (also typischerweise Open source-Software) oder
auch bei selbst entwickenten Lösungen?
Zumindest in meinem alten Gästebuch hat es fast keinen Spam gegeben,
obwohl, wenn man nach den passenden Begriffen sucht, meine Webseite bei
Google unter den ersten 5 in der Regel kommt.

Weiter hat das Gästebuch sonst eine aprove Funktion, dass ich die
Einträge erst prüfe und dann frei schalte. Obwohl ich das komischerweise,
weil eben kaum Spam in den letzten 10 Jahren kam, nicht bräuchte.

Vielleicht nach Anbietern Ausschau halten, die dieses anbieten.
--
Andreas
PGP Key available on public key servers
Mailfilter rules http://www.tombstones.org.uk/~ankman/filterrules.html
Thomas Hochstein
2007-01-11 09:43:35 UTC
Permalink
Post by Martin Lemke
Was mich mal hinsichtlich Gästebuch-, Foren- und Blog-Kommentar-Spam
interessieren würde, sind die Erfahrungen damit. Besteht das Spam-Problem
nur bei Standard-Software (also typischerweise Open source-Software) oder
auch bei selbst entwickenten Lösungen?
Seit einiger Zeit auch bei selbstentwickelten Lösungen;
Kontaktformulare und Gästebücher werden entsprechend zugemüllt.
Offenbar werden die Seiten vorher auch gezogen und geparsed, denn es
bringt nichts, einfache Codefelder unterzubringen (bspw. ein
"hidden"-Feld, in dem Datum/Uhrzeit des Abrufes kodiert sind, und dann
zu prüfen, ob der POST-Request in einem vernünftigen Zeitraum danach
liegt). Bloße Umbenamsung der Felder hilft also auch nicht weiter.
Post by Martin Lemke
Hintergrund meiner Frage: Derzeit könnte die Umbenenntung von
Formularfeldern von Standardsoftware noch immer einen wirksamen
Schutzbieten.
Ich zweifele etwas daran.
Post by Martin Lemke
Das ist auf jede ander Standardsoftware übertragbar. Aber es ist zu
erwarten, dass diese Lösung möglicherweise nicht bis alle Ewigkeit
funktioniert. Aber derzeit scheint das noch eine wirksame Strategie
darzustellen.
Was derzeit noch geht: Erwarteten Inhalt der Felder parsen, und
einfache Prüfabfragen ("Geben Sie folgende Zeichenfolge ein") statt
Captchas, d.h. Abfragen, die theoretisch durch einen Computer genauso
gut zu beantworten sind wie durch einen Menschen, die aber einen - auf
den Einzelfall zugeschnittenen - Programmieraufwand erfordern. Damit
habe ich den Spamanteil praktisch auf null gesenkt; diejenigen
Webpräsenzen, bei denen ich noch nicht zu dieser Maßnahme gekommen
bin, haben immer noch zweistellige Spameingänge täglich.

Bei Standardsoftware helfen interessanterweise Standardmaßnahmen, die
man praktisch ohne Konfigurationsaufwand per Click aktivieren kann;
mein Blog ist seit Monaten spamfrei (Captchas für Kommentare, die
älter sind als x Tage; IP-Filter; einfache Wortfilter; Akismet).

-thh
Leonard Orb
2007-01-11 14:37:19 UTC
Permalink
Post by Thomas Hochstein
Offenbar werden die
Seiten vorher auch gezogen und geparsed, denn es bringt nichts, einfache
Codefelder unterzubringen (bspw. ein "hidden"-Feld, in dem Datum/Uhrzeit
des Abrufes kodiert sind, und dann zu prüfen, ob der POST-Request in
einem vernünftigen Zeitraum danach liegt). Bloße Umbenamsung der Felder
hilft also auch nicht weiter.
Ich würde ja für Leute mit aktiviertem Javascript ein hidden-Input
übermitteln, dessen value erst beim Client stimmig berechnet wird. Das
sollte die meisten Spammer vor ernste Probleme stellen.

Die anderen User können trotzdem noch über ein Captcha verifiziert
werden.

Leo
Jens Müller
2007-02-12 00:08:49 UTC
Permalink
Post by Leonard Orb
Ich würde ja für Leute mit aktiviertem Javascript ein hidden-Input
übermitteln, dessen value erst beim Client stimmig berechnet wird. Das
sollte die meisten Spammer vor ernste Probleme stellen.
Und die Berechnung darf dann auch gerne ordentlich kompliziert sein,
irgendein Standardfall für "proof of computational effort" halt.
Daniel Rehbein
2007-02-16 22:25:41 UTC
Permalink
Post by Leonard Orb
Post by Thomas Hochstein
Offenbar werden die
Seiten vorher auch gezogen und geparsed, denn es bringt nichts, einfache
Codefelder unterzubringen (bspw. ein "hidden"-Feld, in dem Datum/Uhrzeit
des Abrufes kodiert sind, und dann zu prüfen, ob der POST-Request in
einem vernünftigen Zeitraum danach liegt). Bloße Umbenamsung der Felder
hilft also auch nicht weiter.
Ich würde ja für Leute mit aktiviertem Javascript ein hidden-Input
übermitteln, dessen value erst beim Client stimmig berechnet wird. Das
sollte die meisten Spammer vor ernste Probleme stellen.
Die anderen User können trotzdem noch über ein Captcha verifiziert
werden.
Und was ist mit Nutzern, die sich Inhalte z.B. mit Hilfe eines
Textbrowsers vorlesen lassen?

Daniel Rehbein
www.daniel-rehbein.de
Leonard Orb
2007-02-17 17:27:05 UTC
Permalink
Post by Daniel Rehbein
Post by Leonard Orb
Die anderen User können trotzdem noch über ein Captcha verifiziert
werden.
Und was ist mit Nutzern, die sich Inhalte z.B. mit Hilfe eines
Textbrowsers vorlesen lassen?
Ein Captcha ist ein Test, der einen Menschen als solchen identifiziert, ohne
einen zweiten Menschen als Tester vorauszusetzen.
Es liegt im Ermessen des Captcha-Betreibers, das so zu gestalten, daß es
möglichst für jeden Anwender technisch funktioniert und trotzdem zuverlässig ist.

Leo
Andreas M. Kirchwitz
2007-02-17 20:33:53 UTC
Permalink
Post by Leonard Orb
Post by Daniel Rehbein
Post by Leonard Orb
Die anderen User können trotzdem noch über ein Captcha verifiziert
werden.
Und was ist mit Nutzern, die sich Inhalte z.B. mit Hilfe eines
Textbrowsers vorlesen lassen?
Ein Captcha ist ein Test, der einen Menschen als solchen identifiziert, ohne
einen zweiten Menschen als Tester vorauszusetzen.
Nein, das ist falsch. Ein Captcha ist ein Turing-Test, um Menschen
und Computer zu unterscheiden. Beispielsweise bei den seit Jahren recht
beliebten "verborgenen" Texten in Bildern läuft das so: Wird der Text
überwiegend richtig erkannt, hat man es mit einem Computer zu tun.
Wird maximal die Hälfte erkannt, ist's ein Mensch. Wird nichts erkannt,
ist Knut, das tapsige Eisbärkind aus dem Berliner Zoo, über die Tastatur
gelaufen.
Post by Leonard Orb
Es liegt im Ermessen des Captcha-Betreibers, das so zu gestalten, daß es
möglichst für jeden Anwender technisch funktioniert und trotzdem zuverlässig ist.
Brauchbare Captchas müssen wohl erst noch erfunden werden ...

Grüße, Andreas

Lesen Sie weiter auf narkive:
Loading...