Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

If an encrypted ASP.NET Viewstate is submitted with every form, and control POST, does that mean that ASP.NET is less vulnerable to CSRF than other solutions with this?

What is the extent and limitation of that protection?

Since the AntiForgeryToken isn't implemented by default in ASP.NET MVC does that mean that those sites may be more likely to be at risk?

share|improve this question
    
If you want to complete intro on CSRF with practical examples and how to prevent it in ASP.net..You can go here: thehackerspost.com/2013/02/… –  user21136 Feb 23 '13 at 17:29
    
The following SO question may be useful: stackoverflow.com/questions/4074199/… –  Eric G Feb 23 '13 at 19:07

2 Answers 2

up vote 12 down vote accepted

The purpose of ASP.NET ViewState is to persist control state between post-backs (See http://msdn.microsoft.com/en-us/library/ms972976.aspx), it does not implicitly enable security that would prevent CSRF.

Also note that encrypted ViewState in unpatched older versions of ASP.NET are susceptible to an encryption vulnerability see http://technet.microsoft.com/en-us/security/bulletin/MS10-070.

To enable this type of protection you could:

ASP.NET MVC3 does have an anti-forgery token that is used with the [ValidateAntiForgeryToken] attribute on the controller action (See http://msdn.microsoft.com/en-us/library/system.web.mvc.validateantiforgerytokenattribute.aspx). In the view’s form tag call the Html.AntiForgeryToken helper (See http://msdn.microsoft.com/en-us/library/dd470175.aspx) with following syntax:

Web Forms:

<%= Html.AntiForgeryToken() %>

Razor:

@Html.AntiForgeryToken()
share|improve this answer

It is difficult to execute a successfull CSRF attack on an application using viewstate but not impossible. One way to do a succcessful CSRF attack on an application with _viewstate is

  1. Attacker is able to login to the application ( using own or aquired credentials)
  2. Visit the page (with most common or most useful variable states) against which she wants to create a CSRF attack for
  3. Copy the _Viewstate
  4. Insert this _viewstate in her attack page
  5. Send the attack page to the victim
  6. With some luck and good guessing the attack might just work

A solution to this has been introduced in 1.1. Instead of using just _viewstate you can use ViewStateUser-Key . This uses the use session key to create the state token which will be really difficult to guess or copy by the attacker.

I would still suggest implementing an indenpendent CSRF token mechanism for protection against CSRF in your application ( I know many will differ on this)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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