Why is "oN%3d" so dangerous?

[Mike Kozlowski]

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
[url]http://www.klio.org/mlk/[/url]

[Joe Kaplan \(MVP - ADSI\)]

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" <mlk@klio.org> wrote in message
news:cjjne3$7f5$1@reader1.panix.com...

> 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
> [url]http://www.klio.org/mlk/[/url]
>

[Nicole Calinoiu]

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" <mlk@klio.org> wrote in message
news:cjjne3$7f5$1@reader1.panix.com...

> 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
> [url]http://www.klio.org/mlk/[/url]
>

[Mike Kozlowski]

In article <uexrmD9pEHA.3896@TK2MSFTNGP15.phx.gbl>,
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
[url]http://www.klio.org/mlk/[/url]

[Mike Kozlowski]

In article <uexrmD9pEHA.3896@TK2MSFTNGP15.phx.gbl>,
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
[url]http://www.klio.org/mlk/[/url]