CSRF aka Cross-site Request Forgery is a type of cyber-attack that attempts to override the authenticated user request by fooling the user to click on a fake link that contains manipulated script so that the attacker can utilize the previously-stored cookies to access the site without any restrictions and carry out fraudulent attacks. Not to mention, the attackers initiate this attack so that they can either gain some financial benefit, submit or delete a record, purchase a product, change passwords, or send a message without users’ consent. Moreover, these types of attacks are more visible on banking websites, and therefore, it becomes very essential to protect yourself from these attacks. Yes, no doubt Captcha (Completely Automated Public Turing test to tell Computers and Humans apart) are your soldiers, but the question is, can Captcha prevent CSRF?
Well, let’s try to find out!
Contents
Can Captcha prevent CSRF?
No, Captcha won’t be able to prevent a user from CSRF attack, because an attacker can request a challenge from the Captcha provider, solve it, then compile the CSRF request with the Captcha solution as well as the ID, and lastly send it again to the server. The server then confirms the request, gives validation, and accepts the action. Thus, giving an easy pass to the attacker.
Moreover, Egor Homakov described this exact attack scenario back in 2013, where an attacker could buy Captcha challenge-solutions pair online from the people who have already solved them, thus making this attack more doable.
How to prevent CSRF attacks?
So, now that it is clear that CSRF attacks cannot be prevented using Captcha, there rises a need to take some precautionary measures to safeguard your website. And therefore, I am noting down some of the preventive measures below.
Don’t allow an attacker to craft an arbitrary request:
First of all, make sure that an attacker cannot craft an arbitrary request run in the security context of any other user, and sent from a different website, as this is the initial condition for launching a successful CSRF attack.
Try token-based prevention:
As mentioned by OWASP Cross-Site Request Forgery Prevention Cheat Sheet, the most common preventive technique for Cross-Site Forgery Request Attacks is to use the CSRF token aka synchronizer token or anti-CSRF token.
Moreover, this session token has unique values that are generated by the application, sent to the client, and then back to the server which verifies the request, thus making it unpredictable for the hacker.
The same-site cookie approach restricts the origin from where the cookie can be dispatched. Thus, CSFR exploits the possibility of making a cross-origin request. Therefore, by limiting requests so that they can only be sent from the origin where the cookie is related, it can effectively prevent the ability to send external requests to an application.
Moreover, according to OWASP, this approach should be combined with CSRF token strategy and not be used as a substitute.
Custom Request Header:
The use of a Custom Request Header is particularly effective for AJAX or API endpoints, because, in this approach, JavaScript is used to add a custom header which unfortunately is unable to make cross-origin requests with a customer header as it is restricted by the SOP security.
Thus, preventing a cross-domain request with customer headers, resulting in the elimination of CSRF attacks.
A double submits cookie approach can be used if it is impossible to use a valid token on the server-side. Here, when a user visits a website, the site generates a value that is stored in the form of a cookie on the user’s device, apart from the session identifier cookie. After that when a legitimate request is submitted to the site, it must contain a similar value as the cookie. Lastly, the server verifies it, and if the value is a match, then the request parameter is accepted.
Are Cross-Site Request Forgery and Cross-Site Scripting the same thing?
No, CSRF and XSS are both different types of attacks, because for CSRF to work, the user must currently be authenticated on a website, through which the attacker can send a request, while on the other hand, XSS doesn’t require authentication, but only for the user to visit a particular site on which the XSS script is then executed within the browser.
Final Remarks on Can Captcha prevent CSRF?
So, after this brief discussion, it is very much clear that a Captcha test won’t be able to prevent a website from a CSRF attack because the attacker is simply camouflaged by the authenticated user, thus giving the attacker a simple pass to carry out fraudulent attacks.
Therefore, if you want to protect your website from CSRF attacks, then you can simply follow the preventive measures that are mentioned in the article.