When Microsoft unveiled its IE 8’s “XSS filters”, almost one year ago, we could notice how, despite their impressive resemblance to NoScript’s anti-XSS protection, they were quite limited in comparison.

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.

Today I noticed via sla.ckers.org that such a DOM-based XSS attack is currently possible against Paypal and Ebay, no less, allowing the attacker to steal authentication info and other sensitive data, or even perform financial transactions on the behalf of the victim.

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?

  1. * Latest versions of Firefox, Safari, Opera and Chrome.
  2. ** 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.

16 Responses to “Paypal XSS, an IE Exclusive!”

  1. #1 GµårÐïåñ says:

    Thank you for the analysis, very informative. Once again, another reason to use NoScript.

  2. #2 Laurens Holst says:

    More FUD to scare us into using the adware NoScript?

  3. #3 Giorgio says:

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

  4. #4 Basti says:

    Thanks for information.

    @Gorgio:
    Please keep it low. Don’t start that war again.

  5. #5 Nilesh says:

    Hi Giorgio,

    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.

  6. #6 Lost in the Noise » Blog Archive » IE8 machteloos tegen lekke PayPal en eBay sites says:

    […] Volgens Maone is het lek in de website opmerkelijk, aangezien die alleen IE treft. “Alle moderne […]

  7. #7 Giorgio says:

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

    1. Input decoding (decodeURIComponent)
    2. Input validation
    3. 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.

  8. #8 Nilesh says:

    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

  9. #9 Bill says:

    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.

  10. #10 Giorgio says:

    @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

    1. Split it in a name-value pairs list -
      var pairs = location.search.split(”&”
    2. 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 :(

  11. #11 Nilesh Kumar says:

    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

  12. #12 Tom T. says:

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

  13. #13 Bob says:

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

  14. #14 Bob says:

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

  15. #15 Giorgio says:

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

  16. #16 Tom T. says:

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

Bad Behavior has blocked 7169 access attempts in the last 7 days.