I know this was posted here so many times and had a valuable suggestions and suggested fixes. But none of them helped.
We have an e commerce site which is online ordering system. Our web site is hosted on IIS 7.0 with .net framework 4.0.(this is the only website running on IIS ). In our testing environment everything worked fine and we deployed it.
Now we are getting MAC ERROR when user is trying to access the site or if he is in the site and browsing to other pages, user is facing this error. Here is the stack trace.
Exception: 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.
Stack Trace: System.Web.HttpException
Stack Trace:
at System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) at System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose) at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Purpose purpose) at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose) at System.Web.UI.HiddenFieldPageStatePersister.Load() at System.Web.UI.Page.LoadPageStateFromPersistenceMedium() at System.Web.UI.Page.LoadAllState() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) at System.Web.UI.Page.ProcessRequest(HttpContext context) at ASP.pages_usagereports_index_aspx.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
We started getting this issue when we implemented a code to fix CSRF issue in the base page.
If we take out the code and tested with a user, we are not getting any error.
So far we have tried these solutions
1) Applied machine key to the website even though we are not web farm environment.
2) We don’t want to disable the enableviewstate to false or the viewstateencryption mode to never as it is preferred not to do that. We even tried this but didn’t help.
3) We tried assigning different combinations for the base.viewstateuserkey like combination of userhostaddress and user Agent but it didn't help.
4) We used Microsoft .net web protection library from this link
http://software-security.sans.org/developer-how-to/developer-guide-csrf
After this we started getting another error
Inner Exception Type: System.InvalidOperationException
Inner Exception: Validation of Anti-XSRF token failed.
Inner Stack Trace:
at System.Web.UI.Page.HandleError(Exception e) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) at System.Web.UI.Page.ProcessRequest(HttpContext context) at ASP.signin_aspx.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Now we are getting two errors. MAC error and Anti XSRF error.
Searched on this error and I saw number of posts but i tried them. None of them helped.
Any suggestions on this are much appreciated.
Thanks in advance
The MAC for the ViewState is derived using the ANtiXsrfTokenKey generated in your master page. If the token is not present when the user accesses your site (cookies disabled or the value in the cookie changed or deleted) then the page will generate a new token. What then happens, if there is a ViewState in the page being posted back, is that the MAC will be checked with the new Token and won't match the old token, that is the first error you can see.
The Xsrf check in your master page is slightly confusing but uses the Xsrf token stored in a cookie and matches it to the value stored in the page. Usually these will match but if another site attempts to make an illegal request to your site, their site won't send the Xsrf cookie and the check will fail. The reason that this is confusing is that if you have a ViewState, this will fail before the Xsrf check.
Another issue with the Xsrf check is that it uses the logged in user's name as part of the check. If a user is logged in and then the auth cookie is deleted or expires, this part of the check will fail and you will see an Xsrf failure which is misleading, the real error is that "the authentication has expired causing the Xsrf check to fail".
I have re-worked the functions in Site.Master.cs several times to make these errors more clear.
Hope that helps.
Related
Getting this error randomly on server here is the iis details.
IIS version= 10.0.14393.0
Windows server 2016
System.Web.Management.WebRequestErrorEvent, System.InvalidOperationException, An unhandled exception has occurred.The resource class for this page was not found. Please check if the resource file exists and try again.
Stack trace: at System.Web.Compilation.LocalResXResourceProvider.CreateResourceManager()
at System.Web.Compilation.BaseResXResourceProvider.EnsureResourceManager()
at System.Web.Compilation.BaseResXResourceProvider.GetObject(String resourceKey, CultureInfo culture)
at System.Web.Compilation.ResourceExpressionBuilder.GetResourceObject(IResourceProvider resourceProvider, String resourceKey, CultureInfo culture, Type objType, String propName)
at ASP.usercontrols_uc_adduser_ascx.__BuildControlImage1()
at ASP.usercontrols_uc_adduser_ascx.__BuildControlcontractorUC_RadAjaxLoadingPanel1()
at ASP.usercontrols_uc_adduser_ascx.__BuildControlTree(secure_usercontrols_uc_adduser_ascx __ctrl)
at ASP.testpage_aspx.__BuildControlAddQuickContractor1()
at ASP.testpage_aspx.__BuildControlfrmMain()
at ASP.testpage_aspx.__BuildControlTree(secure_bidmain_aspx __ctrl)
at ASP.testpage_aspx.FrameworkInitialize()
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
This error is coming randomly, but after recycling the app pool fixes it. Can some help with this.
I doubt if the case relates to the Network/Route issue. For example, some requests are discarded by the application gateway, which may be caused by the wrong NAT tables configured in the public firewall or router. You could verify this by accessing the website with a local IP.
please check the below issue.
https://serverfault.com/questions/845606/iis-randomly-returning-inet-e-resource-not-found
My server is throwing errors like this. I suppose some kind of attack is takign place. I have IIS7, Windows server 2012.
System.Web.HttpRequestValidationException (0x80004005): A potentially dangerous Request.RawUrl value was detected from the client (="...?return="><noembed><img+src%3D...").
at System.Web.HttpRequest.ValidateString(String value, String collectionKey, RequestValidationSource requestCollection)
at System.Web.HttpRequest.get_RawUrl()
at System.Web.UI.Page.ValidateRawUrlIfRequired()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
It is basically warning for a cross-site scripting attack (XSS): https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
This means somebody is trying to inject valid HTML into your webpage using the query-string. If your webserver is programmed to subsequently display this somewhere else (maybe a forum or something) then this opens up an attack vector. Other visiting users to your site might execute JavaScript code injected by the attacker.
To prevent this, ASP.NET by default does not allow certain content to appear in the query string, specifically anything that resembles valid HTML. This could be caused by an input-field somewhere on your website that does not correctly escape HTML characters OR someone is simply trying to attack you website. Either way, make sure to always escape user-controlled input correctly on the server or on the client (or both).
If you think your security is OK, then you can ignore this error as it is basically out of your control. ASP.NET simply detected the attack and blocked it.
I've got a client with a legacy ASP.NET WebForms app that was, previously, running ASP.NET 2.0. The site needed a new feature that necessitated using a third-party component that required ASP.NET 4, so we moved his application from ASP.NET 2.0 to ASP.NET 4.0 and the move went smoothly except we're getting the following intermittent exception:
System.IndexOutOfRangeException
Index was outside the bounds of the array.
System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.IndexOutOfRangeException: Index was outside the bounds of the array.
at System.Web.UI.WebControls.GridView.LoadControlState(Object savedState)
at System.Web.UI.Control.LoadControlStateInternal(Object savedStateObj)
at System.Web.UI.Page.LoadAllState()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.HandleError(Exception e)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at ASP.maintenancetechnician_advancedsearch_aspx.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
There were some Stack Overflow questions on this, but all had to do with load balanced/multi-server environments and having this happen when a request bounced from one server with different settings than another (such as one having had some .NET SP installed and the other not).
But this is running in a single-server environment.
Moreover, this problem didn't start until the upgrade to ASP.NET 4. Searching hte ELMAH error logs reveals that this exception has happened 8 times today and not once prior to today (as far back as our logs go, at least, which is a month).
Any ideas on where to go from here?
I agree that posting code would help, but I think I may know what's happening. We ran into a similar issue a few months ago. It ended up being that the Gridview control had it's EnableViewState set to false. Check that viewstate is enabled on the grid and see if that clears it up.
This site has a decent description of what happens when the viewstate is off:
http://forums.asp.net/t/1026981.aspx?ObjectDataSource+GridView+Disabled+ViewState+Major+Concurrency+Issues+possible+solution+
In our website (ASP.NET Forms, Sitecore 6.6), in the log files I find so many viewstate exceptions. But there is no obvious issues reported by the users.
Here is the exception, by referring to the log files I found that this issue mainly occurs in a particular page which has a viewstate like 20KB. Please help to sort out this issue.
5676 00:30:43 ERROR Application error.
Exception: System.Web.HttpException
Message: The client disconnected.
Source: System.Web
at System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError)
at System.Web.UI.HiddenFieldPageStatePersister.Load()
at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
at System.Web.UI.Page.LoadAllState()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Nested Exception
Exception: System.Web.UI.ViewStateException
Message: Invalid viewstate.
Client IP: xxx.xxx.xxx.249
Port: 53377
Referer: <URL>
Path: /<PATH>
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B329 Safari/8536.25
ViewState: cT4jo/ieR1NMvyqfwH6MToZmW6E/oKO64RcFXyllzcXB84wiWN/j3WeRyXxUZWCnr9c6staUp76B0Zr7/IqYgWWS3qfiMu9xzpU61bB+TAjDz0IbVwSt0rvZoFh7M/tQGQWyRha4ieCH7B5wKu3hXexRTIWwvP0JLbNmnQyFnOdqTnJZXBYQtaTyzMva3Fy7Q9YNstymtd1XrO1WHvUsBS6CwyV8eUYZs3LWRvczf3Ixz2XRg2Y4fY4kpuXl+QJLkbhgnALcFeGe9ur1l8Gyq6EdhqRb0BOlK4ozKaq4hpUT6HWes9YP2DjCJCpa2wP47hqZ5DaAXrcN+R6UPOqYIl6TSIjNUCv35NPPozaFjItLGmZi6ee+PfxOSz4ejxgBJzV3KNf2/1Mr5GNI7uZWgw998CI0mtxtpuWjp5kZCAfKzSCX//Vv7030VBLAE4Gj1RYIek1WNuwDreglFE5Pt8uKMDOsJstt8tXGqyCVcxqQAnRyN51e3uuqbDvDL2yVXA6yv6QyaCD/XmIHcgz//HItyqlhEziyOx7MxwKzpMyLu/6g2poqKMoNWtnQwxw9JTVwijEf45Lai+BOmgMNITgyrmLDp7ioHgHFK0VSmrSxN2W+CBRyyXWfn3QAy8UQYpq1TdHEUnGbc3XTTfBYW/gj+mFGaEpM24hUi/gJBxU2r+/wG2XxHfsxgrq6kG5cM8Hzf4GHuSC4...
Nested Exception
Exception: System.FormatException
Message: Invalid length for a Base-64 char array or string.
Source: mscorlib
at System.Convert.FromBase64_Decode(Char* startInputPtr, Int32 inputLength, Byte* startDestPtr, Int32 destLength)
at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
at System.Convert.FromBase64String(String s)
at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose)
at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose)
at System.Web.UI.HiddenFieldPageStatePersister.Load()
We have also seen this on our load balanced servers, specifically on pages where we use some form of ajax control (either ajax control toolkit, or home-grown).
The issue appears to be that the customer invokes some form of ajax request, then either closes their browser or goes to a different page either by a link or the browser back/forward controls.
One thing you can do, if you have control over when your response is sent to the client, is to do the following:
if(HttpContext.Current.Response.IsClientConnceted) {
//Send response
}
This should remove the error from your logs.
I've seen this same exception message in our logs for some time now and I have never been able to reproduce the issue until today, so I thought that I'd share my experience.
On a page using Ajax Update Panels, the user can first load the page. Then the user can invoke an Ajax request. If the user invokes another Ajax request, but hits the back button before the second Ajax request finished loading then the user is redirected to the previous page and the exception message is logged.
The user experience is not interrupted when this message is logged and therefore, the user doesn't know that anything happened behind the scenes. The exception message is accurate in terms of how view state is handled in the ASP.Net page life cycle.
I would say that the exception message is safe to ignore and you could likely find a solution to avoid having the exception message logged in the first place.
As a note, adding machine keys or addressing web server config settings has never helped me in any case regarding this exception message primarily because, in most cases, I was not using a web farm.
I usually hate posting these types of questions as normally I find that the best way to really learn is to figure out the answer yourself.
However, I need an answer to this question really quickly as I have a client who can't run her business due to this problem.
Yesterday my ASP.NET host provider moved my application from a server running .NET 1.1 to one running .NET 1.1 and 2.0. My problem is that when I test the move the main site page (Default.aspx) will not load
"Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.
Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."
[SecurityException: Request for the permission of type 'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) +0
System.Security.CodeAccessPermission.Demand() +59
System.Net.HttpWebRequest..ctor(Uri uri, ServicePoint servicePoint) +147
System.Net.HttpRequestCreator.Create(Uri Uri) +26
System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase) +298
System.Net.WebRequest.Create(Uri requestUri) +28
System.Web.Services.Protocols.WebClientProtocol.GetWebRequest(Uri uri) +30
System.Web.Services.Protocols.HttpWebClientProtocol.GetWebRequest(Uri uri) +12
System.Web.Services.Protocols.SoapHttpClientProtocol.GetWebRequest(Uri uri) +4
System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) +52
PilatesPlusDublin.PilatesPlusDublinws.PilatesPlus.InsertException(String sModuleName, String sException, Int32 iUserID) +97
PilatesPlusDublin.MainDefault.Page_Load(Object sender, EventArgs e) +144
System.Web.UI.Control.OnLoad(EventArgs e) +99
System.Web.UI.Control.LoadRecursive() +47
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +7350
System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +213
System.Web.UI.Page.ProcessRequest() +86
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +18
System.Web.UI.Page.ProcessRequest(HttpContext context) +49
ASP.maindefault_aspx.ProcessRequest(HttpContext context) +4
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +358
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64"
If WebPermission isn't available at the hosting site, how do I configure my site to allow access to the page? Is there some tags that need to be put into the web.config? Note - we have no access to machine.config or any other IIS settings.
I understand that people hate reading and answering these types of question but any help on what I, or my hosting site need to do to fix this would be appreciated enormously
Not sure if this will help, but I once had a client with the same type of problem. Their webhosting company made some changes, resulting in their website throwing similar kinds of errors. Managed to get things working again by adding the following just inside the System.Web section in web.config:
<trust level="Full" />
If this doesn't solve your problem and the webhosting can't fix things on their until the new year, I'd seriously consider switching hosting providers.
Just as an FYI to anyone that might have the same problem - I got this exact error message and couldn't figure out what was wrong since I hadn't changed any settings on my local box.
I realized after a couple minutes that I had accidentally opened the project from a network share on Windows Server 2008. Of course the permissions weren't correct! Really stupid move, but if it helps someone I am willing to be humiliated :)
I am posting this in case it helps anyone else. Be warned before they move an existing ASP.NET site hosted by your provider to another sever.
MAKE SURE YOU ASK THEM ABOUT WEBPERMISSIONS AND TRUST LEVELS.
This was my providers reply....
"Thank you for your email.
It's failing because WebPermission isn't available in a medium trust environment.
We can't make any changes to these servers at the moment, since we plan to migrate all sites on to a pair of new clusters by the end of this year. I'm confident that the new Windows cluster will have WebPermission available, since it's enabled on the current Namesco Windows cluster. "
So they expect my client's site to be offline and losing business until the New Year.
Is your web application calling a web service or accessing external web sites? If so, you might need to talk with your hosting provider and ask for the URI to be added to the list of allowed connection endpoints.