We have seen a lot of DoS (Denial of Service) attacks in recent times. An old but promising solution to DoS attacks in web applications is to have CAPTCHA implemented in the publicly available form/pages. However, all CAPTCHA implementations are not quite safe, and some implementations would give the user a headache.
There are recent developments on simplifying CAPTCHA- But on simplifying, some developers forget the purpose of CAPTCHA.
Well, what is the purpose of using CAPTCHA?
In simple words CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a program to ‘ensure’ that the user is a human.
Almost 80% of custom CAPTCHA implementations are found to be unsafe during our evaluations. So what all are the measures to make sure the application has safe and simple CAPTCHA?
Let us first check the possible UNSAFE implementations and the possible ways to implement a safe CAPTCHA.
- Validated at client side
Some applications validate CAPTCHA at client side, thus defeat the purpose of having CAPTCHA. The application server is still vulnerable to DoS, as the request does not get validated in the server for CAPTCHA.
- CAPTCHA logic in client side
It is a wrong practice to expose any logic in the client side page source/ in any JavaScript. Somebody with a malicious intent can read the page source and attack the web application with the CAPTCHA extracted out from the page source logic.
- The CAPTCHA is machine readable
There are some tools programmed to read the CAPTCHA images. The attacker could make use of the CAPTCHA reading tools to launch attack against the application. There are multiple tools available freely in internet to check if a CAPTCHA image is machine readable or not. A few of them are follows:
- https://code.google.com/archive/p/captcha-breaking-library/
- tessarcap
- CAPTCHA is getting validated in the intermediate request in the server side
Many applications are validating CAPTCHA using an intermediate request- in order to prevent the overload on the server. However, the final request (for example:- to save/ register/ login) can be replayed, as the CAPTCHA protection is not provided for that request.
- Re-use CAPTCHA
Re-use of CAPTCHA enables the malicious user to fire requests with same CAPTCHA value. A CAPTCHA once used should be invalidated in the server side, so that the re-use of CAPTCHA can be prevented.
Most of the developers use math-CAPTCHA, which looks simple and easy to implement. But does math-CAPTCHA serve the purpose? Usually it doesn’t.
A request with Math-CAPTCHA can be programmed to fire multiple times- since the logic believes in the request itself.
Here is a logic to safer CAPTCHA implementation
Once requested, create a captcha image, encrypt it, and along with a cookie send it to the user. In the server side, validate the CAPTCHA in the final request, with the help of cookie. Invalidate the cookie after one time use.
Some CAPTCHA library/implementation for better protection:
1- Google CAPTCHA is considered as relatively secure, but that adds a burden to the user with its complicated images.
2- If the application is written in Java, SimpleCAPTCHA is a better option. The CAPTCHAs are simple, and the secure settings are easy. One can set the complexity of image as well.
Google has implemented something called ReCaptcha which we already discussed here.
Happy testing guys..
