A Quick View State Review

It's been seven years now since the release of the first .NET framework. Throughout all that time there are few aspects of the framework that have been continually misunderstood like the View State. It's a common thread throughout many of the ASP.NET applications that I assess; the View State is misused a lot.

View State misuse leads to a few different problems. Bloat is a common one, and so is accidental disclosure of sensitive data. Every once in a while I'll even see an application with the View State message authentication code (MAC) disabled, allowing attackers to manipulate the View State's values. Of course, the problems with information disclosure and manipulation can be easily solved by turning on View State encryption (and hopefully, setting the ViewStateUserKey* as well). But that's not really addressing the problem at its source.

These problems seem to arise from a basic misunderstanding of the purpose and function of the View State. The standard statement that everyone hears about the View State is that it persists state across postbacks. This simply means that programmatic changes to the properties of any controls will be stored and persisted in the View State across postbacks. Changes to the default properties that are made declaratively or before the control is added to the page's control hierarchy will not be tracked. This means that, ideally, control properties should be set in the ASP code itself instead of in the code-behind file. That way, they won't have a chance to pollute the View State.

This is a pretty key idea and the following two articles, by Scott Mitchell and Dave Reed, respectively, should be required reading for understanding the whole concept.

• http://msdn.microsoft.com/en-us/library/ms972976.aspx
• http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

Both of these articles describe what the View State really is, and more importantly, what it isn't. Applying the information presented in the articles above will go a long way towards reducing security problems with the View State. However, in the cases where sensitive data is still leaking, it may be easier to not use the View State at all. In many cases, it can be completely turned off without impacting the functionality of the application. In other cases, the View State can be disabled on a per-control basis. More good news on this front is that ASP.NET 4.0 will give developers more control over exactly how the View State is used on a page.

* Setting the ViewStateUserKey can help protect against POST-based cross-site request forgery (XSRF) or one-click attacks. However, in order for the ViewStateUserKey to work, the View State MAC must be enabled. Depending on the application, this feature alone may be worth leaving the View State enabled. More information on the ViewStateUserKey property can be found at the following site:

• http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2