Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Security > Why is "oN%3d" so dangerous?

Reply
Thread Tools

Why is "oN%3d" so dangerous?

 
 
Mike Kozlowski
Guest
Posts: n/a
 
      10-01-2004
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/

 
Reply With Quote
 
 
 
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      10-01-2004
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" <(E-Mail Removed)> wrote in message
news:cjjne3$7f5$(E-Mail Removed)...
> 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/
>



 
Reply With Quote
 
 
 
 
Nicole Calinoiu
Guest
Posts: n/a
 
      10-01-2004
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" <(E-Mail Removed)> wrote in message
news:cjjne3$7f5$(E-Mail Removed)...
> 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/
>



 
Reply With Quote
 
Mike Kozlowski
Guest
Posts: n/a
 
      10-01-2004
In article <(E-Mail Removed)>,
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/

 
Reply With Quote
 
Mike Kozlowski
Guest
Posts: n/a
 
      10-01-2004
In article <(E-Mail Removed)>,
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/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Cisco 2611 and Cisco 1721 : Why , why , why ????? sam@nospam.org Cisco 10 05-01-2005 08:49 AM
Why, why, why??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 6 01-27-2005 03:35 PM
Why Why Why You HAVE NO IDEA MCSE 31 04-24-2004 06:40 PM



Advertisments