PHP and AJAX security

[markis]

I'm designing a user-friendly captcha (created and served via PHP) for general use.  The idea is that, if the user is not a bot, Javascript will perform a request to the server and fill in the captcha field, saving the user time and irritation.  I was hoping someone here could identify some of the more blatant security flaws in this beta design:

 

• PHP-scripted Contact form page loads.  Session starts.  Page requests a captcha image, which is generated on request.  Both a session cookie and a regular cookie are set (via PHP, not JS).
   
  
• As the user types into the form, JS makes a request to the PHP captcha page for the captcha solution.
   
  
• The captcha page checks for both cookies.  If they exist as expected, it echos the solution.
   
  
• Once the user submits the form, the captcha image, the solution, and both cookies are destroyed.  Of course, the solution is checked, and the form results are emailed, stored, or whatever.

 

I know this all opens up a lot of security problems, but it's intended for low-spam sites with a penchant for user-friendliness.  I would just like to make it as secure as possible.  Any thoughts?

 

The page is www.markraymondmason.com/AAcontactform.php if you're interested in trying to hack it or anything.    In the end, the captcha will be hidden, shown only if something goes wrong.

[redbullmarky]

...The idea is that, if the user is not a bot, Javascript will perform a request to the server and fill in the captcha field, saving the user time and irritation.

 

I might just be short of a few bits of education or might be being stupid, but surely the whole point of captcha is to determine whether the user is a bot or not, as opposed to just trying to irritate the user? If you have ways other than the captcha of finding out what sort of user they are, enough to fill in the captcha form for them, then surely you can just do away with the captcha altogether?

[Liquid Fire]

if you can detect that a user it not a not I would love to know how.

[448191]

Won't work. A bot will have the the cookies set too, thus can easily query for the solution. Just making the spammers' job easier.

 

The bottom line is that without human interaction you can't tell CHA.

[markis]

OK, right, that was worded in a confusing way.  :-\ 

 

The whole thing really hinges on bots not being able to run Javascript.  I thought that, without JS, a robot couldn't make the AJAX query.  Of course, if they can run JS, the whole thing is sunk.  redbullmarky, the captcha is there in case the user has JS turned off, or for some other reason can't do AJAX.

 

448191, point well taken.  I assumed bots couldn't set session cookies.  There goes that.

 

Can bots run JS?  Is there anything else I could test for to find out if a traditional browser or a robot is making the query?  It's OK if it assumes a user is a bot sometimes - all that will happen is the user will have to fill out the captcha.

[markis]

Oh, I should also mention that, to make the query, some information unique to that particular load of the page needs to be included.  This info can only be collected via JavaScript, so the bot must run JS to hack the captcha.

 

So, can bots run JavaScript?

[448191]

I don't see why not. A bot is a program. It's as sophisticated as one makes it. That said, there really isn't any information that can't be deducted/spoofed. If aimed specifically at your script, an attacker WILL be able to emulate the resulting request, even without a full JavaScript interpreter.

 

Again, without human interaction you can't tell CHA.

[markis]

OK, fair enough.  Is there really NO way?  The trouble with human interaction is that people can be so unpredictably, well, stupid sometimes.  I run an international site, so questions like "which month comes after May?" don't work.  Even simple math is hard for some people, ie "what is 2 + 7?"  And captchas are tough to read.  Whatever the instruction is, however simple it may seem, I'd bet 10% of users would screw it up at least once (which would frustrate them), and 1% wouldn't be able to do it at all.

 

Testing for bots behind the scenes is tough too.  The ones targeting my site were very weird, moving slowly and quickly, submitting blank forms or ones full of gibberish.  No easy way to tell them from people by checking the form contents...most didn't even submit urls.

 

Is there nothing that, in the course of filling out a web form, a person would do that a bot absolutely couldn't?  What about mouse movements?  Keypresses?  Scrolling?  Any other ideas?  Maybe a simple point-and-click JS 'game' that's replaced by a captcha if the user has JS turned off?

 

 

[448191]

No. You will of course fend off some bots.

 

Apparently, more people are relying on the presumption that spambots can't execute javascript:

 

Resultaten 181 - 190 van circa 1.910.000 voor This email address is being protected from spam bots' date=' you need Javascript enabled to view it. (0,22 seconden) [/quote']

 

I would suggest a multiple line of defense:

 

1) Deny requests from known spambots. You could even do a periodical update from the RSS feed on www.projecthoneypot.com

2) A post-spamfilter

3) A CAPTHA

 

You could use the CAPTHA to give users a chance to prove they're in fact not bots, even after the spamfilter has identified (suspected) spam. You can also require a CAPTCHA if the user posts often in a limited amount of time: flood control. You can also think up different implementations of this combination of defenses. For example, you could start with a very sensitive spamfilter and a very easy CAPTCHA. If the spamfilter triggers, increase the CAPTCHA difficulty.

[websiterepairguys]

...I'd bet 10% of users would screw it up at least once (which would frustrate them), and 1% wouldn't be able to do it at all.

 

So the question here is, are you coding your site for the remaining 89 percent, or the 11 percent that are unable to pass simple captchas?

 

Here's what I would do (and this is my standard implementation):

 

When the form is loaded, pull in the question / MD5 value of the answer from from a random list (admin edited).  For multilingual sites, this can have a question for each language, etc..

 

Display the question via javascript document.write

 

when the user enters the answer, compare the MD5 of his answer with the already known md5 of the correct answer.

 

This a simple and effective captcha, even better then the images (which Im finding harder and harder to read).  Take for example the captcha for this forum.  It was incredibly small and doesn't take into account people with disabilities (with the exception of the listen function).

 

Its funny, we put all this work into keeping bots out, and we can do nothing to keep some human from doing it manually.

 

Regards,

Mark

 

 

[markis]

OK, thanks a lot for all your help, guys.  That clears a lot of things up and gives me a lot of ideas for the future.

 

I've decided to stick with the captcha for now.  I will soon employ other methods like you suggested, 448191, and hopefully move into using the captcha more as a backup, or in parallel with other methods.

 

I have, however, taken some steps to make the captcha easier for people:

 

• It's big, high contrast, in a serif font, and has no noise in the background.  Apparently, noise and low contrast images make little difference for OCR anyway.  The letters usually overlap, which tends to frustrate OCR, or so I'm told.  I'm pretty sure OCR would be a pretty inefficient way to spam web forms.
  
• The sequence of letters is short and somewhat "pronounceable".  The words are nonsense, but form strings that would be easy to type.  IE: "TOOR" is easier to type than "XJBM".  It's interesting what even this simple algorithm comes up with - some good kids names in there!

 

In the end, actually, it's all a bit silly.  My site is based around the art of photography - I'm pretty sure it won't be that popular with the visually impaired anyway!

 

Here's the result, still pending some minor changes: http://www.markraymondmason.com/contactform.php.

 

Thanks again,

 

    - markis.