Difference between revisions of "Testing for Captcha (OWASP-AT-012)"

Revision as of 00:45, 18 November 2013

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

WARNING: CAPTCHA protection is an ineffective security mechanism and should be perceived as a "rate limiting" protection only!

Most current used CAPTCHA images can be easily cracked in a fully automated way using many commercial or opensource services. Commercial services are usually very cheap and provide a simple API for most programming languages.
It is not recommended to use CAPTCHA protection for security-critical applications, in this case it is more suitable to use SMS text messages or OTP tokens instead.

Example of Google reCAPTCHA cracked in 7 seconds by commercial automated cracking service:

Price: US¢1.390
Uploaded: Sun Nov 17 20:03:13 2013
Solved: Sun Nov 17 20:03:23 2013
Text: 270 35524452

Most CAPTCHA images can be cracked in 1-15 seconds, therefore CAPTCHA should be perceived as a rate limiting protection only which stops the attacker for a limited amount of time.

Brief Summary

CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer.

Description of the Issue

Despite the above-described CAPTCHA weakness, it can be still used against:

• automated sending of many GET/POST requests in a short time where it is undesirable (e.g., SMS/MMS/email flooding), CAPTCHA provides a rate limiting function
• enumeration attacks (login, registration or password reset forms are often vulnerable to enumeration attacks - without CAPTCHA the attacker can gain valid usernames, phone numbers or any other sensitive information in a short time)
• automated creation/using of the account that should be used only by humans (e.g., creating webmail accounts, stop spamming)
• automated posting to blogs, forums and wikis, whether as a result of commercial promotion, or harassment and vandalism
• any automated attacks that massively gain or misuse sensitive information from the application
• simple enumeration attacks and less sophisticated attackers

Black Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...