Why CAPTCHA isn’t a defence to CSRF

CSRF (Cross-Site Request Forgery) is a form of hack where a malicious installation causes a website, email, IM, or software program to perform unwanted actions through a trusted website (the hacked site) for which the user is currently authenticated.

How impactful a CSRF attack is depends on the capabilities exposed by the hacked application.

In effect, a CSRF can cause systems to perform functions via the users’ browser to access user data (which can lead to transferral of funds, and the changing passwords), often without the knowledge of the target – until the action has been completed.

If the user account compromised is of the administrative level, a successful CSRF can compromise the web application as a whole.

Because of its severity, and how common an issue it can be, it has been a staple of the OWASP Top Ten list.

The hack can also go by the name of: XSRF, Sea Surf, Session Riding, and Hostile Linking.

There is however a misconception that by using CAPTCHA, you can prevent against CSRF attacks. At a basic level, a CAPTCHA works on the client side by:

  1. Making the browser challenge the user (request from the CAPTCHA provider).
  2. Retrieving and presenting the challenge to the user.
  3. Ensuring the user authenticates themselves by inputting a solution to the challenge.
  4. Forcing the user to submit, before sending the challenge and solution to the server.
  5. Ensuring the server receives the challenge and solution.
  6. Making the server forward this data (challenge and solution) to the CAPTCHA provider for confirmation that the solution is correct.

Because of this, the server doesn’t actually know who (or what) inputted the solution, just that it has received a solution through communication with the CAPTCHA provider, whether or not the solution is correct.

It is assumed that a correct solution means the user is genuine, thus authenticating them.

A hacker however can get around this defence by:

  1. Requesting a challenge from the CAPTCHA provider.
  2. Receiving and saving the challenge; solving it.
  3. Compiling the CSRF request, the challenge, and the solution in the request.
  4. Server retrieves the request from the user, affirms it is a valid solution and accepts the malicious action.

Google reCAPTCHA

It’s also worth pointing out that at no point in any of the documentation for Google reCAPTCHA does it mention CSRF, as this isn’t what it’s wholly designed to do, and relying on it as a solution in the long term would not be viable.

Google can change how reCAPTCHA works at any time, and because the CSRF vulnerability isn’t specified in the documentation, they are under no obligation to ensure that any changed versions work as a CSRF prevention.