Re: Proposal: Security checks after same-origin revocation with document.domain

> In an ideal world, we could all do our own thing here. Unfortunately, there's one
> situation where this behavior _is_ script-visible. That situation arises with
> document.domain. If two same-origin scripts become cross-origin via document.domain,
> one script could have grabbed document.firstChild from the other scope before the
> revocation occurred. What happens next depends on the application of security checks
> to arbitrary objects. Per spec, document.firstChild becomes a back door into the other
> scope, granting unfettered access as long as the script is careful enough to avoid
> touching Window, Location, and Document. 



A while ago, eBay's non-Flash image upload UI did rely on on getting references to functions in another frame, setting document.domain and being able to call said functions in spite of the now different security contexts. We gave them some advice on using postMessage() instead, I need to recheck to see if they've changed their code.


(Re-tested. Yeah, they have been working on it but the postMessage() call is only used if they detect Opera, and it's not actually working yet because they got the "target origin" argument's syntax wrong (didn't include protocol), plus they seem to have forgotten adding a message *listener* in the parent page..)


FWIW, that's the only compat issue I remember having seen due to Opera doing more security checks than what HTML5 specs. It's sufficiently bad to make us consider our behaviour a bug, though for easily understandable reasons "be less secure" is a class of bugs we're sort of reluctant to fix..



Well Bobby, at least you now know where to start testing if you add more security checks to the DOM: eBay. 


https://twitter.com/#!/hallvord/status/165016007029694465 :)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Monday, 16 April 2012 22:14:31 UTC