Singing the Viewstate Blues

Secure ASP.NET

Singing the Viewstate Blues

By Don Kiely

Viewstate is often the subject of threads on the http://www.asp.net forums, where I spend many ahappy hour moderating and learning a lot of cool stuff about ASP.NET andrelated technologies. There are many things that can go wrong with viewstate,and many ways to make using it more efficient. Sometimes it s a securityproblem; other times, it is more mundane and obscure.

Recently, someone started a thread about a problem with viewstatethat seemed to be a security issue. The poster was getting an exception that.NET was unable to validate data. Check out the exception and see if you knowwhat the problem is:

Unableto validate data.

Description: Anunhandled exception occurred during the execution of the current web request.Please review the stack trace for more information about the error and where itoriginated in the code.

Exception Details:System.Web.HttpException: Unable to validate data.

Source Error:

An unhandled exception was generated during the executionof the current web request. Information regarding the origin and location ofthe exception can be identified using the exception stack trace below.

Stack Trace:

[HttpException (0x80004005): Unable to validate data.]

  System.Web.Configuration.MachineKey.GetDecodedData(Byte[] buf, Byte[]modifier, Int32 start, Int32 length, Int32& dataLength) +194

  System.Web.UI.LosFormatter.Deserialize(String input) +60

[HttpException (0x80004005): Authentication of viewstatefailed.  1) If this is a cluster, edit configuration so all servers use the same validationKey and validationalgorithm.  AutoGenerate cannot be usedin a cluster.  2) Viewstate can only beposted back to the same page.  3) Theviewstate for this page might be corrupted.]

  System.Web.UI.LosFormatter.Deserialize(String input) +118

  System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +101

[HttpException (0x80004005): Invalid_Viewstate

       Client IP:10.100.110.9

       Port: 3870

       User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NETCLR 2.0.50727)

       ViewState:xwDPx...Vjy+P2m

       Http-Referer:http://www.example.com/admin/logon.aspx

       Path:/Default.aspx.]

  System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +442

  System.Web.UI.Page.LoadPageViewState() +18

  System.Web.UI.Page.ProcessRequestMain() +447

(I ve truncated the viewstate data both to save space andto protect the poster, in case there is anything sensitive in it.)

What do you think? Where would you start looking for theproblem?

Hmm. With these kinds ofproblems, you can often find the answer by scanning the exception output. (Yes,Microsoft has gotten far better at providing useful information in errormessages.) The quick and dirty evidence includes several items:

There are a lot of possibilities at this point. Threadingcan cause problems, as can incorrect machine key settings. You might considerworker process recycling or being used in a server farm. But what is reallymaddening is that often the problem only happens sporadically, which can makedebugging maddening. In the case of one poster, it happened on only a singlepage in the Web application.

The most logical conclusion is the machine key possibility,so you might put in fixed keys for encryption and decryption and propagate themwherever they need to go. But often the problem persists. Sometimes the problemarises due to bugs in the .NET Framework, such as problems with theRijndaelManaged class described here: http://support.microsoft.com/default.aspx/kb/842791.

But often the answer is painfully non-obvious. Ready for the answer? The key piece of information is thatit happens sporadically. This particular problem came about only when the userstopped a postback to the page either by clicking the browser s stop or backbuttons. Then the browser doesn t finish sending the viewstate data, and theserver reports a problem, thinking that it can t properly validate corrupteddata. And off you go on wild goose chases to resolve the issue.

I don t have any hard evidence, but I suspect that theproblem is amplified when the page s viewstate data is huge. More data, moretime to transmit, and more likely a stop is going to happen before the data isfully posted back.

See? As hard and mysterious as security can be, securityis not always the source of coding problems. Often when it walks like asecurity problem and quacks like a security problem, it isn t a securityproblem at all. Digging more deeply is the only way to find the true answer.

This sort of thing gets posted in both the StateManagement and Security forums, and we moderators have a hard time decidingwhere best to put the post to maximize the chances for a successful resolution.Probably the best thread I ve seen about the problem dates back to January ofthis year: http://forums.asp.net/t/1063094.aspx.Kudos to everyone who responded to help the poster solve the problem, findingthe solution that was probably as non-intuitive as they come!

DonKiely, MVP, MCSD, is a senior technology consultant, building customapplications as well as providing business and technology consulting services.His development work involves tools such as SQL Server, Visual Basic, C#,ASP.NET, and Microsoft Office. He writes regularly for several trade journals,and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and readhis blog at http://www.sqljunkies.com/weblog/donkiely/.