[whatwg] postMessage: event.source allows navigation of sender
Adam Barth and Collin Jackson pointed out to me that while
investigating frame navigation policies they found that a recipient of
a postMessage in Opera can set event.source.location, thus navigate
the sender window/document. I think this is a bug in the API itself.
This seems to violate the API's promise of safe cross-domain
communication even with untrusted documents. One can imagine use cases
where a script in document A has a reference to window B and thus can
post messages, but window B does not have any to A and would not under
normal circumstances be able to change A's address.
I think this should be adressed by removing event.source entirely. It
would be weird to disallow setting location on a window object in this
context only. To allow posting replies we could instead define a
function on the event object. Say for example
document.addEventListener( 'message', function(e){
if(e.data=='Hi'){
e.reply('Hello');
}
}, false )
--
Hallvord R. M. Steen
Re: [whatwg] postMessage: event.source allows navigation of sender
On Feb 7, 2008 10:24 AM, Hallvord R M Steen wrote: Adam Barth and Collin Jackson pointed out to me that while investigating frame navigation policies they found that a recipient of a postMessage in Opera can set event.source.location, thus navigate the sender window/document. I think this is a bug in the API itself. If what you say is true (see below) I'd rather say it's a bug in Opera's implementation. This seems to violate the API's promise of safe cross-domain communication even with untrusted documents. One can imagine use cases where a script in document A has a reference to window B and thus can post messages, but window B does not have any to A and would not under normal circumstances be able to change A's address. Shouldn't event.source.location be read-only? Isn't that a direct application of the same-origin policy? The current draft contains the following note: Implementors are urged to take extra care in the implementation of this feature. It allows authors to transmit information from one domain to another domain, which is normally disallowed for security reasons. It also requires that UAs be careful to allow access to certain properties but not others. See also http://www.whatwg.org/specs/web-apps/current-work/multipage/section-history.html#security5 And setting the event.source (Window object)'s location property is covered by the following paragraph: In the ECMAScript DOM binding, the location members of the HTMLDocument and Window interfaces behave as if they had a setter: user agents must treats attempts to set these location attribute as attempts at setting the href attribute of the relevant Location object instead. — source: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-history.html#location0 which invokes the #security5 above. -- Thomas Broyer
Re: [whatwg] postMessage: event.source allows navigation of sender
Hallvord, On Feb 7, 2008 1:24 AM, Hallvord R M Steen [EMAIL PROTECTED] wrote: Adam Barth and Collin Jackson pointed out to me that while investigating frame navigation policies they found that a recipient of a postMessage in Opera can set event.source.location, thus navigate the sender window/document. I think this is a bug in the API itself. When one frame posts a message to another frame, the recipient frame obtains a pointer to the sender frame as the source attribute of the message event. In Opera, this leaks the capability to navigate the sender's frame to the recipient because Opera assumes that if a script has a JavaScript pointer to a frame then that script is permitted to navigate that frame. The source attribute of the message event does not leak any privileges to the recipient in Internet Explorer, Firefox, and Safari because these browsers do not make this assumption and instead check whether the script is permitted to navigate the frame when the script assigns window.location. In Opera, it is difficult to obtain a JavaScript pointer to a frame because Opera prevents scripts from reading window.frames[i] across domains. Internet Explorer, Firefox, and Safari all allow scripts to read window.frames[i] across domains. This seems to violate the API's promise of safe cross-domain communication even with untrusted documents. One can imagine use cases where a script in document A has a reference to window B and thus can post messages, but window B does not have any to A and would not under normal circumstances be able to change A's address. Other browsers do not equate having a JavaScript pointer to a frame with the ability to navigate that frame. I think this should be adressed by removing event.source entirely. Another way to resolve the issue is for Opera to match the other browsers and check whether a script is permitted to navigate a frame when that scripts assigns the frame's location. On Feb 7, 2008 1:45 AM, Thomas Broyer [EMAIL PROTECTED] wrote: Shouldn't event.source.location be read-only? Isn't that a direct application of the same-origin policy? Internet Explorer, Firefox, Safari, and Opera all permit a script to write window.location across domains. This action is interpreted as a request to navigate the frame. The browser's frame navigation policy determines whether this navigation is permitted. Adam
Re: [whatwg] postMessage: event.source allows navigation of sender
On 07/02/2008, Hallvord R M Steen [EMAIL PROTECTED] wrote: That is of course a possibility. I don't have Firefox 3 handy so I'd appreciate somebody explaining how it is implemented there. By the way, I recommend Minefield (the Firefox 3 nightlies) to anyone. I now use it as my default browser on Windows. There are occasional bad builds, but mostly it's just better in every way than Firefox 2. Lots of nice incremental improvements to the interface, less memory-hogging, more responsive, better at handling 200 tabs open, and so on. The only minus point is that most of my favourite extensions haven't been updated yet. - d.
Re: [whatwg] postMessage: event.source allows navigation of sender
On 07/02/2008, Thomas Broyer [EMAIL PROTECTED] wrote: On Feb 7, 2008 10:24 AM, Hallvord R M Steen wrote: Adam Barth and Collin Jackson pointed out to me that while investigating frame navigation policies they found that a recipient of a postMessage in Opera can set event.source.location, thus navigate the sender window/document. I think this is a bug in the API itself. If what you say is true (see below) I'd rather say it's a bug in Opera's implementation. That is of course a possibility. I don't have Firefox 3 handy so I'd appreciate somebody explaining how it is implemented there. Shouldn't event.source.location be read-only? Isn't that a direct application of the same-origin policy? No, all user agents I know allow you to set window.location across domains. Not doing so would break literally millions of web pages. As event.source just points to the sending window object setting event.source.location is same as setting window.location . The current draft contains the following note: Implementors are urged to take extra care in the implementation of this feature. It allows authors to transmit information from one domain to another domain, which is normally disallowed for security reasons. It also requires that UAs be careful to allow access to certain properties but not others. Do you really thing this vague paragraph *can* be interpreted as saying normal same-domain policies should be extended with a stricter policy that also disallows setting location? It's not exactly clear. See also http://www.whatwg.org/specs/web-apps/current-work/multipage/section-history.html#security5 And setting the event.source (Window object)'s location property is covered by the following paragraph: In the ECMAScript DOM binding, the location members of the HTMLDocument and Window interfaces behave as if they had a setter: user agents must treats attempts to set these location attribute as attempts at setting the href attribute of the relevant Location object instead. Indeed. All UAs already do that - if you set location, you set .href. Have a look at section 4.7.4.1. Security which reads: User agents must raise a security exception whenever any of the members of a Location object are accessed by scripts whose origin is not the same as the Location object's associated Document's origin, with the following exceptions: * The href setter So setting location actually sets href, and setting href is explicitly permitted across domains. By my reading the spec clearly dictates what Opera has implemented, so the original question remains. -- Hallvord R. M. Steen
Re: [whatwg] postMessage: event.source allows navigation of sender
Adam Barth and Collin Jackson pointed out to me that while investigating frame navigation policies they found that a recipient of a postMessage in Opera can set event.source.location, thus navigate the sender window/document. I think this is a bug in the API itself. When one frame posts a message to another frame, the recipient frame obtains a pointer to the sender frame as the source attribute of the message event. In Opera, this leaks the capability to navigate the sender's frame to the recipient because Opera assumes that if a script has a JavaScript pointer to a frame then that script is permitted to navigate that frame. This is actually per the spec and required for web compatibility: any script that has a pointer to a window object can usually set its location property. I expect most UAs only disallow it for http-https communication and I know Opera is a tad stricter than the others and disallow it if domains do not match for https-https communication. If you have test cases that show other browsers disallowing scripts that have a pointer to a window object from setting location across domains I'd very much like to see them. Being more restrictive in certain cases would be nice but is in my experience not possible without too much breakage, so I'm very interested if you can demonstrate stricter policies that actually work. (Note that I am talking only about setting window.location here, not about e.g. targetting a named window with a window.open call - that's a different scenario entirely.) The source attribute of the message event does not leak any privileges to the recipient in Internet Explorer, Firefox, and Safari because these browsers do not make this assumption and instead check whether the script is permitted to navigate the frame when the script assigns window.location. Adam, I don't quite follow you here because I don't know any IE or Safari implementation of window.postMessage. I'm quite sure IE doesn't implement it, I tried googling for Safari and postMessage/cross-document messaging but didn't find anything. As far as I know only Firefox 3 betas and Opera supports this, so no other implementations can be tested. In Opera, it is difficult to obtain a JavaScript pointer to a frame because Opera prevents scripts from reading window.frames[i] across domains. Internet Explorer, Firefox, and Safari all allow scripts to read window.frames[i] across domains. We should probably fix that if there is consensus on the more liberal approach - though note that Opera nevertheless allows you to set window.frames[i].location across domain. I don't know how you tested allow scripts to read window.frames[i] to reach the above statement. If you try a simple alert(window.frames[i]) you're actually calling the toString() method of the window object, which Opera disallows across domains so you get a security exception there. (Perhaps a pointless one..) Other browsers do not equate having a JavaScript pointer to a frame with the ability to navigate that frame. Again if you can back that up with test cases I'd love to see them :-) I think this should be adressed by removing event.source entirely. Another way to resolve the issue is for Opera to match the other browsers and check whether a script is permitted to navigate a frame when that scripts assigns the frame's location. But this would have to be applied only when window.location was set in a message event handler - that would get very messy! Alternatively we could pass in a fake window object that does not allow setting location, but that would directly contradict the spec and not be much cleaner. A postback function on the event object is by far the cleanest approach I can think of. (Apologies to the Opera and Firefox developers who would have to change their implementations..) On Feb 7, 2008 1:45 AM, Thomas Broyer [EMAIL PROTECTED] wrote: Shouldn't event.source.location be read-only? Isn't that a direct application of the same-origin policy? Internet Explorer, Firefox, Safari, and Opera all permit a script to write window.location across domains. This action is interpreted as a request to navigate the frame. The browser's frame navigation policy determines whether this navigation is permitted. Exactly. -- Hallvord R. M. Steen
Re: [whatwg] postMessage: event.source allows navigation of sender
On Feb 7, 2008 2:27 AM, Hallvord R M Steen [EMAIL PROTECTED] wrote: Opera assumes that if a script has a JavaScript pointer to a frame then that script is permitted to navigate that frame. This is actually per the spec and required for web compatibility: any script that has a pointer to a window object can usually set its location property. This does not seem to be required for web compatibility because Internet Explorer, Firefox, and Safari all restrict what happens when you assign a frame's location property according to their navigation policy. If the navigation is denied, Internet Explorer opens the page in a popup instead (unless blocked by the popup blocker) and Firefox throws an exception. The latest nightly build of Safari also opens a popup window when a navigation is denied, but the currently deployed version only logs the error to the debug console. I expect most UAs only disallow it for http-https communication and I know Opera is a tad stricter than the others and disallow it if domains do not match for https-https communication. The frame navigation policy in Internet Explorer, Firefox, and Safari is based on origins. If two frames are in a different origin, the frame navigation policy does not distinguish origin differences due to hosts from origin differences due to schemes. If you have test cases that show other browsers disallowing scripts that have a pointer to a window object from setting location across domains I'd very much like to see them. Here is a test case: http://crypto.stanford.edu/~abarth/research/html5/sibling/ The first child frame is in a different origin from the top-level frame and from the second child frame. In Internet Explorer, Firefox, and Safari, the first frame can obtain a JavaScript pointer to the second frame, but cannot navigate the frame by assigning its location property. This demo works in Internet Explorer 7, Safari 3, and Firefox 3. Being more restrictive in certain cases would be nice but is in my experience not possible without too much breakage, so I'm very interested if you can demonstrate stricter policies that actually work. This demonstration shows that Internet Explorer, Firefox, and Safari restrict these cases. These browsers are widely deployed, and the best thing for compatibility would be for all browsers to consistently apply the same policy. (Note that I am talking only about setting window.location here, not about e.g. targetting a named window with a window.open call - that's a different scenario entirely.) Yes. Named window navigation is another scenario. Adam, I don't quite follow you here because I don't know any IE or Safari implementation of window.postMessage. I'm quite sure IE doesn't implement it, I tried googling for Safari and postMessage/cross-document messaging but didn't find anything. As far as I know only Firefox 3 betas and Opera supports this, so no other implementations can be tested. postMessage is implemented in the trunk version of Safari. http://nightly.webkit.org/ I do not know if postMessage will be implemented in Internet Explorer 8, but if it were to be implemented in IE8, the source attribute would not leak any privileges to the recipient because IE checks whether the navigation is permissible before performing the navigation. We should probably fix that if there is consensus on the more liberal approach Yes, interoperability would be improved if all browsers implemented the same security policy. though note that Opera nevertheless allows you to set window.frames[i].location across domain. I don't know how you tested allow scripts to read window.frames[i] to reach the above statement. If you try a simple The same demo at http://crypto.stanford.edu/~abarth/research/html5/sibling/ shows that Opera does not permit a script to assign top.frames[1].location when top and the second frame are in a different domain. Other browsers do not equate having a JavaScript pointer to a frame with the ability to navigate that frame. Again if you can back that up with test cases I'd love to see them :-) This is the same test case. I think this should be adressed by removing event.source entirely. Another way to resolve the issue is for Opera to match the other browsers and check whether a script is permitted to navigate a frame when that scripts assigns the frame's location. But this would have to be applied only when window.location was set in a message event handler - that would get very messy! I'm suggesting Opera should match the behavior of other browsers and check whether a navigation is permissible under its frame navigation policy before performing the navigation, regardless of how the browser was requested to perform the navigation. It is difficult to control navigation by containing references to frames because it is easy for JavaScript pointers to frames to escape in unexpected ways, for example via the source attribute of the message
[whatwg] Calendar subscription as a feed?
Consider a site that has something like an event calendar (may be displayed with a table layout or just a simple list). How should one link to iCalendar information that is meant for subscription or importing to reader's calendaring software? (This is different from a single event information for which one could use a microformat.) Currently it seems that there are two practical ways to link to a iCalendar file; one may distribute the .ics file via HTTP or with webcal protocol (which, if I've understood correctly, is just HTTP with different protocol name to help with binding with correct program). So I can write a href=webcal://example.com/feed.icsSubscribe events/a or a href=http://example.com/feed.ics;Download events/a However, both of these URLs could really be used for subscriptions. Should I mark up those as feeds? Should calendar feeds have different rel type than feed? Is it okay to write something like a href=http://example.com/feed.ics; rel=feed type=text/calendarCalendar feed/a? The feed keyword is defined as the feed keyword indicates that the referenced document is a syndication feed at http://www.whatwg.org/specs/web-apps/current-work/#link-type5 - is a calendar feed a syndication feed? -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] postMessage: event.source allows navigation of sender
On Feb 7, 2008, at 2:27 AM, Hallvord R M Steen wrote: The source attribute of the message event does not leak any privileges to the recipient in Internet Explorer, Firefox, and Safari because these browsers do not make this assumption and instead check whether the script is permitted to navigate the frame when the script assigns window.location. Adam, I don't quite follow you here because I don't know any IE or Safari implementation of window.postMessage. I'm quite sure IE doesn't implement it, I tried googling for Safari and postMessage/cross-document messaging but didn't find anything. As far as I know only Firefox 3 betas and Opera supports this, so no other implementations can be tested. The current development version of WebKit includes support for cross- document messaging. I don't think any publicly available version of IE has it. However I think Adam was speaking in the general sense here, that getting a window object reference that you couldn't otherwise would not leak navigation capability in the named browsers regardless of how you get it. Other browsers do not equate having a JavaScript pointer to a frame with the ability to navigate that frame. Again if you can back that up with test cases I'd love to see them :-) I don't have a test case handy for this but I can assure you Safari/ WebKit only allows navigating other frames in the following cases: // The navigation change is safe if the active frame is: // - in the same security origin as the target or one of the target's ancestors // Or the target frame is: // - a top-level frame in the frame hierarchy This test is applied at the time window.location is assigned. If these conditions are not met, assigning the location property of another frame/window has no effect. You can probably figure out how to make a test case based on this. Regards, Maciej
Re: [whatwg] postMessage: event.source allows navigation of sender
Opera assumes that if a script has a JavaScript pointer to a frame then that script is permitted to navigate that frame. This is actually per the spec and required for web compatibility Here is a test case: http://crypto.stanford.edu/~abarth/research/html5/sibling/ Ah sorry, I see what you mean. Haven't let all the implications of your ancestor policy research sink in yet. You are perfectly right that Opera's security policy here relies on disallowing getting the window object rather than setting location. Implementing the ancestore policy takes care of most of the scenarios I can think of where you may want to post messages to a window that should not be allowed to change your location. One case I'm still somewhat concerned about is that one is allowed to set the location of any top-level window according to the ancestor policy, so calling postMessage on untrusted windows from your top window is still somewhat dangerous. That's something we have to allow for web compatibility and for this reason I still think removing event.source from the message event interface would be a good idea. For example, consider w=window.open(); w.opener = null; w.location = 'http://untrusted.example.org' w.postMessage( '...' ); Untrusted content now gets a window reference it would not otherwise have, and will be allowed to set location if this scripts runs in the top context of the opener. -- Hallvord R. M. Steen
Re: [whatwg] postMessage: event.source allows navigation of sender
On Feb 7, 2008 10:59 AM, Hallvord R M Steen wrote: Have a look at section 4.7.4.1. Security which reads: User agents must raise a security exception whenever any of the members of a Location object are accessed by scripts whose origin is not the same as the Location object's associated Document's origin, with the following exceptions: * The href setter Oops! My bad, missed the exceptions... -- Thomas Broyer
