eBay versus security policy consistency

Almost a year ago, we noticed that uploading images with the "basic" uploader while creating an auction on eBay doesn't work. It appears to just hang, but the error console reveals that it fails with a security exception.

The upload itself happens in a popup window where document.domain has been set, but only to the host name of the server – basically doing document.domain=document.domain. While this looks like a no-op, it actually changes the security origin from "all pages sent from cgi5.ebay.com" to "all pages that set their document.domain to cgi5.ebay.com". The opener page does not set document.domain but comes from the same server. Opera would traditionally consider them same origin and let the popup and opener communicate. However, in March 2008 we noticed a comment in WebKit's source code claiming this is a security hole in Opera – while I don't entirely agree with that we nevertheless aligned our security policy with the others. And thus we broke eBay's image upload!

After looking at the eBay issue last autumn and noticing the nasty and confusing browser-sniffing in the code that sets document.domain, we decided it was probably eBay's fault and left it with the Open The Web/Developer Relations team as OTW-5637, where it's been in limbo for months after initial attempts at getting through to the right people – no small task with a site and company as large as eBay. I asked in the bug why it works in other browsers, but the browser sniffing appeared to be sufficient explanation so back then I didn't continue the analysis.

Yesterday, the question came up again, and I tested with Chrome and Firefox. (As an aside, both have the annoying habit of making the address field of the popup read-only if the script wants – Opera ignores this user-unfriendly command.. So before testing the upload popup I used a simple bookmarklet

javascript:var window_open=window.open;void(window.open=function(url, name){window_open.call(window, url, name);});

to make sure the address bar would be editable.)

With the popup open, trying simple bookmarklets like

javascript:alert(opener.document)

quickly revealed that all browsers consider the popup and the opener different origins. Yet other browsers allowed the callback that modified the DOM in the opener to show the uploaded image!?

eBay relies on an inconsistency in the security policy of other browsers:

The code in the popup will try to pass the URL to the opener to show the image thumbnail in the page, then close the popup. To do so it calls methods in the opener. It has access to these methods because it stored a pointer to them before document.domain was set – so it was allowed to reference them.

In Opera, when the callback tries to modify the DOM and show the image, a security check in the DOM kicks in. This is why the script stops with a security error – Opera is the only browser that notices that the running script has a different origin than the document whose elements we're manipulating. This test shows the different behaviour.

Chrome and Firefox happen to not do a security check in the relevant DOM code. They do treat the popup and the opener as being from different origins, but their security policy has a convenient inconsistency that allows this callback.

So, the state of this issue:

  • Opera enforces the same-origin security policy in code points in the DOM where other browsers apparently do not
  • eBay's code requests really inconsistent security behaviour from browsers – wanting random pages to be different origin and relying on apparent bugs in browser security policies
  • Other browsers' implementations appear to be safe enough against actual exploits, though confusing and inconsistent

Changing security policy implicitly by removing some of our same-origin checks is a risky fix :yikes: . I can't think of a way to exploit what the other browsers are doing, but we'd certainly prefer staying consistent.. I'll probably look at a site-specific browser.js patch first, to make eBay work while we think about it.

Reader opinions welcome – who has the best suggestion for how we should resolve this conundrum?

18 thoughts on “eBay versus security policy consistency

  1. I would contact the other browser vendors and confront them with the problem. If they agree on fixing this security issue (not fixing it would be bad marketing…) then ebay have to act.Sure, other pages can get broken in all other browsers (except Opera) too. But if they are broken in all browsers, site admins have to do something.Maybe this issue can be discussed also on larger tech websites, to get some attention on the problem and the possible unsecure pages out there.But what I still dont understand is why webkit browsers too seem to do not work like they claim how to be correct/secure.

  2. Menno writes:The solution seems obvious: get eBay to fix things by having them set document.domain in the opener page as well.To get them to do that, open a couple of bug reports for Firefox and Chrome, so that the upload will break for them the way it is broken in Opera. EBay is sure to fix it if 40% percent of people are having the problem, rather than just the current 2% (?).Menno

  3. Originally posted by dbloom:

    how do other browsers behave when you get window references using window.open?

    Off the top of my head, I'd say the second statement should create a new popup and not reference the old one precisely because it's from a different origin than the first one. If you start setting document.domain (man, how I hate that JS misfeature!) that should change.If we don't behave that way, give me a bug :-p

  4. Originally posted by anonymous:

    get eBay to fix things by having them set document.domain in the opener page as well

    It would be my preferred solution too – though I will note that it isn't as easy as it sounds, because they will need to make sure it's set consistently and at the right time across all pages that need to interact. For example, just adding a statement that sets it in the main "create an auction" page breaks photo upload when the popup tries to store references to the callback function before it has set document.domain.. They would probably need to fix numerous similar issues.

  5. File bug reports w/ Google & Mozila 😉 (what prevents hackers from abusing this to send users malware and other stuff)Maybe Google will pay Opera 😀

  6. Originally posted by OmegaJunior:

    Hire a hacker to develop a successful XSS exploit.

    It depends on if there are any bugs in the site or the browser

  7. Robert Carnegie rja.carnegie@excite.com writes:Yes, excuse me: you can't think of a way to exploit what the other browsers are doing, but is exploitation your area of expertise?As a programmer myself, I find it is rather easy to write programs that go wrong when the user presses the wrong key or inputs the wrong data, because you tend to assume that if you do your job properly, they'll do theirs properly too.

  8. Anonymous writes:I'd suggest:First and most important: Repair stupid ebay by browser.jsMost user don't care why ebay don't work but think it's Operas fault.Second: Inform other browser producer & ebayThird: Inform some security experts like secunia, VUPEN, …Fourth: Wait until someone exploit the security holes in ff, chrome etc.

  9. Originally posted by anonymous:

    excuse me: you can't think of a way to exploit what the other browsers are doing, but is exploitation your area of expertise?

    Yes and no – I have experience in trying to find security exploits and have identified several in Opera and other web browsers. That doesn't mean I can think of all possible angles, of course 🙂

  10. Anonymous writes:This seems like flow for image upload on ebay selling page:Main page on ebay is: cgi5.ebay.comPopup opens on cgi5.ebay.comImage inside popups are sent to msa1.cgi5.ebay.com inside an ifarme in popup. For the iframe response to communicate back to popup, domain are downgraded to ebay.com in popup and iframe as well, so iframe can pass information back to popup window.After all the images are uploaded popup window passes thumbnails to main page using a previously stored reference to main window. for All the browsers previously stored reference works fine this problem only exist in opera.

  11. Ole Laursen writes:To the people who think Opera should just be strict here, there are in fact some half-way legitimate uses of tricks like these.If you set document.domain on a page, browsers start behaving funny. For instance, we've had the XML parser in Firefox die once document.domain is set. So it's nice to be able to confine document.domain hacks to small iframes without setting document.domain on the top page.Basically the pattern is that first you fire up an iframe, set up a nice and prepared environment with a reference you can use later, set document.domain (after which all bets are off), do the minimal you have to do and return the result through the reference left earlier.Some of these tricks are currently required to get cross-platform long-polling up and running. Please don't break them.

  12. Ole Laursen writes:Or rather, please unbreak them.Indeed, Opera 10 doesn't work with the standard iframe trick, while 9.something worked fine. Sigh

  13. Originally posted by anonymous:

    Some of these tricks are currently required to get cross-platform long-polling up and running.

    Interesting information – I didn't know about the XML parser issue. I know document.domain sometimes causes problems for XMLHttpRequest usage though. As usual, it's the workarounds and hacks for weirdness in one browser that causes more problems for the others than anything else…In any case, since HTML5 specifies and we implement window.postMessage(), setting document.domain is no longer a requirement for communication between frames from different origins.

Leave a comment