Last post Jul 29, 2016 03:31 PM by superjose
Jul 26, 2016 03:51 AM|superjose|LINK
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.
Jul 27, 2016 03:09 AM|superjose|LINK
Almost 24 hours... bump! ;)
Jul 28, 2016 01:59 AM|meeyourmark|LINK
How would you get the token , when token is expired , you need the same process to acquire a new token .
Jul 28, 2016 10:56 AM|superjose|LINK
meeyourmark, thanks for the reply! So you're suggesting to use the OAuth token to load the CSRF token too?
Jul 28, 2016 11:19 AM|superjose|LINK
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.
Jul 28, 2016 12:46 PM|superjose|LINK
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.
Jul 28, 2016 03:26 PM|superjose|LINK
I think my solution above is quite useless. This would be defeating the purpose of JWT at all.
Jul 29, 2016 03:31 PM|superjose|LINK
So... Another bump*