2

According to the OWASP CSRF Cheat Sheet viewStateUserKey for ASP.NET ViewState is acceptable to prevent csrf attacks, but I really don't get how. I get that this makes it hard for an attacker to modify the viewstate since they would basically have to know the user's session id, but a form's post parameters are not stored in the session state so you don't need to modify that in your attack.

Is the whole concept around the fact that it is difficult to obtain a valid viewstate to begin with, or am I missing something?

Is this really considered a valid technique to prevent csrf?

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
Jarrod Everett
  • 517
  • 2
  • 6
  • 11

2 Answers2

4

If you enable the ViewStateUserKey, then the server will protect the integrity of the view state by appending a random, unguessable checksum. This checksum acts much like a random CSRF token.

In particular, ViewStateUserKey will compute a Message Authentication Code (MAC) on the view state fields. A MAC is like a keyed checksum of the data, where the key is known only to the server. Because the attacker does not know the key, the attacker cannot generate a valid checksum (MAC digest) for some other value of view state parameters.

If you use a ViewStateUserKey, then the key used is specific to the particular user. This means that a malicious attacker Mandy cannot learn a valid value of the MAC digest for user Bob. Mandy cannot guess it, because a MAC algorithm is designed to prevent guessing the MAC digest. Mandy cannot learn it by contacting to the server, because if she connects to the server, the server will use her cryptographic key, not Bob's key, so the MAC digest that is sent to Mandy will be unrelated to the one used for Bob.

In effect, the MAC digest acts like a random 128-bit string that the attacker cannot guess. This is what prevents CSRF. Standard CSRF defenses involve including a random string in the request parameters (random, so that the attacker cannot predict it). With a ViewStateUserKey, the MAC digest acts as that random string.

See also Microsoft on Securing View State and Does ASP.NET Viewstate implicitly prevent CSRF attacks? What does this mean for MVC?.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
3

As I understand it the point of the ViewStateUserKey specfically is that it ensures that the ViewState will be specific to a given user. As ViewState is a hidden field that needs to be submitted as part of a form somewhat like most CSRF defence tokens, if the attacker is not able to predict it's value it will be difficult for him to execute a successful attack.

It should be noted that it needs to be used in conjunction with the ViewStateMAC for this to work (as noted here) as that's what's checked by the application on postback.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • But the difference here with most csrf tokens is that it is validated server side against the session id... which in this case is submitted with the csrf attack. So as long as you didn't modify the view state you will be ok. And since post params aren't part of view state this seems like it wont be very effective – Jarrod Everett Aug 23 '12 at 21:01
  • I believe that that's the point of ViewstateMAC when combined with the user key. Setting the MAC causes viewstate to be validated server-side, setting the user key causes the MAC to be tied to the individual user. – Rory McCune Aug 23 '12 at 21:34
  • So then the security of this is due to the fact that it's very hard to forge a valid viewstate since it is essentially equivalent to forging a session key? – Jarrod Everett Aug 23 '12 at 23:36
  • Essentially with these two settings in place, yes – Rory McCune Aug 24 '12 at 06:44
  • @RоryMcCune Is it a security threat if the ViewState is same for all the users in an application? – Rahil Arora May 22 '14 at 15:04