FreeLists / dokuwiki / [dokuwiki] Re: Anti spam brainstorming

[Andreas Gohr <andi@xxxxxxxxxxxxxx>]

On Thu, 9 Nov 2006 22:59:00 +0100
Andreas Gohr <andi@xxxxxxxxxxxxxx> wrote:

> Ed writes: "So far I have been successful by using a session variable
> that is set when the form is requested via http get. If the submitted
> form doesn't have the session variable set, I dump the email and
> return a bogus error message."
> 
> Another idea could be to create such a verification key automatically
> from some browser user data and an encryption key - like the one we
> use to protect the auth cookie from being stolen. This could really
> work :-)

I'm thought more about this... My idea was to use something like this
to be generated as additional hidden field, which then is checked later
again on save:

md5(auth_browseruid().auth_cookiesalt().$ID);

This is a first start but has a problem. It's replayable, because for
one page it's always the same result. To fix this we could add the
timestamp of the most current revision:

md5(auth_browseruid().auth_cookiesalt().$ID.$INFO['lastmod']);

This should fix script like the ones I described in my last mail. But
looking at my access logs, the spammer seems to fetch the form for each
submit. There always a GET to the page, then a POST (to access the edit
form), then a POST to save, then a GET (redirect after saving). The
user agent is most probably fake but it identifes it self as FireFox.

While I was looking at this, I had another thought. Couldn't a spammer
write a FireFox extension to do his spamming? It would create a spam
tool which exactly behaves like a real browser. Including accepting
cookies and keeping session variables.

I fear here we are at a dead end again (if we don't want to add a
captcha to the above verification key). *sigh* it looked promising.

Andi

-- 
http://www.splitbrain.org