|Summary:||Security exploit in postMessage using js to override the URI and domain|
|Product:||WebKit||Reporter:||Adam Barth <firstname.lastname@example.org>|
|Component:||HTML DOM||Assignee:||Sam Weinig <email@example.com>|
|Severity:||Normal||CC:||firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org|
|Version:||528+ (Nightly build)|
Overwriting of document.documentURI seems to be allowed by the DOM 3 Core spec (http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Document3-documentURI). That is not say we shouldn't change our behavior to match the other browsers, though I can't imagine that we would want to unless it poses a real security or compatibility concern. That said, I am not sure our doucment.documentURI implementation is correct. For this bug, I think the fix is to not use the Document::documentURI() for postMessage, but rather use the url from the FrameLoader (or perhaps one of the other 10 url related methods off the document, uhg).
> Overwriting of document.documentURI seems to be allowed by the DOM 3 Core spec Yep. You're right. Firefox throws a "not implemented" exception when you try to assign to documentURI, which we originally took to mean it wasn't assignable. > I am not sure our doucment.documentURI implementation is correct. I think it is not meant to be affected by the <base> tag. For example, the spec says: "the base URI is computed using first the value of the href attribute of the HTML BASE element if any, and the value of the documentURI attribute from the Document interface otherwise" , which implies that the two aren't necessarily equal. > For this bug, I think the fix is to not use the Document::documentURI() for > postMessage, but rather use the url from the FrameLoader That makes sense. The HTML5 spec should probably be clarified because it saids: "the uri attribute must be set to the URI of that document" , which sounds a lot like document.documentURI.  http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-baseURI  http://www.whatwg.org/specs/web-apps/current-work/#postmessage
I am calling this a P1 bug, because we have to either fix it or remove postMessage to avoid creating a security problem.
Created an attachment (id=18336) [details] Adds integrity to postMessage URI > For this bug, I think the fix is to not use the > Document::documentURI() for postMessage, but rather > use the url from the FrameLoader (or perhaps one of the > other 10 url related methods off the document, uhg). This patch changes postMessage to use the same URL field as document.location.
(From update of attachment 18336 [details]) Good patch! r=me However, it does not fix this bug as described in the title. It fixes the more important security problem in postMessage.
Created an attachment (id=18404) [details] Updated patch with more tests and updated document.domain behavior The HTML5 spec has been clarified to specify that the domain value should not change when the page sets document.domain. This updated patch changes the browser behavior to match the new spec. There's a new test case as well.
It looks like this patch has been r+'ed since Jan 12 but has not been landed. Is there something we can do on our end to help?
Oops, that is my fault. I will land it ASAP. Sorry.
I am going to close this bug and open another to track the original issue, the base tag overwrites document.documentURI.