This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Testing for Captcha (OWASP-AT-012)

From OWASP
Revision as of 00:33, 18 November 2013 by Wilder (talk | contribs) (Description of the Issue)

Jump to: navigation, search
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 considered to be an ineffective security mechanism!

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:
Image2.jpeg
Price: US¢1.390
Uploaded: Sun Nov 17 20:03:13 2013
Solved: Sun Nov 17 20:03:23 2013
Text: 270 35524452

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 above-described CAPTCHA weaknesses, it can be still used against:

  • simple 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 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
  • 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

Black Box testing and example

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

References

Whitepapers
...
Tools
...