One of the limitations was their ability to mitigate a subset of reflective (AKA type 1) XSS vulnerabilities only, leaving them totally useless against DOM-based (AKA type 0) XSS attacks which, instead, are effectively defeated by NoScript.

Even more interesting, modern browsers*except IE properly encode request URLs before sending them on the wire, but exploitation of this specific Paypal vulnerability requires the "double quotes" character to pass through with no encoding: therefore, while the vast majority of XSS exploits are cross-browser, this one affects exclusively IE**. Embrace and XSStend?

* Latest versions of Firefox, Safari, Opera and Chrome.

** Variants could affect any browser, since IE's encoding bug is generally not required for DOM-based XSS. Firefox users can protect themselves by using NoScript, even in the permissive and not recommended "Allow Scripts Globally" mode.

This entry was posted on Tuesday, May 19th, 2009 at 2:21 am and is filed under IE, XSS, Mozilla, Security, NoScript. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

@Laurens Holst:
Care to explain how exactly is this FUD?
Where's the Fear, where the Uncertainty and where the Doubt?

And how would exactly NoScript qualify as adware, since it doesn't display any advertising of its own and you can use it for free with no obligation to see any ad?
If you mean the release notes page, you may want to read FAQ 2.5, which has been always linked from the release notes page itself and explains how to quickly disable it.

Or you may choose to blindly believe in Wladimir Palant's propaganda...

Sorry..a bit off-topic , but i am confused a bit.
On entering into the search parameter of the search page the application is doing output encoding as it gives me back "%3cscript%3ealert('xss')%3c%2fscript%3e". Is there any chance to bypass output encoding so that the malicious script gets executed. This i am asking because sometimes we can find out the way the application is encoding and just by looking the encoding way used by the application we may find out which other script variation which may gets executed.

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.

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

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).

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? :-)

@#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?

@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).

@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.

@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?