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

From: dd (dd_at_ghettohackers.net)
Date: 03/27/04

  • Next message: Don Parker: "Re: nmap shows open UDP port 113" 
    Date: Fri, 26 Mar 2004 16:04:09 -0800
To: Frank Knobbe <frank@knobbe.us>

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

  • Next message: Don Parker: "Re: nmap shows open UDP port 113"