I have an odd reoccurring error that I believe is related to View State and security settings. This error appears on one of my client’s site between 1 to 6 times a day:
Source: System.Web
Error in: /detail.aspx?CaseID=1852
Error Message: Unable to validate data.
Stack Trace: at System.Web.Configuration.MachineKeySection.**EncryptOrDecryptData(**Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
Researching online has lead to a deadend. I believe it has do with security and ViewState. Because this is an ecommerce site, I took the extra steps of protecting against a number of treats, includign XSS and CSFR. Here are the steps I took:
Turned on HTTPOnly Cookies (Protects against XSS Style Attacks)
Turned on Secure Cookie Flag (Protects against XSS Style Attacks)
Created a BasePage which all the pages inherit instead of Page, in the Basepage I overrides OnInit and set ViewStateUserKey to SessionID (Protects against certain CSFR Style Attacks)
Explicitly enabled validateRequest (On by default, but can be overwritten)
ViewState Encryption Enabled
The website is hosted on a Win2003 Virtual Server, using ASP.NET 3.5 SP1 and AJAX. The page is not using caching, which some articles I found suggested was a problem when you set the ViewStateUserKey key to a unique value, such as SessionID. I can duplicate this exact error if I turn off cookies in my browser and try to view one of the pages that creates the error.
Notes, The error message does NOT mention MAC has failed
My theory is that those that experience this error are on networks that have a Proxy/Caching Server. My solution was to only set the ViewStateUserKey when it was a secure connection. Most Proxy/Caching Servers are only set to cache HTTP connections, not secure connections.
Related
I tried this:
runas /user: domain\user cmd with no luck
This seems to only occur now when IIS is reset and I try to resume my browsing session. So I am logged into the application, I reset IIS on the server, refresh the page and see the error.
I am building an application in .NET 4.0 MVC with a Secure Token Service that is using WIF 4.0. Everything works as expected, except this case. I even tried to use a custom error page, but the error is happening there as well. Because of that, I can't get the custom page to show either. Also, This is using a certificate that is located on both load balanced servers. This happens in my dev environment whihc consists of only one server (app, wfe, db operated there)
One thing I noticed is that if I switch my IIS APP Pool user back to Network Service account it doesn't throw the error any more. We have some restrictions (mostly network related) in the application that we need to use an account in our AD for the app pool sections
Anybody have any experience with this issue?
Key not valid for use in specified state.
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.Security.Cryptography.CryptographicException: Key not valid for
use in specified state.
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:
[CryptographicException: Key not valid for use in specified state. ]
System.Security.Cryptography.ProtectedData.Unprotect(Byte[]
encryptedData, Byte[] optionalEntropy, DataProtectionScope scope) +428
Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode(Byte[]
encoded) +54
[InvalidOperationException: ID1073: A CryptographicException occurred
when attempting to decrypt the cookie using the ProtectedData API (see
inner exception for details). If you are using IIS 7.5, this could be
due to the loadUserProfile setting on the Application Pool being set
to false. ]
Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode(Byte[]
encoded) +146
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[]
cookie, Boolean outbound) +113
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader
reader, SecurityTokenResolver tokenResolver) +647
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte[]
token, SecurityTokenResolver tokenResolver) +105
Microsoft.IdentityModel.Web.SessionAuthenticationModule.ReadSessionTokenFromCookie(Byte[]
sessionCookie) +262
Microsoft.IdentityModel.Web.SessionAuthenticationModule.TryReadSessionTokenFromCookie(SessionSecurityToken&
sessionToken) +76
Microsoft.IdentityModel.Web.SessionAuthenticationModule.OnAuthenticateRequest(Object
sender, EventArgs eventArgs) +53
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
+148 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75
This issue is related to session cookies.
WIF protects session cookies using Data Protection API (DPAPI) by default, and the DPAPI is closely related to machine keys.
If the keys used to encrypt the session cookies change, it throws this exception.
It could be also related to your app hosting infrastructure.
if your app is running in an Network Load Balancer (NLB) environment
if you change the app pool settings (e.g., change the pool’s user)
More details about this scenario on the MSDN blog entry:
WIF 1.0 – ID1073 A CryptographicException occurred when attempting to decrypt the cookie using the ProtectedData API Archive.Today Shortlink
Todd Foust (October 29, 2012)
So, if your app runs in NLB environment, you could :
Configure your load balancer to use sticky sessions. This means that your user will be directed to the same server during the session duration. (I’m not very fond of that one)
Use a certificate to encrypt the session cookies
set all web.config files to use the same machine key in system.web
If you are not running the app in a NLB env, you could try:
set the machinekey in your web.config to use a pre-defined value instead of auto-generated values
Regarding auto-generated machinekey setting, please see:
How unique is your machine key?Archive.Today Shortlink
I think that I've tried all of the standard responses to this problem, and I know that I've read hundreds of questions and posts about this problem, but none of them seem to have resolved it or shed any light on what the cause is in my scenario. (I'm 5 hours down and no nearer :-( )
I have a web-farm of 2 servers.
I have set the machine key and validation key in machine.config on both machines
Encryption: SHA1, Decryption: AES - These are the defaults, could it help to change them?
I have verified that no other config files in the chain (web.cfg, apphost etc.) have a setting for these values.
I have added a page to the site (based on this SO) that spits the machine key values back out, and verified that they are the same across requests to both machines and match the values that are in machine .config
The server side session state is in a shared state-server, I have verified that sessionid remains constant between requests to the 2 servers.
I have verified that the page is completely loaded and the __EVENTVALIDATION hidden field has been rendered into the page before initiating the post. The viewstate size is not too bad at 7.64kb
When a page is rendered from a request to server 1 and then posted back to server 2, I get the dreaded...
Error Message:
Unable to validate data.
at System.Web.Configuration.MachineKeySection.GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength)
at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) HttpApplication.RecordError => HttpApplication.RaiseOnError => global_asax.Application_Error
The post is triggered by a standard, unadulterated asp linkbutton, there is no ajax going on on the page.
Any and all help will be greatly appreciated.
Setting enableViewStateMAC = false is not a solution :-)
Having inherited the servers in the state that they were configured, I never questioned the validity of the keys!!! ...Just checked that they matched on both servers...
Leaving all the encryption / decryption and validation algorithm settings as they were, I generated new keys using this tool which has a few more options than the others.
Problem solved
Moral of the story: If in doubt, generate new keys
... but why and how? Some postbacks with viewstate were working just fine with the old keys, it was only when the postback was to a different server that the problem became evident. If the keys were invalid - missing a character or something - then every postback should have failed - I think
If you've established that the machine keys are the same on both boxes, could it be the encryption/decryption thereof ?
Have you tried using Triple DES and setting the decryptionKey in the machine.config on both servers?
Check here
Also a easy way of making sure the machineKeys are the same is to add a line like this in the web.config.
NB: Assuming you have the same web.config on both servers and making sure that the validationKey and decryptionKey is valid
You can use http://aspnetresources.com/tools/machineKey to generate it.
<system.web>
<machineKey validationKey="*D9B0EDEA69D81A89BF5FBA2B08BAF691013F86B89A1F6BA8068C6ECC9539074" decryptionKey="*AE2B1966AF65D08F03EDFB" validation="SHA1" decryption="AES" />
We're using the Jasig .NET CAS Client to interface with our organization's CAS SSO server.
However, we've noticed that in ASP.NET MVC 3 (and I would assume this affects ASP.NET WebForms as well) applications, when users log out, we see the following error in our error log:
System.Web.HttpRequestValidationException (0x80004005):
A potentially dangerous Request.Form value was detected from the client
(logoutRequest="<samlp:LogoutRequest...").
at System.Web.HttpRequest.ValidateString(String value, String collectionKey, RequestValidationSource requestCollection)
at System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, RequestValidationSource requestCollection)
at System.Web.HttpRequest.get_Form()
at System.Web.HttpRequest.FillInParamsCollection()
at System.Web.HttpRequest.GetParams()
at DotNetCasClient.Utils.RequestEvaluator.GetRequestIsCasSingleSignOut() in C:\Projects\Jasig\CAS\dotnet-client\trunk\DotNetCasClient\Utils\RequestEvaluator.cs:line 292
at DotNetCasClient.CasAuthenticationModule.OnBeginRequest(Object sender, EventArgs e) in C:\Projects\Jasig\CAS\dotnet-client\trunk\DotNetCasClient\CasAuthenticationModule.cs:line 93
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I don't believe this is an error message users are receiving -- it seems to only be seen by the server. As far as the users are concerned, log out is successful.
Is there any way I can get ASP.NET MVC to stop trying to validate these types of requests? I know I can disable request validation completely, but that's out of the question. The site with a hyphen has a good question on this, but not really an acceptable answer:
add the following setting to the web.config:
<httpRuntime requestValidationMode="2.0" />
After setting this value, U can disable request validation by setting validateRequest="false"
So, is there any way to disable ASP.NET validation for this request without turning it off completely?
Edit: This is also tricky to debug because this request is coming from the CAS server, NOT from the user's browser. I think this is the CAS server attempting to notify all running applications that the user has signed out (single sign out). So we're only receiving this error in production, not when testing locally.
The dotnetcas client gets access to the request before it gets to an MVC controller action, so it is not possible to simply set the validation attribute on an MVC controller or action.
The target of this request seems to be the last URL that was validated, so it is not possible to disable validation for a specific path in your application by using this method either: http://erikbra.wordpress.com/2012/04/17/wif-saml-token-post-and-requestvalidationmode2-0/
From what I see you have a couple of options:
Disable this validation:
<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>
or
.Net 4.5 allows you to access a request before it goes through validation. If you have access to this you can re-compile the client from source, fixing the relevant issue.
I am not familar with Jasig .NET CAS but ASP.NET MVC allows you to disable request validation at the page level.
Add the following attribute to your controller action:
[ValidateInput(false)]
I am fairly new to ASP.NET. I recently set up automated email from my website to notify me of an unhandled exceptions. Just a few hours ago in 3 minutes there were 10 unhandled exceptions and all stack traces were similar. There is a lot in the error messages I do not understand, but I do not like the way this looks.
Here is one of the email messages:
An unhandled exception occurred:
Message: Padding is invalid and cannot be removed.
Stack Trace:
at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)
at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Is this an attempt to hack into my site or something else?
Many thanks go to those who provided Answers and Comments provided which pointed me in the right direction to get an answer to this exception. It's cause can be difficult to determine, especially when not occuring in a web farm.
IE 5.5 was not causing the problem as I had earlier thought.
It was not easily found, but a post on my web host forum by one of the staff mentioned reports of Viewstate errors. The cause was attributed to the asp worker process or the server recycling.
The asp worker process settings refers to the processModel Element in the machine.config file. See http://msdn.microsoft.com/en-us/library/7w2sway1(VS.80).aspx for more information.
The recommended fix was to set an encrypted machineKey in the web.config file. The Machine Key node is in the system.web element.
This was easily done and solved the problem thanks to the handy ASP.NETResources site which has a MachineKey Generator. See http://www.aspnetresources.com/tools/keycreator.aspx.
This exception is thrown when the assembly resource handler gets an invalid request. It is unlikely this is related to any malicious activity; it's usually caused by an incorrectly configured machine config on the server.
Some background:
ASP.NET has built-in mechanisms for exposing resources from the assembly (dll) via an HttpHandler. Resources such as JavaScripts and images can be stored as text in the assembly and requested by the browser via .axd handlers. But for security reasons, the handlers don't accept a plain-text location of the resource, which might expose clues about how your code works. Instead, it uses information in the machine.config on the server to encrypt a unique identifier to the resource. This exception gets thrown when a resource is requested, but when the server tries to decrypt the identifier provided, it fails.
The error is because your appdomain was recycled/restarted. When that happens the application and the machine key is set to auto, it changes. That affects the decryption of the info in the url of the resources urls (.axd). Setting up a fixed machine key will prevent it from ever happening again.
Please check this for more info on a similar case (the explanation is with an issue with viewstate validation, but the cause is the same one):
http://www.developmentnow.com/blog/InvalidViewstate+Or+Unable+To+Validate+Data+Error.aspx
Ps. this explains it on single server deployments :) - although the solution is the same for both multi-single server, the fix was usually only explained to make all servers use the same machine key.
Update 1: The padding is invalid message doesn't have relation to the css padding. If it is only happening on ie 5.5, it is likely the parameters for the webresource.axd are being messed up, just like in this question: Invalid Webresource.axd parameters being generated.
I don't know if anyone has seen this issue before but I'm just stumped. Here's the unhandled exception message that my error page is capturing.
Error Message: 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: at
System.Web.UI.ViewStateException.ThrowError(Exception
inner, String persistedState, String
errorPageMessage, Boolean
macValidationError) at
System.Web.UI.ObjectStateFormatter.Deserialize(String
inputString) at
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String
serializedState) at
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter
formatter, String serializedState) 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()
at
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext
context) at
System.Web.UI.Page.ProcessRequest(HttpContext
context) at
ASP.generic_aspx.ProcessRequest(HttpContext
context) at
System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at
System.Web.HttpApplication.ExecuteStep(IExecutionStep
step, Boolean& completedSynchronously)
Source: System.Web
Anybody have any ideas on how I could resolve this? Thanks.
I seem to recall that this error can occur if you click a button/link etc before the page has fully loaded.
If this is the case, the error is caused by an ASP.net 2.0 feature called Event Validation. This is a security feature that ensures that postback actions only come from events allowed and created by the server to help prevent spoofed postbacks. This feature is implemented by having controls register valid events when they render (as in, during their actual Render() methods). The end result is that at the bottom of your rendered
form tag, you'll see something like this:
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="AEBnx7v.........tS" />
When a postback occurs, ASP.net uses the values stored in this hidden field to ensure that the button you clicked invokes a valid event. If it's not valid, you get the exception that you've been seeing.
The problem you're seeing happens specifically when you postback before the EventValidation field has been rendered. If EventValidation is enabled (which it is, by default), but ASP.net doesn't see the hidden field when you postback, you also get the exception. If you submit a form before it has been entirely rendered, then chances are the EventValidation field has not yet been rendered, and thus ASP.net cannot validate your click.
One work around is of course to just disable event validation, but you have to be aware of the security implications. Alternatively, just never post back before the form has finished rendering. Of course, that's hard to tell your users, but perhaps you could disable the UI until the form has rendered?
from http://forums.asp.net/p/955145/1173230.aspx
#Chris
if the problem is clicking an item before the page has completely rendered, asp.net 3.5 SP1 added a web.config entry on the page element called renderAllHiddenFieldsAtTopOfForm.
do you have multiple servers running this application and/or have a web garden? If yes, you are going to have to set the machine key in the web.config
By default, ASP.NET includes a digital signature of the ViewState value in the page. It does so with an automatically-generated key that is held in memory. This is done to prevent a malicious user from altering the ViewState from the browser and, for example, grant him/herself access to stuff they wouldn't normally have access to.
ASP.NET can also, optionally, encrypt the ViewState, but it's turned off by default for performance reasons. In many web sites, it is a lot more important to make sure that the content of the ViewState is not 'mucked with', than it is to keep it confidential.
The error message says that the signature verification failed. The page was posted with a ViewState, but the ViewState signature didn't match the signature calculated with the keys held by the server.
The most common reason for this error is that you are using two or more web servers in a farm-like environment: one server sends the original page, signed with the key in memory on that server, but the page is posted back to the second (or third...) server. Because the two or more servers don't share the signature key, the signatures don't match.
...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.
What the error message is telling you is to use the validationKey attribute (see details in MSDN) in your web.config to hardcode the signature key to a value shared by all your servers, instead of using a dynamically-generated one. That way, the signature validation can succeed independently of which server receives the postback.
You could turn off the verification, but it's very dangerous to do so. It means any hacker with a bit of free time can fake values in your application. For example, if you keep the price of the item in a ViewState value, the hacker could change the value from the browser to $0.01 right before putting the order.
For anyone else ending up struggling with this issue here is a helpful link to some work arounds:
http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
I know you can disable the Validation of viewstate MAC, but I think if the page is not loaded you can get into more trouble. When I ran into this problem I had to disable all buttons until the page was fully loaded.