Web Development

What is CAPTCHA?

CAPTCHA is an acronym for “completely automated public Turing test to tell computers and humans apart.” This can be with images / audio or whatever we will see in future.

Why do sites use it?

CAPTCHA is used to prevent bots from automatically submitting forms with SPAM or other unwanted content. Google and other companies use it to prevent bots from creating multiple Gmail accounts.

What is wrong with it?

Users will have to enter this additional information every time they have to submit a form. This is getting more and more difficult to decode for humans as the bots are getting better at it. I am sure that everyone reading this post has atleast once got a CAPTCHA entered wrongly.

Alternative Simple soultion:

NOTE: Does not apply for highly targeted sites like gmail, yahoo mail and others alike.

However,
If you have a sales form which requires an entry of username, email and phone number for a call back
OR
a simple contact us form with just name, number, description.

1) Have server validation of data.
All the forms have only client validation in javascript. Just validate in server and you can have 70% of spam bot submissions caught.
EG: If your form has Name, Email, Telephone.
The bot will send some 500 character text in Name and valid email and some random data in phone field. A simple validation on the server to trash Name having more than 30 characters will do the trick.

2) Hidden input element
Add an extra text input element to your form. In an external style sheet you set the element to display: none; thus making it invisible to all users with CSS enabled. Spam bots will usually fill all fields in a form you know that any forms submitted where this invisible field is not empty are spam.

With the above two simple steps you can see that most sites can avoid spam messages and still not having to use a captcha.

So in short – for all the websites with simple contact forms why do we use CAPTCHA and risk giving the customer an additional field to fill and risk not to getting them to fill it at all ??

Session fixation attacks attempt to exploit the vulnerability of a system which allows one person to fixate (set) another person’s session identifier (SID). Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs (query string) or POST data.

Example of such an attack: Lets take an example of a banking website which provides login to access banking features. (this can be any site which allows users to login).
EG: http://www.poorbanking.com

1) Hacker
Creates a very a link and sends visitors to the site as http://www.poorbanking.com/index.php?PHPSESSID=1234
Lets assume PHPSESSID is the name of the cookie / variable used to store session information. It is very easy for anyone to find this by just visiting the site once.

2) Hacker sends link to the target user.
http://www.poorbanking.com/index.php?PHPSESSID=1234 by email or placed in a blog etc.

3) Victim
Sees the link and clicks on it. The site looks genuine and the victim logs in to the site. At this stage the PHPSESSID is set to PHPSESSID=1234 and user is logged in.

4) The happy hacker
Hacker can keep checking if they can login by simply going to http://www.poorbanking.com/showmeaccount.php?PHPSESSID=1234
where showmeaccount.php is the page after login. They can see that once the user has logged in they can easily get access to the page.

Work around to this problem

Just prior to setting such a session variable, a call to session_regenerate_id() can help to protect against a session fixation attack.

See more information at http://en.wikipedia.org/wiki/Session_fixation