My security scan detected issue of type "Missing AntiForgeryToken implementation". My application has a layer of .netCore WebApi services, a .netCore WebApi with RazorPages service and a Angular front-end application. Reading online all CSRF Token implementation refers to RazorPages or similar but not front-end applications. The question is: is the token require in three tier architecture? Do I have to implement the policy with my fe? Is it a real issue the tool is detecting?
Thanks.
CodePudding user response：
First of all, it is necessary to understand what is antiforgerytoken? This has nothing to do with n tier. If your project has web pages and you are making http requests, you should use AntiforgeryToken cause security.
CodePudding user response：
The architecture is irrelevant.
"Rule of thumb" is that if there is a user context in your application then you require an anti-forgery token implementation to prevent attacks such as:
An attacker tricks the user into visiting a different web page (such as evil.com) with malignant code that secretly sends a malicious request to the application's web server (such as example-bank.com).
Assume the user is logged into the application at example-bank.com. The user opens an email and clicks a link to evil.com, which opens in a new tab.
The evil.com page immediately sends a malicious request to example-bank.com. Perhaps it's a request to transfer money from the user's account to the attacker's account. The browser automatically sends the example-bank.com cookies (including the authentication cookie) with this request.
If the example-bank.com server lacks XSRF protection, it can't tell the difference between a legitimate request from the application and the forged request from evil.com.
Angular's HttpClient enables XSRF Token support by default:
HttpClient supports a common mechanism used to prevent XSRF attacks. When performing HTTP requests, an interceptor reads a token from a cookie, by default XSRF-TOKEN, and sets it as an HTTP header, X-XSRF-TOKEN. Because only code that runs on your domain could read the cookie, the backend can be certain that the HTTP request came from your client application and not an attacker.
By default, an interceptor sends this header on all mutating requests (such as POST) to relative URLs, but not on GET/HEAD requests or on requests with an absolute URL.
To take advantage of this, your server needs to set a token in a JavaScript readable session cookie called XSRF-TOKEN on either the page load or the first GET request. On subsequent requests the server can verify that the cookie matches the X-XSRF-TOKEN HTTP header, and therefore be sure that only code running on your domain could have sent the request. The token must be unique for each user and must be verifiable by the server; this prevents the client from making up its own tokens. Set the token to a digest of your site's authentication cookie with a salt for added security.
It is relatively straight forward to implement on the .net side as well.
services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");