In this section, we will examine the misuse of cookies, particularly concerning cross-site request forgery (CSRF). Consider a scenario in which a user interacts with a web browser with the intention of visiting a bank’s website. Upon accessing the bank’s site, the user submits a login request and subsequently receives a cookie from the bank, enabling further actions on the site, contingent upon a successful login. However, if the user is inadvertently led to a malicious website, such as www.dangers.com, and this site sends a request to the bank on the user’s behalf, the user’s cookie associated with the bank is transmitted along with that request. This behavior is inherent to how browsers operate, and if the bank does not implement adequate security measures, the malicious site could execute transactions on the user’s behalf without their knowledge.
To mitigate this risk, two protective measures are available in the .NET Core framework:
- Antiforgery Tokens
- SameSite Cookies
Antiforgery Tokens are implemented through the form tag helper in ASP.NET. Although it resembles a standard form tag, it generates additional code, including a hidden input field that contains a token. This token ensures that only forms created by ASP.NET can be submitted successfully, rejecting any requests that lack the appropriate token. To strengthen the Antiforgery token mechanism, actions in the controller must be annotated with the validate Antiforgery token attribute. Consequently, even if a malicious site attempts to send a token on behalf of the user, the absence of the Antiforgery token generated by the ASP.NET form will lead to the rejection of the request, thereby protecting the user.
Another method to combat cross-site request forgery is through the use of SameSite cookies.
These specialized cookies can only be sent directly to the bank and not from third-party websites. SameSite cookies function by differentiating between their path and regular cookies. When a user makes a request, they receive both a regular cookie and a SameSite cookie. The SameSite cookie behaves differently than the regular cookie: when the user visits a site like www.dangers.com, only the regular cookie will be transmitted to the bank’s website, while the SameSite cookie remains protected by the browser. This mechanism effectively prevents cross-site request forgery.
It is essential to understand the implications of cookies and to distinguish the “SameSite cookie” from other types. By default, cookies are sent from any website, irrespective of their origin. However, the cookie policy can be modified to suit specific requirements. The following API code allows for the creation of a cookie policy option, which can be passed to the “UseCookiePolicy” method. By default, the cookie policy is set to “lax” mode, which is relatively permissive. A stricter “strict” mode is also available, but it is generally not recommended unless absolutely necessary. In “strict” mode, the originator of the request must be from the same website, while “lax” mode permits certain redirections. It is crucial to select the appropriate mode based on your specific needs, and it is advisable to retain the default value unless there is a compelling reason to change it.
For additional information and more detailed guidance, please visit the following link: Microsoft Documentation on SameSite Cookies.
Source: Nguyen Chi Hieu – Technical Manager
