What is this?

[eradic8]

Questionable Unicode to ASCII homographic conversions performed by Microsoft's "Classic" ASP - from recent development history seen as below.


+ [XSS] Work-around for questionable Unicode to ASCII homographic
conversions performed by Microsoft's "Classic" ASP
x Tighter UI synchronization callbacks

[Giorgio Maone]

"Classic" ASP (i.e. the old, VBScript-based one before ASP.NET) does a pretty stupid (translation of "questionable") thing: every high unicode code point (i.e. >0x7f), if found in request parameters escaped using the old and deprecated %u0123 notation, gets automatically translated to an ASCII character: if there's one which vaguely resembles the original visually, e.g. "<" (ASCII 0x3C) for "〈" (Unicode 0x2329) or "e" (ASCII 0x65) for "ℯ" (Unicode 0x212F), then it gets used, otherwise either the "standard" replacement character ("�", Unicode 0xfffe), or more commonly the question mark ("?", ASCII 0x3F) is picked, apparently in an arbitrary way.

Needless to say, this behavior can mess with any filter, including NoScript's (before the work around) and Chrome's, but IE's is immune (probably because IIRC Internet Explorer itself used to perform this kind of transformation on the client side as well, or just because someone from the IIS dept. told the IE security guys "look at this cool stuff we do to protect IIS from those ugly Chinese characters!").

For instance, on IIS 5 or below ("Classic" ASP is disabled by default in most recent IIS version because, guess what?, it's a security nightmare) the following query string:

Code: Select all

%u2329scr%u0131pt%u232A%u212fval(%27al%u212Frt(%22XSS%22)%27)%u2329/scr%u0131pt%u232A

translates to

Code: Select all

<script>eval('alert("XSS")')</script>

which, if echoed back, is executed as a JavaScript block by the browser.

Any "sane" web server (either a recent IIS or Apache or Lighttpd or you name which) would either leave the %u0123 stuff alone (because this escaping style is deprecated) or would translate the whole into a pitoresque

Code: Select all

〈scrıpt〉ℯval('alℯrt("XSSi")')〈/scrıpt〉

which obviously has no meaning to any decent browser.

Either way, recent NoScript versions cope with this nicely, even though it costed me some hours of swearing and about 3KB more in the compressed XPI: look at the ASPIdiocy.js file in the content directory (autogenerated by a test ASP script I created ad-hoc) to see what I mean.

[dhouwn]

but IE's is immune (probably because IIRC Internet Explorer itself used to perform this kind of transformation on the client side as well, or just because someone from the IIS dept. told the IE security guys "look at this cool stuff we do to protect IIS from those ugly Chinese characters!").

I believe some security researcher reverse-engineered IE's XSS filter, maybe you could take a look at it and see if you haven't overlooked any of ASP's character replacement 'features'.

[eradic8]

O.K Giorgio thanks, I think I kind of understood your explanation with my limited technical knowledge, but just to make it clear am I alright to be using NoScript version 2.0.1 or should I use development version 2.0.2rc5 ?

[Giorgio Maone]

I believe some security researcher reverse-engineered IE's XSS filter, maybe you could take a look at it and see if you haven't overlooked any of ASP's character replacement 'features'.

One of them is a friend of mine (Sirdarckcat), but nobody figured out this from a reverse engineering just because nobody fantasized about the existence of this (undocumented) feature so far.
Anyway the script I wrote to test the ASP transformations for all the unicode spectrum is more exhaustive, direct and conclusive than any reverse-engineering on a 3rd party filter.

@eradic8:
"Classic" ASP website are luckily becoming a rarity, at least among valuable XSS targets (e.g. banking sites), so you should be relatively safe even on the stable version, but if you want always to get the latest and greatest protection level you may want to join the beta channel.
At any rate, 2.0.2 final should be available not later than next Monday.

[eradic8]

@eradic8:
"Classic" ASP website are luckily becoming a rarity, at least among valuable XSS targets (e.g. banking sites), so you should be relatively safe even on the stable version, but if you want always to get the latest and greatest protection level you may want to join the beta channel.
At any rate, 2.0.2 final should be available not later than next Monday.

Many thanks.