After upgrading a project to the RC a System.Web.HttpRequestValidationException is thrown when posting a value containing HTML from a TextArea. I have checked that validateRequest=false in Views/web.config, and have set this in the application's root web.config.
I have also created a fresh MVC project, created a simple view & controller and posted a simple html paragraph element with the same result. Call stack provided. [HttpRequestValidationException (0x80004005): A potentially dangerous Request.Form value was detected
from the client (html="
Sorry, I should have been clear in my original post, I have already attempted to turn this off at page level, to no avail. This is purely arose when upgrading to MVC RC1, and not as a result of a code change. To clarify; validation is also turned off in both
web.config files (root and root/Views).
So whats the point of this in the web.config: <pages validateRequest="false" It even says to use this in the ?Upgrading from Beta? section. Another bug?
“It is not the strongest of the species that survives, nor the most intelligent. It is the one that is the most adaptable to change.”
http://weblogs.asp.net/mikebosch
*** Please MARK this post as ANSWERED, if you find it helpful) ***
In MVC, request validation has to be done at the controller level instead of at the page level because the controller is processing input, not the page. If request validation were done at the page level, then the controller would happily process malicious
input (and potentially commit it to the database!) before the validation check ever took place.
By default, all controllers perform validation after the authorization filters have run. If you want to disable validation per-controller or per-action, decorate the type or method with the [ValidateInput(false)] attribute.
Since the controller is now responsible for validation, it doesn't make sense for the page to do it, so the default Web.config sets the page's ValidateRequest setting to false. This setting only affects pages; the controller does not have the necessary
permission to read this from Web.config. If we didn't make this change to Web.config, then for any controller or action where you want to suppress request validation, you'd also have to do it at the page level or else you'll see exceptions. It's annoying
and counterintuitive to have to suppress it twice, and the check is done before the page loads anyway, so we just suppress it at the page level by default. The first check (at the controller) level is still performed.
There is no such thing as one-size-fits-all when it comes to data validation and all attempts to inflict the same "security measure" to all data are bound to cause problems. In this particular case loads of false positives (base64 encoded data triggering
this message? Come on!) and even more false negatives. Assuming all data that are ever sent to a web application are going to end up printed onto a page with no escaping is silly. And trying to prevent problems automatically, without bothering the "developer"
(or rather the script kiddie that needs this kind of training wheels) is not gonna help.
This validation is very similar to the old automatic singlequote escaping in PHP. Something that was supposed to prevent SQL injection attacks on websites created by people that blindly interpolate stuff they receive from outside into ad-hoc SQL queries.
The result is that the singlequotes are escaped all the time even when the data is used for other things. If you've spent any time on the web, you must have noticed sites that prepend a backslash to every singlequote and keep on prependin\\\\\' and prependin\\\\\'.
The validation is more dangerous though. Instead of adding a backslash somewhere (which looks silly, but most of the time doesn't hurt anything), this validation CRASHES the site. Instead of a "The price must be a number." the site just crashes on you. And
that's still one of the better cases. The crash may easily be triggered by some ENCODED binary data in a hidden field! Something the user had never seen and never touched! And now try to debug that... and try to explain that to the users and to your boss.
Apart from attempting to fit a single validation onto everything there's another problem. You should never ever attempt to find the dangerous stuff, you should always make sure you only have the safe stuff! Whenever you try the first you run the risk of
forgetting something. Yet another character special to the specific use of the data (null character, newline, singlequote, doublequote, less-than sign and lots and lots of others ... sometimes even a dot may be special), yet another sequence of characters
that causes trouble IN THAT PARTICULAR CASE ...
Then, after validating the data (based on what is the set of allowed values of each separate value!) you need to make sure you either do escape the value (based on where do you insert it) or use an interface where you do not need to escape it. In which case
having it automatically escaped is either cause of problems or a pain in the ass because you have to unescape the value again. And then possibly escape it correctly for the way you use them.
In either case HOW DO I TURN THIS ILL-DESIGNED PSEUDOVALIDATION OFF ONCE AND FOR EVER?
security asp.net mvc"ASP.NET MVC"[ValidateInput(false)] repopulate fields Exception"SQL injection""Validation".net mvc 2
ButchersBoy
Member
1 Points
6 Posts
validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 28, 2009 12:17 PM|LINK
hello world
").] System.Web.HttpRequest.ValidateString(String s, String valueName, String collectionName) +8718538 System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, String collectionName) +111 System.Web.HttpRequest.get_Form() +129 System.Web.HttpRequestWrapper.get_Form() +11 System.Web.Mvc.ValueProviderDictionary.PopulateDictionary() +113 System.Web.Mvc.ValueProviderDictionary..ctor(ControllerContext controllerContext) +74 System.Web.Mvc.ControllerBase.get_ValueProvider() +31 System.Web.Mvc.ControllerActionInvoker.GetParameterValue(ControllerContext controllerContext, ParameterDescriptor parameterDescriptor) +53 System.Web.Mvc.ControllerActionInvoker.GetParameterValues(ControllerContext controllerContext, ActionDescriptor actionDescriptor) +109 System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName) +350 System.Web.Mvc.Controller.ExecuteCore() +110 System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext) +27 System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute(RequestContext requestContext) +7 System.Web.Mvc.MvcHandler.ProcessRequest(HttpContextBase httpContext) +119 System.Web.Mvc.MvcHandler.ProcessRequest(HttpContext httpContext) +41 System.Web.Mvc.MvcHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext httpContext) +7 System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +181 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75ASP.NET mvc validateRequest
barkha
Member
2 Points
4 Posts
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 28, 2009 02:57 PM|LINK
ButchersBoy
Member
1 Points
6 Posts
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 28, 2009 03:16 PM|LINK
alivemedia
Member
43 Points
54 Posts
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 28, 2009 04:40 PM|LINK
same problem, it's killing me! Anyone find a solution to this yet?
ASP.NET mvc
JeremyS
Member
506 Points
99 Posts
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 28, 2009 04:51 PM|LINK
ValidateRequest is controlled at the controller level. You need to set the ValidateRequest property on your controller to false.
Jeremy
dario-g
Member
4 Points
4 Posts
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 28, 2009 07:50 PM|LINK
It's workaround? Why in controller?
MikeBosch
Member
617 Points
127 Posts
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 30, 2009 04:10 AM|LINK
http://weblogs.asp.net/mikebosch
*** Please MARK this post as ANSWERED, if you find it helpful) ***
levib
Star
7636 Points
1092 Posts
AspNetTeam
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 30, 2009 04:56 AM|LINK
In MVC, request validation has to be done at the controller level instead of at the page level because the controller is processing input, not the page. If request validation were done at the page level, then the controller would happily process malicious input (and potentially commit it to the database!) before the validation check ever took place.
By default, all controllers perform validation after the authorization filters have run. If you want to disable validation per-controller or per-action, decorate the type or method with the [ValidateInput(false)] attribute.
Since the controller is now responsible for validation, it doesn't make sense for the page to do it, so the default Web.config sets the page's ValidateRequest setting to false. This setting only affects pages; the controller does not have the necessary permission to read this from Web.config. If we didn't make this change to Web.config, then for any controller or action where you want to suppress request validation, you'd also have to do it at the page level or else you'll see exceptions. It's annoying and counterintuitive to have to suppress it twice, and the check is done before the page loads anyway, so we just suppress it at the page level by default. The first check (at the controller) level is still performed.
ChadThiele
Participant
983 Points
274 Posts
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Jan 30, 2009 05:34 AM|LINK
In case the answer wasn't clear... I had the same issue, resolved here: http://forums.asp.net/t/1377500.aspx
JendaPerl
Member
142 Points
51 Posts
Re: validateRequest appears to be kicking in in MVC RC1 despite settings
Aug 20, 2010 12:37 PM|LINK
OK, so let me reword my message.
There is no such thing as one-size-fits-all when it comes to data validation and all attempts to inflict the same "security measure" to all data are bound to cause problems. In this particular case loads of false positives (base64 encoded data triggering this message? Come on!) and even more false negatives. Assuming all data that are ever sent to a web application are going to end up printed onto a page with no escaping is silly. And trying to prevent problems automatically, without bothering the "developer" (or rather the script kiddie that needs this kind of training wheels) is not gonna help.
This validation is very similar to the old automatic singlequote escaping in PHP. Something that was supposed to prevent SQL injection attacks on websites created by people that blindly interpolate stuff they receive from outside into ad-hoc SQL queries. The result is that the singlequotes are escaped all the time even when the data is used for other things. If you've spent any time on the web, you must have noticed sites that prepend a backslash to every singlequote and keep on prependin\\\\\' and prependin\\\\\'.
The validation is more dangerous though. Instead of adding a backslash somewhere (which looks silly, but most of the time doesn't hurt anything), this validation CRASHES the site. Instead of a "The price must be a number." the site just crashes on you. And that's still one of the better cases. The crash may easily be triggered by some ENCODED binary data in a hidden field! Something the user had never seen and never touched! And now try to debug that... and try to explain that to the users and to your boss.
Apart from attempting to fit a single validation onto everything there's another problem. You should never ever attempt to find the dangerous stuff, you should always make sure you only have the safe stuff! Whenever you try the first you run the risk of forgetting something. Yet another character special to the specific use of the data (null character, newline, singlequote, doublequote, less-than sign and lots and lots of others ... sometimes even a dot may be special), yet another sequence of characters that causes trouble IN THAT PARTICULAR CASE ...
Then, after validating the data (based on what is the set of allowed values of each separate value!) you need to make sure you either do escape the value (based on where do you insert it) or use an interface where you do not need to escape it. In which case having it automatically escaped is either cause of problems or a pain in the ass because you have to unescape the value again. And then possibly escape it correctly for the way you use them.
In either case HOW DO I TURN THIS ILL-DESIGNED PSEUDOVALIDATION OFF ONCE AND FOR EVER?
security asp.net mvc "ASP.NET MVC" [ValidateInput(false)] repopulate fields Exception "SQL injection" "Validation" .net mvc 2
http://jendaperl.blogspot.com