Re: Pen-tester's analysis of .NET security?

[dd <dd () ghettohackers net>]

Input filtering doesn't work, only output escaping works.  There are any 
number of "meta" characters that could be harmfully depending on were 
they are outputted.  Even if this "bug" did not exist, the ASP.NET 
filtering would still be broken since it is based off a blacklist style 
approach.  Not to mention it doesn't come close to fixing injections 
that occur in SQL, Javascript, VBScript, XML/XSL, etc.

The proper solution for handling input in web applications tends to be 
two pronged, on one side you must perform proper input validation.  On 
the second one must perform output escaping with knowledge of output 
context.

Input validation should by based on a white list system that includes 
length, and format.  It should be noted that "bad" chars such as < > & % 
;, etc can be acceptable input.  Input validation should also never 
attempt to "fix" the input.  Any "bad" input should stop the page 
execution.  "Bad" input should also mean any unexpected additional 
inputs (an extra post/querystring field).  My recommendations are to 
build an input validation framework in which base Page classes are 
extended to include validation.  (NOTE: Proper input validation and 
logging is *very* close to an application intrusion detection system)

Output escaping is simple to add into ASP.NET by extending HtmlControls 
and WebControls to add "automatic" escaping on render.  In addition, to 
provide flexibility in the application the controls should have a method 
such that the developer can bypass the encoding if (say) HTML is 
required to be displayed.  For output that is occurring in written code 
(via Response.Write, <%= %>, etc) developers and testers must be trained 
to understand the idea of context and proper output encoding.

Lastly, a quick note on proper escaping of output.  I never recommend 
the use of built in HTML encoding functions as they only encode 4 
characters ( < > & " ) which I feel is not enough to properly protect a 
system from future vulnerabilities.  I recommend building a library that 
encodes pretty much anything non A-Za-z0-9 SPACE.  This includes all 
unicode characters.

dd

Frank Knobbe wrote:

> On Fri, 2004-03-26 at 02:29, Dominick Baier wrote:
>
> > however there is a bug in asp.net 1.1 with null characters :
> >
> > won't work
> > http://foo.bar/search.aspx?term=<SCRIPT>alert('Vulnerable')</SCRIPT>
> >
> > will work
> > http://foo.bar/search.aspx?term=<%00SCRIPT>alert('Vulnerable')</SCRIPT>
>
>
>
> What did I say earlier about not trusting the OS? Perfect example here.
> You can't trust anybody but your own code :)
>
> Any idea why Microsoft is filtering for "<SCRIPT>" specifically and not
> just "<" and ">"?
>
> Regards,
> Frank


---------------------------------------------------------------------------
You're a pen tester, but is google.com still your R&D team?
Now you can get trustworthy commercial-grade exploits and the latest
techniques from a world-class research group.
www.coresecurity.com/promos/sf_ept1
----------------------------------------------------------------------------