[dokuwiki] Re: Anti spam brainstorming
- From: Andreas Gohr <andi@xxxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Thu, 9 Nov 2006 23:28:38 +0100
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
Other related posts:
