Do Antiforgery Tokens Really Help?

A look into whether or not antiforgery tokens can be stolen

Photo by NASA on Unsplash

Antiforgery Tokens

Here are some questions I came up with while learning about antiforgery tokens and how they can protect against CSRF attacks.

You should already know what a CSRF attack is, and what antiforgery tokens are.

Read my article if you’re interested in how antiforgery tokens work behind the scenes.

Login CSRF attack

A login CSRF attack is the opposite of a normal CSRF attack.

The victim loads a fake website which appears real, and uses it to log in to a website like PayPal, but without the victim knowing, the attacker’s credentials are used behind the scenes.

Once the victim logs in, the browser is redirected to the real PayPal website where they’re now logged in as the attacker.

Why would an attacker want a victim to log in using their credentials?

Because if it’s PayPal, the victim could end up making a payment and linking their credit card to the attacker’s account.

Antiforgery tokens to the rescue

When you make a GET request to a real login page, the response will contain a cookie with an antiforgery token that is mathematically linked to another antiforgery token that is part of the HTML form element where you type in your credentials.

If the user makes a POST request from the fake website to the PayPal login endpoint where the credentials are verified, the request will be rejected because there would be no PayPal cookie containing the antiforgery token.

What if the attacker first extracts the antiforgery tokens?

Extracting the antiforgery token from the HTML

You might be wondering if the attacker could write the Javascript in the fake website, so that a GET request is first made to PayPal’s login page to extract the antiforgery token from the HTML in the response.

Thanks to the browser’s same-origin policy, this can’t happen.

The GET request can be executed, but the reponse is blocked by the browser due to the same-origin policy. So the antiforgery token is not available from within the Javascript code.

This is also why a normal CSRF attack (where the user is already logged in and has an antiforgery cookie), is also protected by antiforgery tokens.

Extracting the antiforgery token from the cookie

Even if it were possible to extract the antiforgery token from the HTML, for a login CSRF attack, the Javascript would need to create a cookie in the victim’s browser with the antiforgery token from the Set-Cookie header in the response. This is also impossible, since you can’t create a cookie for a different domain to the one that rendered the Javascript.

Conclusion

Antiforgery tokens definitely help against attacks.

They are needed for POST and GET requests. PUT/DELETE, and non-standard POST/GET (ie. POST/GET requests that could only have been made via Javascript due to non-standard headers), are already safe because they require a pre-flight request before being executed.

If you’re using a popular, up-to-date browser that uses the same-origin policy, and the websites you use, use ReSTful APIs and antiforgery tokens, it will be very difficult to fall victim to a CSRF attack.

I’m a software developer who is passionate about learning how things work behind the scenes.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store