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