In my previous post on CAPTCHAs I mentioned that “…you need to make sure the end user can’t do anything to influence what code you pick.”

For this example, I will pick on captchas.net, which provides a free CAPTCHA service for anyone to use on their web site. While this is pretty cool of them to provide this for free, there is a serious flaw with their implementation. In fact, it is actually a flaw I have seen more than once in some form or another.

The problem with captchas.net is that they allow you to set your CAPTCHA parameters on the image URL. The parameters you can set include the length of the CAPTCHA and the character set used.
Now my first thought is what would happen if we say we only want one letter and we only want the letter Z? We might use this URL as the CAPTCHA image:

http://image.captchas.net?client=demo&random=&alphabet=z&letters=1

This will return an image like this:

captcha

As you can see, by modifying the client-side source code, you can make sure the CAPTCHA is always just the letter Z. For any of you who haven’t caught on so far, that means we always know the answer to the CAPTCHA will also always be the letter Z. This client-side modification could even be done automatically with a browser plugin or as part of an automated script.

I do, however, need to mention that there are ways to still use captchas.net and make it secure. The key is to track the CAPTCHA secret on the server side to be able to detect any client-side modification. If using asp.net, it might also help to use viewstate with a MAC.

No tag for this post.