CODEWITHSUNDEEP
asp.net-mvcsecurity
WashingMachineHarry
WashingMachineHarry

Reputation: 33

AntiForgeryToken re-use

I have a MVC4 site that uses AntiForgeryTokens and always HTTPS. As I understand it, anti-forgery tokens can be reused as long as the user session is the same.

I'm worried about some kind of attack where someone fetches the token somehow and reuses it to submit a form without the user's knowledge.

Is there any real risk of attack with this setup? Do I need to consider some way of preventing token re-use?

Upvotes: 3

Views: 2265

Answers (2)

SilverlightFox
SilverlightFox

Reputation: 33578

You should only have one CSRF token per session. If the session times out, then the CSRF token expires at this point.

As there is no way for an attacker to read the CSRF token (at least there's no more of a risk of an attacker reading a CSRF token as the Session ID cookie), there is no need to generate a new one unless you have a new session to go with it.

The only exception to this I see is that if a form submission is attempted with a valid user session cookie, but with an incorrect CSRF token (i.e. the user is being attacked by another site they are using). In this case you may want to generate a new CSRF token and flag an alert to yourself so that the requests can be investigated. You may want to generate the alert after the first incorrect CSRF token (as requests containing an incorrect CSRF token should not happen at all), but you could refresh the token after n failed attempts to reduce the chances of a token being brute forced whilst allowing the user to use your system without being denied service (although the denial of service is a minor concern in this case as the attack will be coming from their own machine).

Think about it this way - the only purpose of the anti forgery token is to prevent CSRF. If an attacker can grab this in any way, then they already have access - the damage is already done. For example, if there is an XSS vulnerability on your site, this is enough of a vector for someone evil to attack your users - they won't then need a CSRF attack too.

Upvotes: 2

SkyBlues87
SkyBlues87

Reputation: 1235

Some doco on antiforgery here: http://msdn.microsoft.com/en-us/library/dd492767(v=vs.118).aspx

Essentially the AF token is a hidden field that you can place on any form as follows:

    @Html.AntiForgeryToken()

it is then validated in the controller by decorating the action/method as follows:

[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl)

Every time you call the AntiForgeryToken in a view it will generate a new token, which is then validated in the controller.

It's a small part in the overall security. In addition to this you will commonly have cookies with the client that will be used in identifying sessions and authentication:

.ASPXAUTH
ASP.Net_SessionId
__RequestverificationToken

On top of this you have SSL which is also adding another layer of security and protection.

AF Token can easily be picked up by automated tools such as JMeter and utilised in sending posts back to a server, but the 'general user' won't know anything about this. Anyone trying to use this token would also need to have the same cookies which is more difficult to simulate.

Upvotes: 0

Related Questions