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
Difference between revisions of "Testing for Captcha (OWASP-AT-008)"
| Line 19: | Line 19: | ||
<br> | <br> | ||
| − | CAPTCHA implementations | + | These vulnerabilities are quite common in many CAPTCHA implementations: |
| − | + | ||
| − | * generated CAPTCHA | + | * generated CAPTCHA are weak, this can be identified (without any complex computer recognition systems) only by a simple comparison with already broken CAPTCHAs |
* the value of decoded CAPTCHA is sent by client (as a GET parameter or as a hidden field of POST form). This value is often: | * the value of decoded CAPTCHA is sent by client (as a GET parameter or as a hidden field of POST form). This value is often: | ||
| − | 1) encrypted by simple algorithm and can be easily decrypted by observing of multiple | + | 1) encrypted by simple algorithm and can be easily decrypted by observing of multiple decoded CAPTCHA values |
2) hashed by weak hash function (e.g. MD5) and can be broken using a rainbow table | 2) hashed by weak hash function (e.g. MD5) and can be broken using a rainbow table | ||
| − | * | + | * possibility of replay attacks: |
| − | the appropriate CAPTCHA image and it's ID, solve it and send old | + | 1) the affected application does not keep track what ID of CAPTCHA image is sent to the user. Therefore the attacker can simple retrieve |
| − | + | the appropriate CAPTCHA image and it's ID, solve it and send old value of decode CAPTCHA and its corresponding ID) | |
| − | + | 2) the application does not destroy the session when the correct phrase is entered - by reusing the session ID of a known CAPTCHA it is possible to bypass CAPTCHA protected page | |
| − | + | ||
| − | |||
<br> | <br> | ||
| Line 44: | Line 43: | ||
* try to send old decoded CAPTCHA value with old session ID (if the application accepts it, it is vulnerable to replay attacks) | * try to send old decoded CAPTCHA value with old session ID (if the application accepts it, it is vulnerable to replay attacks) | ||
| − | Find out if the similar CAPTCHAs are already broken, broken CAPTCHA images can be found | + | Find out if the similar CAPTCHAs are already broken, broken CAPTCHA images can be found here [http://www.cs.sfu.ca/~mori/research/gimpy/ez/ gimpy], [http://libcaca.zoy.org/wiki/PWNtcha PWNtcha], [http://www.lafdc.com/captcha/ lafdc]. |
== Gray Box testing and example == | == Gray Box testing and example == | ||
Revision as of 21:55, 28 July 2008
OWASP Testing Guide v3 Table of Contents
This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.
OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here
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. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the generated CAPTCHA is unbreakable. This section will help you to identify these kinds of attacks.
Description of the Issue
Although CAPTCHA is not an authentication control, its use can be very efficient against:
- 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
Using CAPTCHAs as a CSRF protection is not recommended (because there are stronger CSRF countermeasures).
These vulnerabilities are quite common in many CAPTCHA implementations:
- generated CAPTCHA are weak, this can be identified (without any complex computer recognition systems) only by a simple comparison with already broken CAPTCHAs
- the value of decoded CAPTCHA is sent by client (as a GET parameter or as a hidden field of POST form). This value is often:
1) encrypted by simple algorithm and can be easily decrypted by observing of multiple decoded CAPTCHA values 2) hashed by weak hash function (e.g. MD5) and can be broken using a rainbow table
- possibility of replay attacks:
1) the affected application does not keep track what ID of CAPTCHA image is sent to the user. Therefore the attacker can simple retrieve the appropriate CAPTCHA image and it's ID, solve it and send old value of decode CAPTCHA and its corresponding ID) 2) the application does not destroy the session when the correct phrase is entered - by reusing the session ID of a known CAPTCHA it is possible to bypass CAPTCHA protected page
Black Box testing and example
Use intercepting fault injection proxy (e.g. WebScarab to:
- identify all parameters that are sent in addition to the decoded CAPTCHA value from the client to the server (these parameters can contain encrypted or hashed values of decoded CAPTCHA and CAPTCHA ID number)
- try to send old decoded CAPTCHA value with old CAPTCHA ID (if the application accepts it, it is vulnerable to replay attacks)
- try to send old decoded CAPTCHA value with old session ID (if the application accepts it, it is vulnerable to replay attacks)
Find out if the similar CAPTCHAs are already broken, broken CAPTCHA images can be found here gimpy, PWNtcha, lafdc.
Gray Box testing and example
Audit the application source code in order to reveal:
- used CAPTCHA implementation and version - there are many known vulnerabilities in widely used CAPTCHA implementations, see http://osvdb.org/search?request=captcha
- if the application sends encrypted or hashed value from the client (which is a very bad security practice) verify if used encryption or hash algorithm is sufficiently strong
References
Captcha Decoders
Articles
