How to Bypass CAPTCHA/Spam filters (and Stop it!)

[CaffeineCoder]

OK, here's a question for anyone willing to step up and answer or point to solution:

I have some HTML forms for site visitors to request product information. Some of these forms send data to SalesForce. There has been an issue of spam coming through, so I have implemented CAPTCHA's via php (code created as an image), and have also gone through and setup additional checks on the form's fields. These checks are verifying that fields aren't blank, don't contain a url (a common item in the spam), and that email address is in proper form. In testing, there is no way to bypass these checks, but somehow things have gotten through. Does anyone have any thoughts/ideas/ etc for something like this? I figure there's bound to be someone who has experienced a similar scenario. I'm also blocking IP's that have been attempting brute force attacks, but am looking for a more proactive vs reactive solution.

[gentlemedia]

Have you tried the new reCaptcha from Google yet?
https://www.google.com/recaptcha/intro/index.html

[CaffeineCoder]

will look at that, but what about how spammers can get URL in the text when it's checking for it? (Setup to look for http in any part, such as frgafsfshttpfdsafds, etc). I know there is software as well as businesses that will handle getting past a CAPTCHA, but if I test a form to not allow a certain piece of text, find it works, and then later some gets through, I'd like to know how things are able to get past, what is getting changed, etc.

[Traevel]

Any JavaScript validation is vulnerable. Use server side validation on all fields before allowing it.

[CaffeineCoder]

Thanks. Any idea what type(s) of vulnerability?

[Traevel]

Well, disabling JavaScript for starters.

But also altering your page through the browser, creating my own version of the page and having it send data to yours, or even bypassing the front-end altogether and just send data to the server. Never let the server trust what's coming in.

Assume the data that reaches the server can be wrong, and validate at a point where it can't be changed anymore. Right before it goes into the database for example.

[CaffeineCoder]

Makes sense. Similar concept to SQL Injections and legacy ASP, etc. I thought Ajax would be stronger than js since Ajax communicates as a "bridge" between server and client. May have to rewrite this is PHP, but hope it'll only be validation.

[almostbob]

leave the form as it is
validate in the form handler, serverside
let the scumbags think they have bypassed the checks and balances and they will give up, thinking their crap has gone through

ajax:

• anything containing javascript, can be recoded by the user;
• is not for form submission or validation,
• is for one-way page updates server->user in response to user triggers

[CaffeineCoder]

Thinking I may just have to remove the Ajax component altogether and try just pure php. Thing is, the Ajax is what is creating the XMLHttpRequest object, checking readystate, and communicating with the related php files.