CS.CSRF.ATTR.POST

Property 'ViewStateUserKey' is not set

Cross-site request forgery (CSRF) prevention is a complex problem with no universal solution. One way to reduce the chances of introducing CSRF vulnerabilities is to use anti-forgery tokens that request the browser send back the token on each request. For classes derived from 'Microsoft.AspNetCore.Mvc.Controller', these anti-forgery tokens can be 'AutoValidateAntiForgeryToken'. For methods, these anti-forgery tokens can be either ''ValidateAntiForgeryToken' or 'IgnoreAntiForgeryToken'. The CS.CSRF.ATTR.POST checker reports a defect if none of these tokens are used and POST methods are present (that is, methods with one of the following attributes: [HttpPost] , [HttpDelete], [AcceptVerbs("POST")] or [AcceptVerbs("DELETE")]).

Vulnerability and risk

Cross-site request forgery (also known as XSRF or CSRF) is an attack against web-hosted apps whereby a malicious web app can influence the interaction between a client browser and a web app that trusts that browser. When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server that will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc., and can result in the exposure of data or unintended code execution. This form of exploit is also known as a one-click attack or session riding because the attack takes advantage of the user's previously authenticated session.

Mitigation and prevention

The most common approach to defending against CSRF attacks is to use the Synchronizer Token Pattern (STP). STP is used when the user requests a page with form data:

  1. The server sends a token associated with the current user's identity to the client.
  2. The client sends back the token to the server for verification.
  3. If the server receives a token that doesn't match the authenticated user's identity, the request is rejected.

In ASP.NET Core, this can be done by using the following anti-forgery token attributes:

  • ValidateAntiForgeryToken
  • AutoValidateAntiforgeryToken
  • IgnoreAntiforgeryToken

Vulnerable code example

1   using Microsoft.AspNetCore.Mvc;
2    
3   namespace Example.Controllers
4   {
5       public class ExampleController : Controller
6       {
7           [HttpPost]
8           public IActionResult Test1(string name, int numTimes = 1) //@ CS.CSRF.ATTR.POST
9           {
10              string txt1 = Request.Form["Text1"];
11              ViewData["Message"] = txt1;
12              return View();
13          }
14      }
15  }

In this code, the class 'ExampleController' is derived from the 'Microsoft.AspNetCore.Mvc.Controller' class, and class 'ExampleController' doesn't contain the attribute [AutoValidateAntiForgeryToken]. The 'Test1' method is defined inside the 'ExampleController' class and the 'Test1' method doesn't contain either the [ValidateAntiForgeryToken] or the [IgnoreAntiForgeryToken] attributes. In addition, the 'Test1' method is attributed with the [HttpPost] attribute. Klocwork reports this vulnerability as a CS.CSRF.ATTR.POST defect on line 8.

Fixed code example

1   using Microsoft.AspNetCore.Mvc;
2    
3   namespace Example.Controllers
4   {
5       public class ExampleController : Controller
6       {
7           [ValidateAntiForgeryToken] // Adding this anti-forgery token fixes the issue
8           [HttpPost]
9           public IActionResult Test1(string name, int numTimes = 1)
10          {
11              string txt1 = Request.Form["Text1"];
12              ViewData["Message"] = txt1;
13              return View();
14          }
15      }
16  }

In this fixed example, the class 'ExampleController' uses the [AutoValidateAntiForgeryToken] attribute on line 7, which enables ASP.NET's builtin CSRF protections.

Security training

Application security training materials provided by Secure Code Warrior.