3

I have an MVC 4.0 site that uses AntiForgeryTokens to protect against CSRF attacks.

What I am finding is that I can reuse an old __RequestVerificationToken after new sessions have been opened.

I start with adding to the .cshtml

@Html.AntiForgeryToken()

I then decorate the Post Action method in the controller with

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult DoSomething(MyViewModel model)
{
}

I then do the following :-

  1. Log in to admin site and scrape the __RequestVerificationToken value.
  2. Log Out
  3. Log Back In again (in theory there should now be a new token created)

  4. Then submit the form below in a new tab in the same browser (see that I have used the token from the previous request).

    <html>
<body>
  <form action="http://adminsite.com/DoAction" method="POST">
    <input type="hidden" name="id" value="26" />
    <input name="__RequestVerificationToken" type="hidden" value="rt95zr0voZbgLga117YNBfwwLpTU8onGCDmZ4IQEisvhiNH_9ISTtsbDzIVgIkRUzwH81PpbrTRGK4MLSp3S3j-JMNjsJTL04TRl2J38rNz8KKomL98gLjEiJoXgMXFt0qaJ8tPaB4_PvGo8ATaxLcA2" />
    <input type="submit" value="Submit request" />
  </form>
</body>
</html>

What I find is that even though I have logged out and back in again, I am still able to use the old __RequestVerificationToken and I can successfully post the form.

After reading through the documentation (http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages) there is no mention of invalidation of token.

My questions are :-

  1. Shouldn't it now be invalid?
  2. If not, why not?
  3. Is there a way of making the __RequestVerificationToken invalid after logging out and back in again?
Christophe Chang
  • 139
  • 1
  • 8
  • Why should it be invalid if it's the same user logged in? Have you tried using the same token with another user logged in? cf this answer http://stackoverflow.com/a/9447579/1138898 – The Bearded Llama Jul 12 '16 at 15:29
  • The form should fail if posted by a different user yes (aspnet auth username is compared with the username stored in the field token. The usernames must match). The security company doing the penetration test have requested that the token expire after the session ends. They say to minimize the chance of the token being re-used. I can see their point but from what I can see it doesn't look like this is out-of-the-box behavior for this setup. What do you think? – Christophe Chang Jul 12 '16 at 15:52
  • what the pentest company is asking is pointless and most likely aimed at justifying their existence; it would be better use of your time to send them a link to how the thing works, so they can see that there is no cause for concern or they can take on MS if they feel there is; this is bread and butter stuff ;) – The Bearded Llama Jul 12 '16 at 16:27
  • Interestingly stackoverflow uses a more complex prevention method for CSRF. They leverage server state (with a timeout) to generate a unique random key for every single post. I understand that this is overkill for my site though. https://blog.codinghorror.com/preventing-csrf-and-xsrf-attacks/ . – Christophe Chang Jul 12 '16 at 17:05

0 Answers0