Comments on: Paypal XSS, an IE Exclusive!

By: Tom T.

Tom T. — Mon, 15 Jun 2009 03:37:12 +0000

@Bob: Even if true, how does that refute what I said about whether popularity is the best criterion of quality? Every MS OS comes with IE OOB, and most Average Users (and corp IT, who is not always so knowledgeable and has a tendency to avoid change and extra work) plug it in, click the little "e", and that’s it. How does that prove it’s "better"? Most of the AvgUserSpace doesn’t even know that other browsers exist, or of the security issues.

And how have you and Bill in any way refuted the OP, about the specific vuln in IE and the general vuln in all browsers other than a NS-protected Fx?

By: Giorgio

Giorgio — Tue, 09 Jun 2009 10:51:56 +0000

@Bob:
I don’t believe Lauren’s statement was so subtle, and even if it was he wouldn’t be less wrong.

He (and you, apparently) failed to notice that browsers different than IE8 being immune from this specific instance of DOM-based XSS is just an accident, ironically due to a further bug in the Paypal code (missing URL decoding).

The vast majority of DOM-based XSS attacks succeed equally well on IE and any other browser, except those protected by NoScript. That’s what GµårÐïåñ was trying to say, I suspect.

By: Bob

Bob — Sun, 07 Jun 2009 13:39:52 +0000

@Giorgio - I suspect Laurens was referring to comment #1 more than the post itself. "Hey, some software has a flaw in it - best use our product to ensure that this other software which isn’t vulnerable anyway is protected."

@Tom - The link you have provided explicitly states their selection bias (i.e. extracted from their own log files, acknowledging the nature of their content), and also has this to say: "You cannot - as a web developer - rely only on statistics. Statistics can often be misleading." Their statistics show a general increase in Firefox usage, and a marked increase among Web developers - which is unsurprising given the range of functionality in Firefox and extensions that is missing from freely-available IE addons. My own experience would suggest 80% IE is closer to the mark, and a surprising number of corporate projects still need to support IE6 (complete with broken box model).

By: Bob

Bob — Sun, 07 Jun 2009 13:22:31 +0000

@#1 - I’m confused. This exploit appears to be specific to IE8 because of the slightly-broken way it deals with URL encoding and decoding. How exactly can an IE-specific vulnerability be justification for using a particular Firefox extension?

By: Tom T.

Tom T. — Sat, 23 May 2009 05:35:41 +0000

# #9 Bill says:
May 21st, 2009 at 10:46 am

IE8 is the best browser in the world. No amount of FUD will stop me or the millions of other users from using the most popular browser on earth.
********
@ Bill: Then why are you here?

Is popularity always the best criterion of quality? Are the most popular politicians, celebrities, automobiles, etc. always the best?

And for the record, at least one source, [url]http://www.w3schools.com/browsers/browsers_stats.asp[/url], shows that for April 2009, Fx surpassed all versions of IE combined by a full five percentage points, which translates into almost 12% more users of Fx than of IE.

Of course, you’re perfectly free to continue using IE. Good luck with that. … btw, your last name wouldn’t happen to be "Gates", would it? :-)

By: Nilesh Kumar

Nilesh Kumar — Fri, 22 May 2009 06:42:08 +0000

Hi Giorgio,

Thanks a lot, now things are clearer.

Can you elaborate a bit on the point:

>> IS there any way to bypass this URL-encoding and execute XSS?

No (except in IE), unless the injection point is not quoted, because quotes in an URL are usually escaped by the browser (except in IE).

Regards,
Nilesh

By: Giorgio

Giorgio — Thu, 21 May 2009 10:21:24 +0000

@Nilesh:

What is Input Decoding? Is it same as URLEncoding?

DOM-based XSS assumes the application processes and writes out some user input on the client side. If the input is a normal name-value pairs query string, the application script needs to

Split it in a name-value pairs list -
var pairs = location.search.split(”&”
Split each pair into name and value -
var params = {}; for each(var pair in pairs) { pair = p.split(”=”).map(decodeURIComponent); params[pair[0]] = params[pair[1]] };

At this point you’ve got a params hash map with all the query string parameters properly decoded with

decodeURIComponent()


 (url decoding).
The applications you see spitting out %22 are probably skipping the url decoding part, which is generally incorrect (especially if they actually expect special characters from the input) but incidentally makes XSS injections more difficult.
To correctly keep the decoding and being yet protected against XSS injection, you need to perform an extra encoding step when outputting the data, either

Using the DOM, like
document.getElementById(”container”)

 .appendChild(document.createTextNode(params.someParam);

XML-escaping before writing (less recommended), like
function xmlEscape(s) {

  return s.replace(/[<>"'&]/g, function(s) { return “&#” + s.charCodeAt(0) + “;”; });

}

document.write(xmlEscape(params.someParam));


IE doesn’t encode the URL?

No it doesn’t. Therefore an application which doesn’t encode its output is not protected even if it doesn’t decode the input.

You should always encode the output, and decode the input if it makes sense (almost always).

IS there any way to bypass this URL-encoding and execute XSS?

No (except in IE), unless the injection point is not quoted, because quotes in an URL are usually escaped by the browser (except in IE).
When should we enter any script in encoded form to execute the XSS??
Sorry, I’m afraid I don’t understand this question :(

By: Bill

Bill — Thu, 21 May 2009 08:46:56 +0000

IE8 is the best browser in the world. No amount of FUD will stop me or the millions of other users from using the most popular browser on earth.

By: Nilesh

Nilesh — Thu, 21 May 2009 05:49:42 +0000

Dear Giorgio,
First of all really thanks for your quick answer.You are so humble. I appreciate this.

Regarding your reply I have few questions again:

>>You’re talking about a different application, right?
>>In the Paypal case, it’s not doing output encoding, it’s skipping >>input decoding (quite strangely)

I am talking about any general application I find that entering scripts in original form it gives back URL encoded form as output of the script.
What is Input Decoding? Is it same as URLEncoding?

>>only by luck the fact browsers different by IE properly encode the >>URL saves them from XSS

IE doesn’t encode the URL?

>>So is your application actually url-encoding its output (which is >>wrong, since it should HTML-encode instead)

IS there any way to bypass this URL-encoding and execute XSS?

And last but not least:

When should we enter any script in encoded form to execute the XSS??

Thanks,
Nilesh
nileshkumar83.blogspot.com

By: Giorgio

Giorgio — Wed, 20 May 2009 14:49:36 +0000

@Nilesh: You're talking about a different application, right? In the Paypal case, it's not doing output encoding, it's skipping input decoding (quite strangely). The correct workflow should be:

Input decoding (decodeURIComponent)
Input validation
Output with output-specific (HTML or JavaScript) encoding

This Paypal page was missing all the 3, and only by luck the fact browsers different by IE properly encode the URL saves them from XSS. So is your application actually url-encoding its output (which is wrong, since it should HTML-encode instead), or is it just omitting to decode its input like Paypal? In the latter case, it would be as exploitable as Paypal against IE users.