A potentially dangerous Request.Form value was detected from the client (ctl00$body$prop_bodytext="Dit kontoudtog vi...").
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.ArgumentException: A potentially dangerous Request.Form value was detected from the client (ctl00$body$prop_bodytext="Dit kontoudtog vi...")
Anybody know what is this error?
This has to do with the requestValidation setting in your web.config.
Set the the value of <httpRuntime requestValidationMode="2.0"/> in your web.config.
See this link for more info.
As the other question suggests, a quick fix is to change the validation mode, allowing any values to be submitted.
You should understand that this is likely because of the value being submitted by your controls. ASP.NET detects it as being a possible script injection attack.
This error is an exception that is generated to trap such attacks so disabling it might not be the best tactic. Instead, try and find out what the part of the submitted string value is that is causing the exception. This way you can trap it on form postback.
In the early days of ASP.NET, this kind of attack was left to the developer to trap. However, this led to undesirable security situations which undermined the reputation of ASP.NET.
Related
My WAS(on AKS) occured following exception.
Request_url: localhost:8443/nice%20ports%2C/Tri%6Eity.txt%2ebak
org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL contained a potentially malicious String "%2e"
...
I think it's because of azure's port scan.(maybe)
My concerns are as follows.
Ignoring exception seems to make security weak.
Handling exception and logging, it seems that unnecessary logs are accumulating periodically.
What choices do you make in your service? or Any other solution?
I have a MVC application created by Devexpress.I get this error on
www.site.com/Accoun/Login
Attempt by security transparent method 'DevExpress.XtraScheduler.Native.
FullTrustAppointmentMultiClientCacheItem.CreateHandler()' to access security critical method 'System.Runtime.InteropServices.GCHandle.Alloc(System.Object)' failed.
Assembly 'DevExpress.XtraScheduler.v13.2.Core, Version=13.2.8.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a' is partially trusted,
which causes the CLR to make it entirely security transparent regardless of any transparency annotations in the assembly itself.
In order to access security critical code, this assembly must be fully trusted.
How can I fix it ?
It is quite hard to suggest something without understanding all the aspects of this situation. You should report this issue directly to DevExpress Support team and provide them with details. I believe their guys can diagnose the error and point you into the right direction in Scheduler usage in MVC environment.
Related support-article: ASPxScheduler and Medium Trust
There is a generic authentication error which does not seem to hit any debug points, and ALWAYS sends the user to "/home/error".
I've searched far and wide, web.config, routing, etc... and can find no trace of a default error handling sending users to /home/error
I would really like to handle my own exceptions with custom messages, and this is preventing that. Any idea where I can look to find some manner of default error handling?
I have a custom ActionResult which is more deeply encountering System.Web.HttpException when the remote host closes the connection. I've already overridden the Controller's OnException method but it's not getting caught there. The ASP.NET MVC pipeline is already done executing my Controller's Action and is now executing the returned ActionResult when it encounters this exception.
Presently, it's bubbling up and being cluttering my log as an ERROR. I'd rather not filter these out at logging time, because I don't consider a remote host aborting the download of the content to be an error.
I'd rather handle this error directly, but I can't tell where. Controller.OnException doesn't work, and so I doubt the IExceptionFilter would either. I could use Application_OnError but I fear that is too high up.
Isn't there a more MVC'ish way?
There are no other points to catch exceptions between Controller.OnException and Application_OnError. Be Brave and use Application_OnError
You can use HandleErrorAttribute to handle exceptions thrown in the controller action. As you pointed out in your question, I would suspect the error is beyond the scope of this attribute. That would leave only Application_OnError.
You could add a whitelist to your error handling code to ignore specific errors (specific type with specific code and maybe specific source/stacktrace).
Which is the best way to handle a system error in ASP.NET MVC? I've watched a video on DimeCast.net in which the guy used the global.ascx file to write a method Application_Error to handle the errors. But currently, I'm handling my errors inside the web.config file.
Could someone point me in the right direction on how to properly handle errors? This could be:
syntax error
exceptions
404 and other page/file not found errors
The application is fairly large.
Take a look at elmah for logging of unhandled exceptions, there's actually a quick example on nuget demo video
I use combination of elmah for unhandled exceptions, and nLog to log ones that I can handle but still want to log. Thus far the combination has worked out very well.
Very likely you are going to need a combination of approaches. Some errors can be handled directly in your models, others in your controllers, and some others might need to be handled all the way to the application level (either via web.config or via the global.ascx.)
I prefer to handle the errors in the global.ascx rather than via redirection in web.config because in the global.ascx I have more information about the request that caused the error where as if I do a redirect via the web.config settings some of that information is lost by the time my error page receives the request.
A few weeks ago I just noticed that 404 errors are better not handled via the web.config because that (by design) causes an HTTP redirect code 302 rather than a true HTTP 404 code that indicates the client that the resource does not exist. I have a post on my blog where I cover this in detail http://hectorcorrea.com/Blog/Returning-HTTP-404-in-ASP.NET-MVC
Using ELMAH as Brook suggested is also a very good idea.