Why is "oN%3d" so dangerous?

Discussion in 'ASP .Net Security' started by Mike Kozlowski, Oct 1, 2004.

  1. In an ASP.NET 1.1 application, I'm encrypting URL parameters. This
    has mostly been working great, but yesterday, one particular URL got
    caught by the XSS checker, giving me the "A potentially dangerous
    Request.QueryString value was detected from the client". Several
    questions arise from this:

    1. By reducing the querystring down as much as possible, I've found
    that the offending characters are "oN%3d" -- removing the o, the
    N, or the %3d, will all result in the string being okay; but
    leaving all of them together like that triggers the validator.
    Why? This is completely inexplicable to me.

    2. What on earth can I do to avoid this? I'm already URL-encoding
    (that %3d, obviously, was an '=' character), and HTML-encoding
    doesn't seem like it'd have any effect on that string. I'd really
    like to be able to pass random strings around without seemingly
    innocuous characters triggering hard-fail validations.

    Advice? Explanation?

    --
    Mike Kozlowski
    http://www.klio.org/mlk/
    Mike Kozlowski, Oct 1, 2004
    #1
    1. Advertising

  2. I've wondered about this too. It seems you can't put straight base64 text
    on a query string because it needs to be encoded. However, you sometimes
    run into funny encoding issues.

    One thing that I'm pretty sure you can do with impunity is hex-encode your
    binary encrypted data and then just put the hex string string on the query
    string. .NET doesn't seem to have helpful hex-encoding functions like the
    Base64 functions, but it isn't hard to write your own.

    Sorry I didn't answer your actual question. I have no idea on that part.

    Joe K.

    "Mike Kozlowski" <> wrote in message
    news:cjjne3$7f5$...
    > In an ASP.NET 1.1 application, I'm encrypting URL parameters. This
    > has mostly been working great, but yesterday, one particular URL got
    > caught by the XSS checker, giving me the "A potentially dangerous
    > Request.QueryString value was detected from the client". Several
    > questions arise from this:
    >
    > 1. By reducing the querystring down as much as possible, I've found
    > that the offending characters are "oN%3d" -- removing the o, the
    > N, or the %3d, will all result in the string being okay; but
    > leaving all of them together like that triggers the validator.
    > Why? This is completely inexplicable to me.
    >
    > 2. What on earth can I do to avoid this? I'm already URL-encoding
    > (that %3d, obviously, was an '=' character), and HTML-encoding
    > doesn't seem like it'd have any effect on that string. I'd really
    > like to be able to pass random strings around without seemingly
    > innocuous characters triggering hard-fail validations.
    >
    > Advice? Explanation?
    >
    > --
    > Mike Kozlowski
    > http://www.klio.org/mlk/
    >
    Joe Kaplan \(MVP - ADSI\), Oct 1, 2004
    #2
    1. Advertising

  3. Mike,

    It's being evaluated as a potential "onSomeEvent = doSomething()" script.
    One workaround would be to insert some non-whitespace character outside the
    a-z and A-Z ranges between the "on" (cas-insensitive) and the "=" or "%3d".

    If you're curious as to the exact details of why it fails validation, grab a
    copy of Reflector and take a look at the
    System.Web.CrossSiteScriptingValidation class. The entry point for query
    string validation is the IsDangerousString method.

    HTH,
    Nicole



    "Mike Kozlowski" <> wrote in message
    news:cjjne3$7f5$...
    > In an ASP.NET 1.1 application, I'm encrypting URL parameters. This
    > has mostly been working great, but yesterday, one particular URL got
    > caught by the XSS checker, giving me the "A potentially dangerous
    > Request.QueryString value was detected from the client". Several
    > questions arise from this:
    >
    > 1. By reducing the querystring down as much as possible, I've found
    > that the offending characters are "oN%3d" -- removing the o, the
    > N, or the %3d, will all result in the string being okay; but
    > leaving all of them together like that triggers the validator.
    > Why? This is completely inexplicable to me.
    >
    > 2. What on earth can I do to avoid this? I'm already URL-encoding
    > (that %3d, obviously, was an '=' character), and HTML-encoding
    > doesn't seem like it'd have any effect on that string. I'd really
    > like to be able to pass random strings around without seemingly
    > innocuous characters triggering hard-fail validations.
    >
    > Advice? Explanation?
    >
    > --
    > Mike Kozlowski
    > http://www.klio.org/mlk/
    >
    Nicole Calinoiu, Oct 1, 2004
    #3
  4. In article <>,
    Nicole Calinoiu <ngcalinoiu REMOVETHIS AT gmail DOT com> wrote:

    >It's being evaluated as a potential "onSomeEvent = doSomething()" script.
    >One workaround would be to insert some non-whitespace character outside the
    >a-z and A-Z ranges between the "on" (cas-insensitive) and the "=" or "%3d".


    Thank you for the explanation. For now, I'm working around that
    particular catch by just double URL encoding the string, which makes
    "on=" appear to be "on%3d", which ASP.NET fails to complain about.
    I'm worried that this is just catching one symptom of the root
    problem, though, so...

    >If you're curious as to the exact details of why it fails validation, grab a
    >copy of Reflector and take a look at the
    >System.Web.CrossSiteScriptingValidation class. The entry point for query
    >string validation is the IsDangerousString method.


    .... that's helpful. Thanks!

    --
    Mike Kozlowski
    http://www.klio.org/mlk/
    Mike Kozlowski, Oct 1, 2004
    #4
  5. In article <>,
    Nicole Calinoiu <ngcalinoiu REMOVETHIS AT gmail DOT com> wrote:

    >If you're curious as to the exact details of why it fails validation, grab a
    >copy of Reflector and take a look at the
    >System.Web.CrossSiteScriptingValidation class. The entry point for query
    >string validation is the IsDangerousString method.


    For easy reference for some future person looking at this thread
    because they're having the same problem, the XSS validator blocks any
    string matching (in effect) the following regexes:

    script\s*=
    [^a-zA-Z]on[a-zA-Z]*\s*=
    expression
    &#
    <[a-zA-Z!]

    The last two are impossible with Base64 encoding (which only allows
    letters, digits, +, /, and =), the first two are impossible if you
    just do UrlEncode twice in a row (to prevent equal signs from
    occuring), and the third is vanishingly unlikely in random characters,
    but if you're concerned about it, you can just replace all "x"
    characters with "," after the Base64 encoding.

    --
    Mike Kozlowski
    http://www.klio.org/mlk/
    Mike Kozlowski, Oct 1, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anil Kripalani
    Replies:
    2
    Views:
    482
    Eric Lawrence [MSFT]
    Feb 25, 2004
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    875
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,804
    Smokey Grindel
    Dec 2, 2006
  4. jayapal

    why the usage of gets() is dangerous.

    jayapal, Nov 16, 2007, in forum: C Programming
    Replies:
    123
    Views:
    1,973
    CBFalconer
    Nov 28, 2007
  5. Julian

    Why is it dangerous?

    Julian, Aug 10, 2008, in forum: C Programming
    Replies:
    184
    Views:
    3,549
    Ron Ford
    Aug 27, 2008
Loading...

Share This Page