1

According to OWASP you can prevent CSRF in a ASP.NET application if you include the SessionID in the ViewState. From the article:

Viewstate can be used as a CSRF defense, as it is difficult for an attacker to forge a valid Viewstate. It is not impossible to forge a valid Viewstate since it is feasible that parameter values could be obtained or guessed by the attacker. However, if the current session ID is added to the ViewState, it then makes each Viewstate unique, and thus immune to CSRF.

Is including the SessionID even necessary if you are using encrypted ViewState? How could a malicious user generate a valid encrypted ViewState?

Improve this question

1 Answer 1

Reset to default
1

Is including the SessionID even necessary if you are using encrypted ViewState? How could a malicious user generate a valid encrypted ViewState?

A malicious user could generate a valid, encrypted ViewState by visiting the page in question themselves and extracting the value. If the Session ID is not part of the ViewState value then this value will be valid for all sessions.

This is also mentioned on the Microsoft page Securing View State:-

Per-user View State Encoding

If your Web site authenticates users, you can set the ViewStateUserKey property in the Page_Init event handler to associate the page's view state with a specific user. This helps prevent one-click attacks, in which a malicious user creates a valid, pre-filled Web page with view state from a previously created page. The attacker then lures a victim into clicking a link that sends the page to the server using the victim's identity.

When the ViewStateUserKey property is set, the attacker's identity is used to create the hash of the view state of the original page. When the victim is lured into resending the page, the hash values will be different because the user keys are different. The page will fail verification and an exception will be thrown.

You must the ViewStateUserKey property to a unique value for each user, such as the user name or identifier.

Improve this answer
5
  • Very interesting. So are you saying that they would just copy the encrypted viewstate from a page and include that exactly as it was in their CSRF attack?
    – Abe Miessler
    Apr 22, 2014 at 15:35
  • @AbeMiessler Yes, that's right. Of course this also depends on controls being in exactly the right state for the attack to work so it may be difficult to accomplish on complex pages.
    – SilverlightFox
    Apr 22, 2014 at 15:43
  • @SilverlightFox a bit of a necropost but still: I don't really understand the whole viewstate thing. If i wanted to get the viewstate that would work to do a CSRF where would that viewstate be then? Now I just see requests sending viewstate (encrypted) and it is always a different one. Do need to go into the encryption and create my own encrypted for that exact moment? Or is there a resource somewhere that I can find?
    – Wealot
    Mar 21, 2017 at 15:11
  • @Wealot: You would get it from the hidden field __VIEWSTATE within the HTML page. You go to the page where you would like to exploit the vulnerability (i.e where the request would normally be sent from when it is in the required state).
    – SilverlightFox
    Mar 21, 2017 at 15:34
  • @SilverlightFox: thanks! I did not notice those hidden fields before (quite a big application with a lot of fields to go through!).
    – Wealot
    Mar 21, 2017 at 15:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .