CSRF

  • 2 months ago
  • 38 views
  • 0 comments

  • About 2 minutes to read

To help protect against cross site request forgery (CSRF) style attacks Plato employs both server side and client side CSRF protection. These techniques are described below.

Server Side CSRF Protection

All POST requests within Plato leverage the built-in CSRF protection offered out of the box by ASP.NET Core MVC. The server side CSRF protection offered by .NET Core will automatically add a hidden input fields to all Plato forms that perform a POST action. This hidden input field is named plato-csrf.

The plato-csrf hidden input field is populated with a unique random value which is also stored within a HTTP only client side cookie. By default within Plato this cookie is named plato_csrf. When the form is submitted or posted to the server the plato-csrf hidden input field is checked against the value stored within the plato_csrf cookie and if the values match the post is successful. If the values don't match you will see a 403 Forbidden response from the server.

Client Side CSRF Protection

Plato also employs client side CSRF protection to ensure client side or API POST requests coming from the client are indeed coming from Plato and not random 3rd party code.

Unlike server side validation that depends upon a hidden form field, client side requests have no forms so instead the CSRF token is stored within a client side cookie which is issued by Plato to ensure the client request is indeed coming from Plato.

For each page request Plato will issue a plato_csrf_client cookie. This cookie contains a unique random value for each request. This cookie is not flagged as HTTP Only and so can be accessed by client side JavaScript code within Plato. When Plato needs to call the API or perform an operation that would modify data via a client side POST request the plato_csrf_client cookie value is passed along within the client side request via the X-Csrf-Token header to the server and compared against the original plato_csrf_client cookie value issued by the server.

If the value supplied via the X-Csrf-Token header matches the value of the plato_csrf_client cookie issued by the server the request will succeed. If the values don't match you will see a 403 Forbidden response.

This behaviour is controlled via the ValidateClientAntiForgeryTokenAttribute class within Plato.WebApi. This class defines a .NET attribute you can apply to classes or methods to protect those classes or methods with the client side CSRF support.

TIP The various anti forgery configuration options such as cookie name, hidden field name etc can be configured via the AntiforgeryOptions object. These are configured by default within Plato via the AntiForgeryOptionsConfiguration class within the Plato.Internal.Hosting.Web.Configuration namespace.

Can we improve this doc? Login or register to tell us how
Your Feedback
Cancel
In this doc