0

I have a very strange problem trying to implement XSRF in ASP.Net Core on angular $http post calls.

POST Register is working correctly and has the following signature:

[HttpPost("Register")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> PostRegister([FromBody]AccountRegisterPostRequest req)

However POST Logout returns 400 with the same signature:

[HttpPost("Logout")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> PostLogout()
{
   return Ok();
}

ConfigureServices:

services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");
services.AddMvc();
services.Configure<MvcOptions>(c => c.Filters.Add(new RequireHttpsAttribute()));

Configure:

app.Use(next => context =>
{
   if (string.Equals(context.Request.Path.Value, "/", StringComparison.OrdinalIgnoreCase))
   {
      var tokens = antiforgery.GetAndStoreTokens(context);
      context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken,
         new CookieOptions() { HttpOnly = false });
   }

   return next(context);
});

app.UseStaticFiles();

The angular call looks like this:

$http.post("/api/Account/Logout")
.then(function (result) {
   console.log(result);
})

The API is in a seperate project in same solution. Help :)

Kim Raaness
  • 452
  • 3
  • 9
  • Thats the 3rd question from someone trying to put XSRF Token into an angular 2 application in the past 10 days. Do you guys even what XSRF and the AntiForgery tokens are even for? Where do you get all these false information? Post requests via Ajax **are not vulnerable to XSRF** (unless you have get methods with side effects, in which case you didn't even understood basics of web applications) only to XSS (Cross Site Scripting). And of course only when you use cookie authentication, which shouldn't be used with API/Rest anyways – Tseng Feb 04 '18 at 01:35
  • When creating an API, simply use a token authentication (either opaque/reference token or jwt token does the work) and make "GET" methods safe (only reading of information, no mutating). Handing Antiforgery tokens in ajax/api calls is just the wrong solution for an bad decision (using cookies for apis) – Tseng Feb 04 '18 at 01:45
  • Also see [my answer here](https://stackoverflow.com/a/48462460/455493) – Tseng Feb 04 '18 at 01:58
  • @Tseng Thank you for the informative answers. I have decided to migrate to Token based auth for this project. I have problems understanding Web API restrictions. The Register view, in particular, has a lot of client-side validation. I don't want to have to repeat the validations on server at submit (DRY). How would I go about making sure this particular API can only be called from within the web app if not by XSRF? Anonymous method – Kim Raaness Feb 04 '18 at 09:56
  • Typically you split Authentication Server and API into two projects. The Authentication is an MVC app (with MVC views) and an OAuth or OpenID Server (such as [ASOS](https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server) or IdentityServer4). Its used to login and create tokens. Then you have a separate API which doesn't have any MVC views, just WebApi-esque actions which return json. For the authentication server you of course use cookies and Anti-XSRF Token (no SPA such as Angular or React). – Tseng Feb 04 '18 at 11:21
  • For your Api and your SPA you use separate projects. The SPA can be hosted directly (i.e. static middleware, directly in IIS/reverse proxy of your choice) where the Api accessed by that SPA is just a pure json/xmll one which uses tokens for auth. the spa itself doesn't need to be protected really, it just loads in the browser once and calls apis. – Tseng Feb 04 '18 at 11:22

0 Answers0