[webkit-reviews] review requested: [Bug 15313] Same-origin check wrong when document.domain set : [Attachment 16442] Changes all rolled into one patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Sep 28 20:06:51 PDT 2007


Adam Barth <hk9565 at gmail.com> has asked  for review:
Bug 15313: Same-origin check wrong when document.domain set
http://bugs.webkit.org/show_bug.cgi?id=15313

Attachment 16442: Changes all rolled into one patch
http://bugs.webkit.org/attachment.cgi?id=16442&action=edit

------- Additional Comments from Adam Barth <hk9565 at gmail.com>
I've attached all the changes in one patch.

> I believe Firefox does ignore the port, but not the protocol, when both
> documents set document.domain.

This is possible.  I can run that test on Firefox.  It is essential, however,
to check the protocol in order to avoid the HTTPS attack described.

> I don't understand the exploit scenario. How do you "inject script" unless
> you already have access to example.com

HTTPS is designed to be secure against an active network attacker.  An active
network attacker can trivially inject script into an HTTP page as it travels
across the network.  The issue is that he can then escalate to injecting script
into an HTTPS page.  (Imagine a wireless HotSpot in a coffee shop or an
airport.)

> I also don't see how #2 from the original description applies.

I've added an attack scenario in the ChangeLog.  The same-origin policy treats
separate subdomains as mutually distrusting but allows a controlled form of
communication via document.domain.  One common use of this is in mashups, where
www.mashup.com and gadget.mashup.com communicate via iframes with
document.domain set to "mashup.com" (but, of course, www.mashup.com doesn't
fully trust gadget.mashup.com).  For detailed discussion, see
<http://www.collinjackson.com/research/papers/fp801-jackson.pdf>.



More information about the webkit-reviews mailing list