Re: Error

From: Victor Garcia Aprea [MVP] (vga@NOobiesSPAM.com)
Date: 04/23/03


From: "Victor Garcia Aprea [MVP]" <vga@NOobiesSPAM.com>
Date: Tue, 22 Apr 2003 20:44:04 -0300


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" <jeff@kavera.com> wrote in message
news:010a01c308f8$28572fe0$a401280a@phx.gbl...
> 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.
>
>
> >-----Original Message-----
> >> 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
> >Microsoft MVP | ASP.NET
> >
> >>
> >> >-----Original Message-----
> >> >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" <abc@newsgroup.com> wrote in message
> >> >news:O9DUCetADHA.3208@TK2MSFTNGP11.phx.gbl...
> >> >> 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]" <vga@NOobiesSPAM.com>
> wrote
> >> in message
> >> >> news:egPpZJtADHA.33548@TK2MSFTNGP10.phx.gbl...
> >> >> > 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" <abc@newsgroup.com> wrote in message
> >> >> > news:#1dSuDtADHA.3144@TK2MSFTNGP11.phx.gbl...
> >> >> > > 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.HttpApplica
> >> tion+IExecutionSte
> >> >> > > p.Execute()
> >> >> > >    at System.Web.HttpApplication.ExecuteStep
> >> (IExecutionStep step,
> >> >> Boolean&
> >> >> > > completedSynchronously)"
> >> >> > >     TargetSite:
> >> {System.Reflection.RuntimeMethodInfo}
> >> >> > >
> >> >> > > thanks
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >> >.
> >> >
> >
> >
> >.
> >


Relevant Pages

  • Access 2007 unable to digitally sign accdb files
    ... Access 2007 has removed digital signing feature for accdb and accde files. ... the only way to silence Microsoft's security nagging is asking every user to go through a 5-step procedure to set up a trusted location, and then store the accdb file there. ... Microsoft's security message mess once and for all. ...
    (microsoft.public.access.security)
  • Re: Error
    ... In ASP.NET 1.0 there was not built-in feature to do ... >> risking the security of your customers websites. ... >> RequestValidate ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Error
    ... for example I added this feature to our custom web app framework. ... > any application will have stronger security settings right out of the box. ... > risking the security of your customers websites. ... > RequestValidate ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Bypassing SMTP Content Protection with a Flick of a Button
    ... How about using Outlook Express as ... more than an Outlook Express client and employs a rarely-used feature ... This RFC documented feature called "Message Fragmentation and ... comprehensive security policy to restrict potentially harmful content ...
    (Bugtraq)
  • [VulnWatch] Bypassing SMTP Content Protection with a Flick of a Button
    ... How about using Outlook Express as ... more than an Outlook Express client and employs a rarely-used feature ... This RFC documented feature called "Message Fragmentation and ... comprehensive security policy to restrict potentially harmful content ...
    (VulnWatch)