ASP.NET app having viewstate corrupted every few minutes

1
votes

I'm having a problem with a web app I'm managing. Users starting receiving the following error occasionally:

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

The problem is that it's not a cluster - it's a single Windows 2003 server. After digging around, it appears that adding a machineKey section and some extra attributes to the Pages directive in my web.config resolves this error:

<machineKey validationKey='MACHINE KEY SNIPPED'
        decryptionKey='DECRYPTION KEY SNIPPED'
        validation='SHA1'/>

<pages validateRequest="true" enableEventValidation="false">

After changing these two things in my web.config, the error goes away, but now I have a new problem - Instead of an error that my viewstate is invalid, the app just "Forgets" who my user is, and sends them back to the login page. Now, the users are browsing through the application, and then they're unexpectedly sent to the login page, even after they've already been logged in for a few minutes. While I can't force this to happen, it usually happens within visiting 10-12 different pages, so pretty frequently.

I'd love a resolution to this - does anybody know what else might be causing the viewstate error on a single server, or what I can do to ensure that it's validated properly?

2
asp.netasp.net-2.0viewstate
Don't ever turn event validation off. There's a very narrow set of times you want to do this, and trying to get around something that is causing your app pool to recycle is not one of those times. Right now if an attacker knows what they're doing they'll be able to trigger events for disabled or even hidden controls on your page. – blowdart
Are you doing url rewriting? And if so is the url being set to match the page, the form validates against? Changing form validation toasts view state with the same error message.. – Bill Bingham

2 Answers

3
votes

It sounds as though the worker process is recycling itself (assuming you're storing session state in-process). Picking a fixed key means that the viewstate is still valid when the process comes back up, but you've lost the session state. You could try storing the session state in a database, but I'd be more concerned to fix the underlying problem. Does your application suddenly allocate vast amounts of memory, or anything like that? Is there anything suspicious in the event log?

0
votes

It turned out that this began happening when I added additional worked processes to the app pool that was running our application. Because the session state was being stored InProc (and not in a state service or a SQL Server), it was losing track of who the user was when it switched them between working processes. For now, dropping the number of processes on our server back to one corrected the problem, since raising it didn't seem to have any improvement in the first place.