Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Error

4 views
Skip to first unread message

Ashok

unread,
Apr 14, 2003, 6:00:13 PM4/14/03
to
I get following error on server when i am trying to write file to request
stream from client. Please help

{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

Victor Garcia Aprea [MVP]

unread,
Apr 14, 2003, 6:08:48 PM4/14/03
to
Hi Askhok,

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...

Ashok

unread,
Apr 14, 2003, 6:47:19 PM4/14/03
to
Thanks for your reply. Can you please explain more on this.
Client request (vb app) had a POST with query string parameters and was
working with .Net framework 1.0.
Stopped working when i upgraded to 1.1.

"Victor Garcia Aprea [MVP]" <v...@NOobiesSPAM.com> wrote in message
news:egPpZJtA...@TK2MSFTNGP10.phx.gbl...

Victor Garcia Aprea [MVP]

unread,
Apr 14, 2003, 6:56:25 PM4/14/03
to
Its a new feature in ASP.NET v1.1, targeted to prevent cross-site scripting
attacks. Its enabled by default and thats why your site stopped working.
Basically what it does is to examine the Forms, QueryString and Cookies
collection for content considered dangerous (ie. <script> tags, etc), if any
of these collections contain an item with "dangerous" data, an exception is
thrown and the request is aborted. It seems like the data you're posting
contains content considered "dangerous" by ASP.NET and that is why its
aborting the request.

--
Victor Garcia Aprea
Microsoft MVP | ASP.NET

"Ashok" <a...@newsgroup.com> wrote in message

news:O9DUCetA...@TK2MSFTNGP11.phx.gbl...

Ashok

unread,
Apr 14, 2003, 7:09:29 PM4/14/03
to
thanks.

"Victor Garcia Aprea [MVP]" <v...@NOobiesSPAM.com> wrote in message

news:OWJCAktA...@TK2MSFTNGP10.phx.gbl...

Jeff

unread,
Apr 21, 2003, 5:25:08 PM4/21/03
to
This is a feature? 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?

Talk about overkill. How about try again for a better
answer? Like how do we edit the list of things it should
check?

>.
>

Jeff

unread,
Apr 21, 2003, 6:00:53 PM4/21/03
to
Well we found our better answer, we have dot.net 1.0 on
our CD and our customers have just been sent a notice to
not upgrade to Microsofts latest due to security concerns.

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.

>.
>

Victor Garcia Aprea [MVP]

unread,
Apr 21, 2003, 6:11:14 PM4/21/03
to
> This is a feature?
Sure it is.

> 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.

Victor Garcia Aprea [MVP]

unread,
Apr 21, 2003, 6:13:15 PM4/21/03
to
>>>> We will just distribute 1.0 for the time being since we
>>>> cannot just change a ton of code

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...

Jeff

unread,
Apr 22, 2003, 1:54:01 PM4/22/03
to
A one line is not too hard.. sure and is this the same one
line you were talking about here:

"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.

>.
>

Victor Garcia Aprea [MVP]

unread,
Apr 22, 2003, 7:44:04 PM4/22/03
to
Hi Jeff,

>>>> "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 Ramirez

unread,
Apr 28, 2003, 5:48:39 PM4/28/03
to
I think answering this would help us all... Is there any way to set
validateRequest="false" and have the same code compile in ASP.NET 1.0
and ASP.NET 1.1? ASP.NET 1.0 chokes on it whether validateRequest is
in the .aspx page or in Web.config... Is there a way to check the
version of .NET that is running and dynamically output
validateRequest="false" if ASP.NET 1.1 is running? Thanks.

-Andres


"Victor Garcia Aprea [MVP]" <v...@NOobiesSPAM.com> wrote in message news:<e1lbLkSC...@TK2MSFTNGP12.phx.gbl>...

Victor Garcia Aprea [MVP]

unread,
May 2, 2003, 12:18:30 AM5/2/03
to
Jeff,

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...

Victor Garcia Aprea [MVP]

unread,
May 2, 2003, 12:27:09 AM5/2/03
to
Hi Andres,

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...

0 new messages