On Wed, Jul 7, 2010 at 1:11 PM, Eran Hammer-Lahav <[email protected]> wrote: > Thanks. Browser security is not my area. > > It seems to me that this must be documented as all the examples I have seen > for such scripts did not include any such security measures.
Nor is it mine. I know some techniques for cross-origin communication, but not intimately enough to know all the security implications raised by each in various browsers. As a general rule, though, iframes can't talk to one another if they have different origins. There are several ways to bend the rule. Doing so would introduce security problems for OAuth. 1. Communication via setting URI fragments in other iframes and detecting such changes in your own iframe. 2. Proxy iframes. So we should tell people not to (blindly) use those or other techniques that don't respect the same-origin restriction. Instead, they could just directly call functions in one iframe from another iframe (parent.doSomething( blah )). Browsers will only allow this between same-origin iframes. If an implementor needs cross domain functionality, there's a new, safer technology that allows both ends to whitelist who they talk to. Cross-document messaging http://www.w3.org/TR/html5/comms.html#crossDocumentMessages I'm not familiar with cross-document messaging or how well it's supported by browsers. Also note that same-origin security does not protect against malicious communication between two iframes on the same origin but different paths. http://example.com/naive-client/ and http://example.com/evil-scraper/, for example. Because of that, the child iframe should probably check its parent's entire URL, not just the domain/origin. Mike --mdawaffe _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
