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 a happy hour moderating and learning a lot of cool stuff about ASP.NET and related technologies. There are many things that can go wrong with viewstate, and many ways to make using it more efficient. Sometimes it s a security problem; other times, it is more mundane and obscure.
Recently, someone started a thread about a problem with viewstate that 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 know what the problem is:
Unable to validate data.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Web.HttpException: Unable to validate data.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the 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 viewstate failed. 1) If this is a cluster, edit <machineKey> configuration so all servers use the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. 2) Viewstate can only be posted back to the same page. 3) The viewstate 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; .NET CLR 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 and to protect the poster, in case there is anything sensitive in it.)
What do you think? Where would you start looking for the problem?
Hmm. With these kinds of problems, you can often find the answer by scanning the exception output. (Yes, Microsoft has gotten far better at providing useful information in error messages.) The quick and dirty evidence includes several items:
- Unable to validate data. On the surface, this may or may not point to the viewstate, because there may be other validation going on. But viewstate is a prime candidate.
- The viewstate for this page might be corrupted. Lots of possibilities for this, security and otherwise. There could be a problem with encryption keys or regular old bit shifting as it traverses the network.
- System.Web.Configuration.MachineKey.GetDecodedData. This is the method that threw the exception. MachineKeys in the config files are responsible for providing the key for encrypting data, so this is beginning to look like a security problem.
- Authentication of veiwstate failed. This may mean that it is a security issue or some other kind of viewstate problem.
There are a lot of possibilities at this point. Threading can cause problems, as can incorrect machine key settings. You might consider worker process recycling or being used in a server farm. But what is really maddening is that often the problem only happens sporadically, which can make debugging maddening. In the case of one poster, it happened on only a single page 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 them wherever they need to go. But often the problem persists. Sometimes the problem arises due to bugs in the .NET Framework, such as problems with the RijndaelManaged 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 that it happens sporadically. This particular problem came about only when the user stopped a postback to the page either by clicking the browser s stop or back buttons. Then the browser doesn t finish sending the viewstate data, and the server reports a problem, thinking that it can t properly validate corrupted data. And off you go on wild goose chases to resolve the issue.
I don t have any hard evidence, but I suspect that the problem is amplified when the page s viewstate data is huge. More data, more time to transmit, and more likely a stop is going to happen before the data is fully posted back.
See? As hard and mysterious as security can be, security is not always the source of coding problems. Often when it walks like a security problem and quacks like a security problem, it isn t a security problem at all. Digging more deeply is the only way to find the true answer.
This sort of thing gets posted in both the State Management and Security forums, and we moderators have a hard time deciding where 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 of this year: http://forums.asp.net/t/1063094.aspx. Kudos to everyone who responded to help the poster solve the problem, finding the solution that was probably as non-intuitive as they come!
Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications 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 read his blog at http://www.sqljunkies.com/weblog/donkiely/.
