Comments on: Bad Information

By: Chris Shiflett

Chris Shiflett — Tue, 26 Aug 2008 01:36:56 +0000

Dragos is right, but the truth is that there’s no risk in someone using cURL instead of a regular browser, as long as you enforce good rules. Any good security practice considers the fact that a user can manipulate anything in the request.

The practice you describe is for preventing CSRF:

http://shiflett.org/articles/cross-site-request-forgeries

I hope this helps.

By: jgm

jgm — Thu, 03 Jul 2008 13:16:15 +0000

@Dragos,
Yes session hijacking is still an issue, but so long as you destroy the session after processing, it makes the spammer’s job more difficult, they will have to repeatedly visit the initial page to generate a new valid session before hitting the processing page. Checking the submission count and rate will make it even harder. Getting around this version will be significantly more difficult that one that simply looks at the referrer string, which is much more trivial to bypass than stealing a cookie.

By: Dragos

Dragos — Wed, 02 Jul 2008 16:32:06 +0000

Using the same Curl you “blame” that can be used to change REFERER , you can simulate session (capture cookie and use it). Your solution it’s not better than using REFERER variable: both are useless if someone really wants to get in. I found no solution for this issue, that’s why I read your post ;) – and still I have no solution.

By: jgm

jgm — Mon, 30 Jun 2008 01:37:40 +0000

JavaScript is definately an option, and one that I commonly employ on client websites to prevent spam submissions. Though rather than use it as you have described I normally use it to re-write the submission form’s action attribute, from a bogus target to the normal one. This will foil just about all of the normal comment form spammers out there. The bots cant parse javascript and the sweatshops don’t normally to minimize bandwidth use. That combined with a session based approach will eliminate virtually all the spam comments currently. Though I imagine that it will only be a matter of time before we start seeing spam bots that can and will take the time to parse javascript.

By: seb

seb — Sun, 29 Jun 2008 04:40:39 +0000

Another interesting approach I’ve seen is to use Javascript to populate a verification field in your form with some pre-computed value that you can reproduce server-side.

This of course is a problem for users who don’t have Javascript, but really, who doesn’t have Javascript these days?