10

I'm trying to implement antiforgerytokens to an angular application's ajax requests.

Is there a lifetime attached with the antiforgerytoken? If I have the app open for a long while in a web browser whithout touching it, say for a month. Will the ajax requests fail due to a stale token?

Can the token be reused for multiple calls? Can I keep one token somewhere in the page and retrieve it for all ajax calls?

Carl R
  • 8,104
  • 5
  • 48
  • 80

2 Answers2

1

Indeed API are supposed to be consumed by 3rd parties, but what's regarding Single Page interfaces with AFT?

I'm concerned they still require AFT in order to prevent CSRF atacks. And here is a good way to use them in Ajax requests.

Antiforgery token is generated per Session, and remains in session data till it's expired. For new session new token will be generated. And yes, single token can be reused multiple times within the same session.

Please check the link I've added, there is example of how token might be obtained for Ajax requests.

Johnny_D
  • 4,592
  • 3
  • 33
  • 63
  • I've been looking at that page previously and implemented it similarly. In my case I'm rendering the token in the "master page" (which in my case would be the master page from the angular point of view). I'm reusing the same token over and over again. However, at some rare occasion there's an error that a token wasn't made for this user. I'm guessing it happens when using the back button and reusing a page where there's an antiforgerytoken for the unauthenticated user. – Carl R Oct 14 '13 at 14:20
  • I'm accessing the antiforgerytoken using jquery. I've been considering a webservice that could be accessed to retrieve an antiforgerytoken. It seems backwards, but on the other hand it's the same with retrieving a page but without the rest of the page. – Carl R Oct 14 '13 at 14:23
  • If there would be a method for retrieving token, then what's the purpose of those token if it can easily be obtained via csrf. Consider preloading some page with token in background and keeping token from it on your page. – Johnny_D Oct 14 '13 at 15:34
  • A page could equally easy be obtained by csrf, couldn't it? – Carl R Oct 14 '13 at 19:53
  • @CarlR not exactly, you can send a submit request from form, but not by manipulating in JS. Take a look [here](http://stackoverflow.com/questions/929677/how-exactly-is-the-same-domain-policy-enforced). It's all about same domain policy in browsers. – Johnny_D Oct 15 '13 at 05:53
  • 1
    I don't see the connection. The client code needs a token, the token can either come from a page, or from a "partial result", or anything returning a string to the browser. What the client does next with the token is guarded by the domain policy as you are noting. What I'm talking about is pre form submit, you are talking about the submit. Correct? – Carl R Oct 21 '13 at 07:37
0

Will the ajax requests fail due to a stale token? Yes

Can the token be reused for multiple calls? No

However, the better question to ask yourself is why are you using antiforgery tokens with AJAX in the first place. If you're using AJAX, you're using an API, even if you haven't formalized it as such (just a collection of actions/controllers that are using for AJAX/other headless communication). Antiforgery tokens don't work well with APIs because 1) APIs typically allow third-party access and 2) even if they don't, there's better ways to secure them.

If you want to ensure that only your site can access your "API", then implement HTTP authentication or some other scheme to authenticate your requests to your "API". That is how you allow long running sessions that will not fail.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444