I am getting this error, and I know what causes it. There are many causes, but in my case, the issue is that the machinekey differs from server to server (in the web farm) and therefore when it jumpes from machine to machine, it can't decrypt viewstate and/or cookies . I've since fixed this issue, however, there are some users still left with a cookie on their machine, written with the old machinekey, and they are getting this error. I need a good way to handle this error, log them out and then redirect back to the login page. I've tried putting an exception handler in global.asax in Application_error, but this doesn't seem to fire for this error. There are other errors that happen, and I've filtered to catch only this error (by looking at the exception). I have customErrors 'on' in the web.config. How do I do this?
There are a few ways to resolve this issue. The best overall solution is to set the encryption and decryption keys explicitly in the machine.config of each server:
<machineKey validationKey="JFDSGOIEURTJKTREKOIRUWTKLRJTKUROIUFLKSIOSUGOIFDS..." decriptionKey="KAJDFOIAUOILKER534095U43098435H43OI5098479854" validation="SHA1" />
Another option is to disable encryption of the ViewState altogether, but you will lose some security benefits by doing this:
<pages viewStateEncryptionMode="Never" />
Lastly, you can disable the validation:
<pages enableViewStateMac="false" ... />
Related
We have a .NET Framework web app where we use .ASPAUTH cookie and ASP.NET_SessionId for authenticated user. Our Session.Timeout is set to 60 minutes in the IIS hosted web.config file.
Recently I follow the recommendation of OWASP top 10 to prevent possible information exposure by Disable caching for response that contain sensitive data.
I did this by adding the following in the Web.config file of the web app.
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-cache, no-store" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="0" />
</customHeaders>
</httpProtocol>
The very next day I start getting call from some users (not all) that they got redirect to the log out page by simply clicking on links in our web application. So I did what naturally comes to me is to roll back that change and off course that complains went a way gradually.
This puzzle me, as I don't know how http response caching directive could lead to invalidating a user session and log them out. Even though I see the issue went away, there is no way for me to confirm that it was due to my roll back of these header values.
I know the Pragma and Expires are from Pre HTTP 1.1 so I plan to add the following back in and see if I have the log out issue again.
<add name="Cache-Control" value="private, max-age=3600, must-revalidate" />
Do you think they are related? I researched around and all I could come up is the cache control really affect how often the user request resource from server. One factor I don't have control over is can something on the user's browser end that when combine with this Cache-Control directive can destroy their authenticated session?
Update: I see this refers briefly at this resource. However, they don't really go into the details.
I know there are a lot of questions on this topic and I have read them all.
I'm using IIS8, .Net 4.5.
Users randomly get an invalid viewstate error, I can't figure it out. Once this happens the only way they can get back into the site is to clear browser cache.
In my web.config I have:
<system.web>
<machineKey validationKey='....key here' decryptionKey='....decrypt key is valid here' validation='SHA1'/>
<!--<hostingEnvironment shadowCopyBinAssemblies="false" />-->
<authentication mode="None" />
<compilation targetFramework="4.5.1" />
<httpRuntime targetFramework="4.5.1" />
...
</system.web>
I'm running on a virtual private server, and I've yet to find a viewstate larger than 9kb.
My application pool is set to restart at 3:00am, once per day.
My page uses update panels, maybe the user is clicking 'back'? But I've seen it happen just visiting the page with no clicking back.
One thing I noticed is I have 3 different sites using the same application pool identity, but the application pools are seperate. There is no machine keys in machine.xml, but only in my web.config.
A couple of possibilities to investigate:
Update panels are changing form field values (which are what is used to compute ViewState), then the page gets POSTed back to the server, where the new values make validation fail. See this post
You have caching enabled (perform a trace of HTTP headers - make sure you don't have dev tools open) which is causing invalid ViewState to be generated w/ UpdatePanel gumming things up.
Are you using Server.Execute anywhere? (see above link for same)
(less likely) Does your "Virtual Private Server" get migrated to different hardware (perhaps without you knowing it)?
I'm currently fixing some Security issues in our ASP.net website application.
One of the issue was that the ViewState was not encrypted.
So I did check on StackOverFlow and elsewhere on how to encrypt the viewState, and I did it using the <pages viewStateEncryptionMode="Always" /> and adding a 3DES machinekey like this <machineKey validation="3DES" /> in Web.config .
I would like to know if the "EnableViewStateMAC=true" is also compulsorily necessary? since this was mentioned in some of the suggested solutions I had found online.
But, on my checks I found the encryption is working even without this.
[NOTE: I had to do these changes at an application level (Web.config) since making individual page changes is not a practical solution for this application.]
Do not ever set EnableViewStateMac to false, even if encryption is enabled. The MAC guarantees that the client cannot maliciously tamper with the contents of ViewState. (Encryption by itself isn't sufficient to guarantee this; the MAC is necessary.)
The EnableViewStateMac property will be removed in a future version of the product since there is no valid reason to set it to 'false'.
Just in case:
Starting with ASP.NET 4.5.2, the runtime enforces EnableViewStateMac = true
more details here: ASP.NET 4.5.2 and EnableViewStateMac
You might want to note that as of September 2014
All versions of the ASP.NET runtime 1.1 - 4.5.2 now forbid setting
<%# Page EnableViewStateMac="false" %>
and
<pages enableViewStateMac="false" />
http://blogs.msdn.com/b/webdev/archive/2014/09/09/farewell-enableviewstatemac.aspx
It 'll be problem When You host multi server. Because Machine Keys are different.
IF your project runs on single machine. EnableViewStateMAC=true is safely.
Using enableViewStateMac requires that successive requests be forwarded to the same server (i.e. server affinity). This feature is used to help prevent tampering of a page's view state; however, it does so based on an auto-generated validation key on the current server. From this key, a message authentication code (MAC) is generated and sent in the ViewState back to the browser. The problem is that if a POST back is performed and goes to a different server, you will get a nice little error message saying “Corrupt View State“.
To fix this, you can either set enableViewStateMac to false in the element or specify a common value for the validationKey attribute in the element across all servers (in the farm).
By the way, documentation says that this is OFF by default. That is incorrect! Go check machine.config!
I get the following exceptions every couple of days:
System.Web.HttpException (0x80004005): Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. ---> System.Web.UI.ViewStateException: Invalid viewstate.
The thing is that I have a machine key set, and I also use only a single server (ie no cluster). So why is this exception happening? The only thing I can think of is that I keep reseting the IIS server, but I can't quite work out why that's a problem. Do you guys see this exception on a regular basis?
For reference, the following exists under my 'system.web':
<machineKey validationKey="Blah1" decryptionKey="Blah2" validation="SHA1" decryption="AES" />
To elaborate a little on Brian's point, the reason pages which are 'pretty large' experience problems is that those pages are sometimes rendered so slowly that you press the 'submit' button before the ViewState has finished downloading, which causes it to appear corrupted and generates the error.
The only solutions to this are:
disable viewstate completely
use a script to only enable submit after the page is fully loaded
make sure ViewState is as near the top of the page as possible (which I think is bad for SEO if your site is public).
You could try and prove this were the case by seeing if there were any correlation between the speed pages were being loaded and the timing of the exception. Using a tool like LogParser could help with this.
I have something strange going on with our session state.
Our ASP.NET C# application has a session timeout of 10 min, but it seems to be losing session state when redirecting between pages.
So, we set out session value, and redirect to the next step,
Session["temp"] = "somevalue";
Response.Redirect("page2.aspx");
At the top of page2, we check the session value, and if it's not there, redirect back to the start (the code below is the first on Page_Load):
if (Session["temp"] == null)
{
Response.Redirect("start.aspx");
}
The issue is it keeps on doing this redirect, even though the session should not have timed out.
I have checked the config file, and it has a machinekey, as I have been informed that this can sometimes causes issues if it's not there.
Is there something else that could be causing us to lose the session?
Depending how your session's configured, cookie problems can cause you to lose session. As can switching domains / switching between http and https.
And as an aside, if you're connecting over a mobile connection, all sorts of horrible things can happen to your cookies...
Disabled Coockies may be issue. You can also create brand new application (with default web.config without any change) with single page and test it. This will tell you whether the problem is application specific or server specific.
try to add to system.webServer -> modules section in web.config next lines:
<remove name="Session" />
<add name="Session" type="System.Web.SessionState.SessionStateModule" />