From: dd (dd@ghettohackers.net)
Date: Fri Mar 26 2004 - 19:04:09 EST
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=
>>
>>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
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:51 EDT