1

I have an MVC app that is using the AntiForgeryToken capability of ASP.NET MVC. AFAICT this uses an encrypted synchronizer token variation where it validates the payload of the tokens.

A customer has questioned the fact that these tokens don't expire, and if captured will continue to be valid for a given user's session.

It is possible to customize add a timestamp to the token and validate it, thus expiring the issued token after a period.

What I'm wondering though, is this necessary? Should CSRF tokens provide replay protection? Wouldn't an attack require either MitM or an XSS vulnerability?

I sort of expect that a longish expiry is a reasonable part of a defense-in-depth strategy, but it is odd to me that replay would be raised as a security issue with an CSRF prevention scheme.

What am I missing?

2

If the CSRF token can be intercepted then the session cookie can usually be intercepted as well, so CSRF wouldn't be the immediate concern in that scenario.

Some CSRF token implementations have timed expirations, but this is an extra precaution and not strictly necessary. This answer from tylerl suggests that an expiration is a good precaution in case the token is leaked somehow, but expiring the CSRF token when the session ends is ok.

In a CSRF attack the attacker has the ability to submit whatever form data they want from your session, but they can't modify your cookies. For a CSRF token to be effective it should be impossible for the attacker to know its value. If the attacker exploits a vulnerability to obtain CSRF tokens, then you want to make sure that the CSRF tokens are no longer valid once the vulnerability is fixed. As long as the token cookie is expired when the session expires everything is fine (provided you force sessions to expire if you ever suspect tokens have been leaked).

From the documentation you linked it looks to me like it's actually using the Encrypted Token Pattern, which sort of combines a Double Submit Cookie with a Synchronizer Token.

  • Thanks @AndrolGenhald! The token is indeed encrypted, but it's also a synchronized token. The linked doc self explains the scheme as 'variant of the synchronizer token pattern'. In your opinion then replay is not a valid attack threat on the CSRF implementation? – JT. Sep 12 '17 at 13:59
  • In a replay attack the attacker is trying to cause your data to be sent to the server multiple times, in a CSRF attack they're trying to get you to submit something specific once. The issue isn't that requests can be replayed, it's that if the token has been compromised and hasn't been invalidated/expired then the application will be vulnerable to CSRF. – AndrolGenhald Sep 12 '17 at 22:06
  • It would seem that if your cookie and in-page token can be sniffed, the application has bigger problems. IMO the true defense against this is transport security, though I can see the defense-in-depth argument. Where am I going wrong with this thinking? – JT. Sep 13 '17 at 3:37
2

We've had this discussion with many clients over the years. The most valid solution for CSRF protection is one where the server tracks what 'page' was sent to the client, then only accepts valid data from the page that was served, from only the client it was served to.

It's been a while since I've been on the programing side with MS, but the @AntiForgeryToken should change with every request and be validated on each page that receives data.

It sounds as if the application only generates the token once, then never again. Check out this blog for additional details. http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

  • Thanks for your reply! When considering per-page tokens with a synchronizer token pattern, wouldn't this mean that a cookie is either regenerated on each request or there would be a cookie per page? The first would create cross tab issues (as the shared cookie would get invalidated quickly), and the second would create a lot of cookies. – JT. Sep 12 '17 at 13:19
  • When considering the output of @AntiForgeryToken in the Razor side, note that while this may change often, the cookie stays relatively static. As soon as the cookie is reissued, page tokens that had previously been issued are invalidated. Complicating this is that the token is created as a session cookie, and while they're meant to be deleted on browser restart etc, modern browsers will often persist them indefinitely. – JT. Sep 12 '17 at 13:21
  • Lastly (to address the last of your points), the AntiForgeryToken attribute appears to generate a cookie once per login identifier, and doesn't readily regenerate it. This seems to be the nub of the customer's concerns. The key idea I'm trying to drill in on though is whether replay is an attack that an anti-CSRF implementation should consider? – JT. Sep 12 '17 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.