Click here to Skip to main content
15,867,704 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hello,

We have a .NET core web application where we add and authentication scheme that creates an authentication ticket with claims identity.
C#
services.AddAuthentication(options =>
            {
                options.DefaultScheme
                    = AuthenticationScheme.UserLoginAuthenticationScheme;
            })
           .AddScheme<AuthenticationSchemeOptions, AuthenticationHandler>(
                   AuthenticationScheme.UserLoginAuthenticationScheme, options => { });


C#
List<Claim> claims = new List<Claim>
                {
                    ...
                    new Claim(ClaimTypes.Sid, loggedInUser.Id.ToString())
                    ...
                };
...
var claimsIdentity = new ClaimsIdentity(
                    claims,
                    nameof(AuthenticationHandler));

var ticket = new AuthenticationTicket(
                        new ClaimsPrincipal(claimsIdentity), this.Scheme.Name);

We also have an authorization policy builder that requires one of these claims
C#
services.AddAuthorization(config =>
            {
                var userAuthPolicyBuilder = new AuthorizationPolicyBuilder();
                config.DefaultPolicy = userAuthPolicyBuilder
                                    .RequireAuthenticatedUser()
                                    .RequireClaim(ClaimTypes.Sid)
                                    .Build();
            });

When we run checkmarx analysis on the code base we get a couple thousand CSRF violations.

My questions,
1. The way we implement things, is this enough to prevent CSRF?
2. If not, what should be the general approach in fixing these violations.

What I have tried:

Adding [ValidateAntiForgeryToken] attribute on the methods seems to reduce the violations, I am wondering if that's even neccessary.
Posted
Updated 22-Jan-23 23:33pm
Comments
Andre Oosthuizen 23-Jan-23 5:36am    
Not my field of expertise, this has helped me in the past though as a general lookup - https://brightsec.com/blog/csrf-mitigation/
GKP1992 23-Jan-23 11:20am    
Thank you, I'll take a look.

1 solution

Your authentication and authorization policies are nothing to do with CSRF. CSRF occurs when an authenticated user on your site visits another site, and that site is able to trick them into issuing a request to your site to perform an action which they are authorised to perform, but did not intend to initiate.

For example, you log in to YourBankSite.com. In the same browser session, you then visit EvilBadGuys.net. That site includes a button that reads "Cutest kitten picture ever - click now!". When you click on that button, it submits a request to your bank's website to transfer $1,000,000 from your bank account to Dr Evil's bank account. You're authenticated on your bank's site; you're authorised to transfer money from your bank account; but you didn't intend to do so.

The solution is to add an anti-forgery token to all of the forms on your site. The server will append a token to your form in a hidden field. When the form is submitted, it will verify that the token is present, that it was generated by the server itself, and that it was generated for the current user. If any of those conditions are not met, then the request will be rejected. The other site will not be able to generate an appropriate token, and so it will not be able to initiate a forged request on your site.

Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core | Microsoft Learn[^]


The other CSRF protection you'll want to use is to configure "same site" cookies:
SameSite | OWASP Foundation[^]
Work with SameSite cookies in ASP.NET Core | Microsoft Learn[^]

In all modern browsers, setting "same-site" to either "strict" or "lax" ensures that your cookies will not be sent with requests initiated from another site. However, this should be implemented in addition to the anti-forgery token, since there may still be ways around it:
Bypassing SameSite cookie restrictions | Web Security Academy[^]
 
Share this answer
 
v3
Comments
GKP1992 23-Jan-23 11:06am    
Appreciate the thorough explanation. Thank you for taking the time to do this.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900