JWT, OAuth and XSRF on ASP.NET - How would I handle the CSRF token expiration RRS feed

  • Question

  • User-1134857695 posted

    Hi everyone! I'm migrating my app to SPA. I've been investigating the matter, because I got worried about CSRF/XSRF attacks. I have a couple of concerns.. 

    I have started to implement a token-bearer approach using OAuth and JWT through Katana, by following this tutorial: http://bitoftech.net/2015/02/16/implement-oauth-json-web-tokens-authentication-in-asp-net-web-api-and-identity-2/

    After implementing it, I realized that I needed to store the JWT in a safe manner. According to the Stack Exchange network and some other websites, the best way to do this is to store it in a Cookie with HTTP flags on. This would prevent the attacker from using a XSS mechanism and steal the token. Unfortunately this approach is susceptible of CSRF attacks, bringing me almost to square 1.

    A mechanism suggested by the same sources is to use a Double Cookie implementation. In which I would send both: the CSRF token and the JWT. Despite that, I'm really worried about generating the CSRF token (which was my main problem). The best way (in my understanding) to retrieve an anti-forgery token is to server-render it 

    Therefore I get the token through @Html.AntiForgeryToken in my initial load and utilize it for subsequent requests. This creates the following concern: For how long will that token be valid? Or, how would I handle the CSRF token expiration? (Which was my main concern in the beginning) 

    I don't know how viable would it be to request another CSRF token from the server after the data has been sent. I'm very skeptical on retrieving tokens via AJAX calls... 

    I haven't found any post so far that dwells this far. So that's why I'm asking. 

    Tuesday, July 26, 2016 3:51 AM

All replies

  • User-1134857695 posted

    Almost 24 hours... bump! ;)

    Wednesday, July 27, 2016 3:09 AM
  • User-693045842 posted

    How would you get the token , when token is expired , you need the same process to acquire a new token .

    Thursday, July 28, 2016 1:59 AM
  • User-1134857695 posted

    Hi meeyourmark, thanks for the reply! So you're suggesting to use the OAuth token to load the CSRF token too?

    Thursday, July 28, 2016 10:56 AM
  • User-1134857695 posted

    Wait! I think there's a problem... If I store the bearer token as a Cookie, and I try to retrieve the AntiForgeryToken from a request, I could potentially open it to attacks, too. The attacker could send the request, the bearer token would go with the request, and then the antiforgerytoken would be returned to the attacker.

    Thursday, July 28, 2016 11:19 AM
  • User-1134857695 posted

    I think I've come up with a solution. Instead of using the JWT as an authentication mechanism. I could use it as an anti-forgery mechanism. 

    I would use Identity as authentication, and the token would be passed to each request for validation. 

    If the user is valid and the token is valid, then go ahead.

    If the user is valid, and the token invalid, invalidate the request. 

    If the user is valid, and the token is valid but expired, log out the user.

    If the user is invalid, and the token valid, invalidate the token and the request. 

    Thursday, July 28, 2016 12:46 PM
  • User-1134857695 posted

    I think my solution above is quite useless. This would be defeating the purpose of JWT at all.

    Thursday, July 28, 2016 3:26 PM
  • User-1134857695 posted

    So... Another bump*

    Friday, July 29, 2016 3:31 PM