Do Antiforgery Tokens Really Help?
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 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 with the antiforgery token.
What if the attacker first extracts the antiforgery tokens?
Extracting the antiforgery token from the HTML
Thanks to the browser’s same-origin policy, this can’t happen.
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
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.