Why is the [ValidateAntiForgeryToken] attribute so important?
![Why is the [ValidateAntiForgeryToken] attribute so important?](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2FzAhAUSdRLJ8%2Fupload%2F241fc86d066f3c4edba1de738d3bdd65.jpeg&w=3840&q=75)
I am a recent graduate at the beginning of my software development career. I enjoy documenting my learnings through my blogs
I was creating an MVC/Web API application with ASP.NET through a PluralSight course and I came across the [ValidateAntiForgeryToken] attribute. This was used throughout the course when using [HttpPost] requests on methods. I decided to dig a little deeper into what this attribute was doing and why it is so important.
This attribute is used to prevent forgery on a request, the instance in which I used this attribute was with forms, to update a database. The [ValidateAntiForgeryToken] attribute is important with a post request because it uses cookies to validate your request, for example, if you want to insert data into a database using a form you want to make sure that the post request is secure and that it cannot be used maliciously on another web host. If you do not use the attribute you are susceptible to malicious attacks from outsiders, this can be dangerous if these requests include personal data and could be used anywhere in the world because it does not use anything to validate the request.
I did some tests to understand how this works using a localhost server.
Test 1
For my first test, I removed the {ValidateAntiForgeryToken] attribute from my create method. By doing this I was able to create multiple instances of the same record without any validation using a localhost server. This is a small way to test this, but it made it clear that this could be very dangerous on other servers that are more open. Meaning someone could potentially steal personal data if the site being used is not using appropriate anti-forgery options.
The image below shows the request being sent again with the same cookie. This request will work whether the cookies match or not and if there is no cookie in the browser at all.
This image shows the two entries created which are the same because the code is not using the [ValidateAntiForgeryToken] attribute.
Test 2
Test 2 uses the [ValidateAntiForgeryToken] and is split into two parts, the first is deleting the cookie and then sending a request to create a data entry. This throws an error "The required anti-forgery cookie '__RequestVerificationToken' is not present".
This is because as the request is running, the browser is trying to match the cookies to accept the request. Because the cookie has been deleted from the browser, the cookie from the request cannot be matched to the browser's cookie and the request to create is denied.
The second part of the test involved altering the cookie definition from the browser and sending a create request, again because these two cookies cannot be matched the browser denies the request. The error thrown is "The anti-forgery token could not be decrypted..."
From this, I have concluded that not including an [ValidateAntiForgeryToken] attribute leaves a web application open to malicious behaviour, and could potentially distribute personal information of customers because of this. While I can acknowledge that there may be better ways to use this attribute or different ways to prevent this type of security breach, this is my learning to date.
A potentially better way to use the anti-forgery token, if you are using .NET Core, is to use the [AutoValidateAntiForgeryTokenAttribute]. This can be applied to the whole controller and will validate all unsafe methods such as Post, Put, Patch and Delete. However, it will ignore methods such as Get, Head, Options and Trace, so if you want to use validation you will have to use the [ValidateAntiForgeryToken] over these methods.
