{System.Web.HttpRequestValidationException}
[System.Web.HttpRequestValidationException]:
{System.Web.HttpRequestValidationException}
HelpLink: Nothing
InnerException: Nothing
Message: "A potentially dangerous Request.Form value was detected from
the client (?<?xml version="...="yes"?>
<myroot>)."
Source: "System.Web"
StackTrace: " at System.Web.HttpRequest.ValidateString(String s,
String valueName, String collectionName)
at System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection
nvc, String collectionName)
at System.Web.HttpRequest.get_Form()
at System.Web.UI.Page.GetCollectionBasedOnMethod()
at System.Web.UI.Page.DeterminePostBackMode()
at System.Web.UI.Page.ProcessRequestMain()
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication+IExecutionSte
p.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&
completedSynchronously)"
TargetSite: {System.Reflection.RuntimeMethodInfo}
thanks
You can disable this at the Page level by setting the RequestValidate
attribute of the Page directive to false, ie:
<% @Page RequestValidate="false" %>
or at the application level by setting the RequestValidate attribute of the
pages element to false, ie:
<pages ValidateRequest="false">
You should double check the decision of disabling this as its usually not a
good idea,
--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
"Ashok" <a...@newsgroup.com> wrote in message
news:#1dSuDtA...@TK2MSFTNGP11.phx.gbl...
"Victor Garcia Aprea [MVP]" <v...@NOobiesSPAM.com> wrote in message
news:egPpZJtA...@TK2MSFTNGP10.phx.gbl...
--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
"Ashok" <a...@newsgroup.com> wrote in message
news:O9DUCetA...@TK2MSFTNGP11.phx.gbl...
"Victor Garcia Aprea [MVP]" <v...@NOobiesSPAM.com> wrote in message
news:OWJCAktA...@TK2MSFTNGP10.phx.gbl...
Talk about overkill. How about try again for a better
answer? Like how do we edit the list of things it should
check?
>.
>
We will just distribute 1.0 for the time being since we
cannot just change a ton of code and have a release on no
notice when MS decides to make these sorts of changes.
So much for compatibility, went thru the same thing with
MFC 1.0, should have known it was coming.
>.
>
> In our case we are storing a one
> element xml chunk in a control and we are supposed to
> disable a whole security level to do it?
You're suppose to add a one line entry to your config file if you want to
disable this feature, I dont think this is too hard.
> Talk about overkill.
I don't see anything overkill here.
> How about try again for a better
> answer? Like how do we edit the list of things it should
> check?
There is no list to edit. I could paste the docs here but I dont see much
sense in doing so. You could take a look at ASP.NET 1.1 docs to find out how
this feature works, its really pretty simple.
You don't need to touch your existing code. Take a look at the previous
threads where I noted how to disable this feature.
--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
"Jeff" <je...@kavera.com> wrote in message
news:05f101c30851$7a833c20$2f01...@phx.gbl...
"You should double check the decision of disabling this as
its usually not a good idea"
I am not trying to dog you but what I am hearing is:
1. This is an important security feature that should not
be disabled.
2. "It is no big deal, just one line to change in config
and you can run 1.1"
We are an established software company with real customers
and real products, the decision to disable any security
feature is a major decsion. We need to know exactly what
we face. It seems to me this is here for a reason, and
turning it off leaves our customers vulnerable to attack.
Yet leaving it on forces us to rewrite code that is
harmless just because this feature seems to be too broad
in what it filters and needs to be fixed.
So the bottom line is:
1. Risk customer attack (never)
2. Stay on 1.0
3. Rewrite tons of code.
I regret my choice for .NET now, this was not going to be
a MS effort and I pushed .NET. When the UNIX folks get
wind of this they will laugh and say "Ya dot.net only runs
if you turn off all the security". What a mistake.
>.
>
>>>> "You should double check the decision of disabling this as
>>>> its usually not a good idea"
This is really important and I think you're mixing things a bit, let me try
to explain it:
Security rule #1: Check your inputs. Any application (web or not) should
check its inputs. In ASP.NET 1.0 there was not built-in feature to do this,
which meant you had to code it for yourself for any real web application
deployed, for example I added this feature to our custom web app framework.
Then came ASP.NET 1.1 with this built-in feature (turned on by default) so
any application will have stronger security settings right out of the box.
In our case we're not currently using it because we've already coded a
similar one. If you were not watching for this in 1.0 then you were actually
risking the security of your customers websites. ASP.NET 1.1 is just trying
to make people aware of this issue and providing a built-in feature to help
in its implementation.
>>> the decision to disable any security feature is a major decsion.
Sure it is. Its very important that you understand what this feature is
about: checking the content posted in forms, querystring and cookies
collection. This content should always be checked against, in 1.0 bits you
had no choice, the checking had to be performed by you; now in 1.1 bits you
may want to let ASP.NET do the checkings for you (of course you can still
use our own checking).
>>> So the bottom line is:
>>> 1. Risk customer attack (never)
You're already risking it if you haven't coded such a feature in ASP.NET
1.0. If you're already protecting yourself from dangerous content then you
may not need the 1.1 feature.
>>> 2. Stay on 1.0
In 1.0, without any additional code from your part for preventing dangerous
content from being posted you may be already risking the security of your
customer website.
>>> 3. Rewrite tons of code.
I don't see any reason for a rewrite here.
>>> "Ya dot.net only runs if you turn off all the security".
This is totally wrong, and whoever says this is not getting how this works.
--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
"Jeff" <je...@kavera.com> wrote in message
news:010a01c308f8$28572fe0$a401...@phx.gbl...
-Andres
"Victor Garcia Aprea [MVP]" <v...@NOobiesSPAM.com> wrote in message news:<e1lbLkSC...@TK2MSFTNGP12.phx.gbl>...
I've just added an entry to my blog describing how this feature works
internally. Maybe this help you to get a better idea of how this works,
please take a look at http://dotnetweblogs.com/vga/
--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
"Jeff" <je...@kavera.com> wrote in message
news:010a01c308f8$28572fe0$a401...@phx.gbl...
You could do something like that by checking the running version and then
calling the HttpRequest.ValidateInput before accessing the collections. You
will need to get a grasp on "reflection" to make this work.
I've just added an entry to my blog describing how the RequestValidation
feature works internally. If you want to learn more about it, please take a
look at http://dotnetweblogs.com/vga/
--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
"Andres Ramirez" <andr...@yahoo.com> wrote in message
news:f60bd3fe.03042...@posting.google.com...