Re: [whatwg] A potential slight security enhancement to postMessage
On Wed, 30 Jan 2008, Collin Jackson wrote: Here is a suggestion for a backwards-compatible addition to the postMessage specification: Currently postMessage is great for sending authenticated messages between frames. The receiver knows exactly where each message came from. However, it doesn't provide any confidentiality guarantees. When you're posting a message to a window, you have no way of knowing who is listening on the other end, because the same-origin policy prevents you from reading the domain and URI of that window. The window may have been showing a page loaded from foo.com the last time you received a message from it, but it might be displaying content from bar.com now; if you send it a message, you don't whether the message will be received by foo.com or bar.com. For non-security-sensitive messages, like change your font color to red, confidentiality might not be needed. However, if the message you're trying to send contains a password, it would be nice to be able to specify which domain you're trying to send it to. The postMessage API could be extended to provide confidentiality by adding some optional arguments: void postMessage(in DOMString message, [optional] in DOMString domain, [optional] in DOMString uri); Done, using just 'origin'. On Fri, 1 Feb 2008, Collin Jackson wrote: You can try it out here: http://crypto.stanford.edu/websec/post-message/challenge-response/. This turned out to be slightly tricky. To send a single message, the sender has to first post a message to the recipient. The recipient then responds. At this point, during the execution of this callback, the domain and uri attributes of the event are accurate and the sender can safely send the message. There are a number of gotchas, which we think we've handled correctly, but it's hard to be sure. In the end, it would be much simpler and less error-prone to write this as a single line of code: frames[0].postMessage(message, theory.stanford.edu); You now have to say: frames[0].postMessage(message, http://theory.standford.edu;); Note that as defined, this: frames[0].postMessage(message, http://example.com/victim;); ...will allow messages to be sent to, e.g. http://example.com/evil;. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A potential slight security enhancement to postMessage
On Wed, 30 Jan 2008, Jeff Walden wrote:
I briefly wrote up some documentation on postMessage for the Mozilla
Developer Center:
http://developer.mozilla.org/en/docs/DOM:window.postMessage
If you pull it up, you'll note two places where I include big, huge,
overbearing, somewhat-exaggerating injunctions about first checking the
domain/uri/source properties of the received message before trusting the
sent data.
Writing those got me thinking: what if we could enforce not touching
the data before verifying the sender's identity? Specifically, what if
we required that either .domain or .uri be read prior to allowing .data
to be successfully accessed, say, without throwing a security error?
(No reason comes to mind for .source to participate in this scheme,
either to throw or to allow access to .data, but I haven't given it
serious thought.) This would prevent unknowing misuse of this
functionality, and safe uses wouldn't be affected. I think this would
only apply to the event dispatched by postMessage, not to MessageEvent,
as the latter is same-origin and there's no harm to a same-origin
MessageEvent.
Thoughts? A no-harm slight increase of the ability to prevent incorrect
use of postMessage, or excessive nannying?
I think most uses of this are actually going to be accepting connections
from any domain. I don't think it makes sense to require people who are
just exposing an interface to the world to require people to go through
hoops like this.
On Wed, 30 Jan 2008, Maciej Stachowiak wrote:
The more convenient version of that would be to require clients to
describe allowed senders when registering for the event in some way.
That would seem more like a convenience and less like a hoop to jump
through.
That's an option, but I fear that people would just end up calling
allowAnyone() (or whatever we call it) in a cargo-cult fashion,
undermining any security benefit.
On Thu, 31 Jan 2008, Jeff Walden wrote:
The key, tho, is that this really isn't a hoop to jump through.
Excluding toy public message board demos, can you describe a use case
for postMessage where it is not necessary to know the identity of the
sender? To know the identity you have to check domain or uri, and
there's no reason not to do that before getting the sent data.
Almost all cases I intend to use this API for are open to anyone to embed.
Game components, widgets, etc, none of them really care who is embedding
them.
On Thu, 31 Jan 2008, Aaron Boodman wrote:
Not necessarily. You could do something like this:
window.createMessageReceiver(http://www.google.com;)
.addEventListener(post-message, function() {
...
}, fase);
Could probably come up with a better method name, and I forget the name
of the event to use with PostMessage, but I hope you get the idea.
I like Maciej's suggestion of making it a natural part of the interface.
If you tell people they have to read x property before y property, they
will just do:
// spec says we have to read this first
var foo = event.domain;
alert(event.message);
But then people will just end up doing:
window.createMessageReceiver(*).addEventListener('message', foo, false);
...without understanding what the createMessageReceiver() part is about. I
don't think we'd really gain anything, except for slightly slowing things.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A potential slight security enhancement to postMessage
The original message never showed up, sadly, so the threading's going to be a bit wrong here, unfortunately. Currently postMessage is great for sending authenticated messages between frames. The receiver knows exactly where each message came from. However, it doesn't provide any confidentiality guarantees. When you're posting a message to a window, you have no way of knowing who is listening on the other end, because the same-origin policy prevents you from reading the domain and URI of that window. The window may have been showing a page loaded from foo.com the last time you received a message from it, but it might be displaying content from bar.com now; if you send it a message, you don't whether the message will be received by foo.com or bar.com. I noted in IRC discussion that postMessage being sync allows a challenge-response protocol to be safely used here, and you can determine the target's identification using domain/uri on the responding message; counterresponse was that's somewhat complicated. Fair enough; I'm not sure if super-security is the main use case for this feature or not (lightweight collaboration seems more likely to me, but I don't really know), so I'm hesitant to comment too much on it. The postMessage API could be extended to provide confidentiality by adding some optional arguments: void postMessage(in DOMString message, [optional] in DOMString domain, [optional] in DOMString uri); If domain or uri are specified, the browser would only deliver the message if the recipient's location matches the specified domain and/or URI. (Being able to specify the URI allows sites to differentiate between http and https URIs.) This seems reasonable enough. For privacy, postMessage should be designed not to reveal the domain or URI of the receiving window, so if there is a mismatch, the message should be silently dropped. Silent dropping is definitely good. Providing the domain and URI for replies should be easy since these values are already parameters of the event. True -- problem is requiring people use them, since they're not forced to do so now. Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
Aaron Boodman wrote:
Not necessarily. You could do something like this:
window.createMessageReceiver(http://www.google.com;)
.addEventListener(post-message, function() {
...
}, fase);
Could probably come up with a better method name, and I forget the
name of the event to use with PostMessage, but I hope you get the
idea.
Ah, yes, hadn't given it enough thought to think of that idea. Adding yet
another object type to the HTML5 system seems suboptimal, but it would address
the problem. A whitespace-separated string of URIs (or prefixes? or domains?
domains is least complicated but doesn't address protocol, and possibly not
port) seems like a reasonable way to do it.
If you tell people they have to read x property before y
property, they will just do:
// spec says we have to read this first
var foo = event.domain;
alert(event.message);
That'd be the fear, yes. It depends to an extent on how the documentation's
worded, which is the problem this is originally trying to avoid.
Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
On Feb 1, 2008 8:18 PM, Jeff Walden [EMAIL PROTECTED] wrote: Currently postMessage is great for sending authenticated messages between frames. The receiver knows exactly where each message came from. However, it doesn't provide any confidentiality guarantees. When you're posting a message to a window, you have no way of knowing who is listening on the other end, because the same-origin policy prevents you from reading the domain and URI of that window. The window may have been showing a page loaded from foo.com the last time you received a message from it, but it might be displaying content from bar.com now; if you send it a message, you don't whether the message will be received by foo.com or bar.com. I noted in IRC discussion that postMessage being sync allows a challenge-response protocol to be safely used here, and you can determine the target's identification using domain/uri on the responding message; counterresponse was that's somewhat complicated. Fair enough; I'm not sure if super-security is the main use case for this feature or not (lightweight collaboration seems more likely to me, but I don't really know), so I'm hesitant to comment too much on it. You could implement confidentiality on top of the original synchronous postMessage using a wrapper that performs challenge-response. Adam and I implemented this as a 48-line JavaScript library. You can try it out here: http://crypto.stanford.edu/websec/post-message/challenge-response/. This turned out to be slightly tricky. To send a single message, the sender has to first post a message to the recipient. The recipient then responds. At this point, during the execution of this callback, the domain and uri attributes of the event are accurate and the sender can safely send the message. There are a number of gotchas, which we think we've handled correctly, but it's hard to be sure. In the end, it would be much simpler and less error-prone to write this as a single line of code: frames[0].postMessage(message, theory.stanford.edu); Collin Jackson
Re: [whatwg] A potential slight security enhancement to postMessage
Maciej Stachowiak wrote: The more convenient version of that would be to require clients to describe allowed senders when registering for the event in some way. I thought about this, but then we necessarily lose the familiarity of the standard event-listener registration process, which outweighs the convenience in my book. Also, I half-think my suggestion is over-paranoia, and I don't give it enough credence to consider inventing a listener-registration process. That would seem more like a convenience and less like a hoop to jump through. The key, tho, is that this really isn't a hoop to jump through. Excluding toy public message board demos, can you describe a use case for postMessage where it is not necessary to know the identity of the sender? To know the identity you have to check domain or uri, and there's no reason not to do that before getting the sent data. I also see a message to this list from Collin Jackson which *should* have arrived in my inbox hours ago but hasn't, and I don't see it in my spam folder. I'm going to give it another half-day or so to appear, and at that point I'll do my best to respond without destroying the threading too much. The ideas suggested there are at first glance orthogonal to my original suggestion, and I also need time to fully formulate a response. Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
On Thu, Jan 31, 2008 at 4:25 AM, Jeff Walden [EMAIL PROTECTED] wrote:
Maciej Stachowiak wrote:
The more convenient version of that would be to require clients to
describe allowed senders when registering for the event in some way.
I thought about this, but then we necessarily lose the familiarity of the
standard event-listener registration process, which outweighs the convenience
in my book.
Not necessarily. You could do something like this:
window.createMessageReceiver(http://www.google.com;)
.addEventListener(post-message, function() {
...
}, fase);
Could probably come up with a better method name, and I forget the
name of the event to use with PostMessage, but I hope you get the
idea.
I like Maciej's suggestion of making it a natural part of the
interface. If you tell people they have to read x property before y
property, they will just do:
// spec says we have to read this first
var foo = event.domain;
alert(event.message);
- a
[whatwg] A potential slight security enhancement to postMessage
I briefly wrote up some documentation on postMessage for the Mozilla Developer Center: http://developer.mozilla.org/en/docs/DOM:window.postMessage If you pull it up, you'll note two places where I include big, huge, overbearing, somewhat-exaggerating injunctions about first checking the domain/uri/source properties of the received message before trusting the sent data. Writing those got me thinking: what if we could enforce not touching the data before verifying the sender's identity? Specifically, what if we required that either .domain or .uri be read prior to allowing .data to be successfully accessed, say, without throwing a security error? (No reason comes to mind for .source to participate in this scheme, either to throw or to allow access to .data, but I haven't given it serious thought.) This would prevent unknowing misuse of this functionality, and safe uses wouldn't be affected. I think this would only apply to the event dispatched by postMessage, not to MessageEvent, as the latter is same-origin and there's no harm to a same-origin MessageEvent. Thoughts? A no-harm slight increase of the ability to prevent incorrect use of postMessage, or excessive nannying? Jeff
Re: [whatwg] A potential slight security enhancement to postMessage
On Jan 30, 2008, at 6:00 PM, Jeff Walden wrote: I briefly wrote up some documentation on postMessage for the Mozilla Developer Center: http://developer.mozilla.org/en/docs/DOM:window.postMessage If you pull it up, you'll note two places where I include big, huge, overbearing, somewhat-exaggerating injunctions about first checking the domain/uri/source properties of the received message before trusting the sent data. Writing those got me thinking: what if we could enforce not touching the data before verifying the sender's identity? Specifically, what if we required that either .domain or .uri be read prior to allowing .data to be successfully accessed, say, without throwing a security error? (No reason comes to mind for .source to participate in this scheme, either to throw or to allow access to .data, but I haven't given it serious thought.) This would prevent unknowing misuse of this functionality, and safe uses wouldn't be affected. I think this would only apply to the event dispatched by postMessage, not to MessageEvent, as the latter is same-origin and there's no harm to a same-origin MessageEvent. Thoughts? A no-harm slight increase of the ability to prevent incorrect use of postMessage, or excessive nannying? The more convenient version of that would be to require clients to describe allowed senders when registering for the event in some way. That would seem more like a convenience and less like a hoop to jump through. Regards, Maciej
Re: [whatwg] A potential slight security enhancement to postMessage
Here is a suggestion for a backwards-compatible addition to the
postMessage specification:
Currently postMessage is great for sending authenticated messages
between frames. The receiver knows exactly where each message came
from. However, it doesn't provide any confidentiality guarantees. When
you're posting a message to a window, you have no way of knowing who
is listening on the other end, because the same-origin policy prevents
you from reading the domain and URI of that window. The window may
have been showing a page loaded from foo.com the last time you
received a message from it, but it might be displaying content from
bar.com now; if you send it a message, you don't whether the message
will be received by foo.com or bar.com.
For non-security-sensitive messages, like change your font color to
red, confidentiality might not be needed. However, if the message
you're trying to send contains a password, it would be nice to be able
to specify which domain you're trying to send it to.
The postMessage API could be extended to provide confidentiality by
adding some optional arguments:
void postMessage(in DOMString message, [optional] in DOMString domain,
[optional] in DOMString uri);
If domain or uri are specified, the browser would only deliver the
message if the recipient's location matches the specified domain and/or
URI. (Being able to specify the URI allows sites to differentiate
between http and https URIs.) If domain and uri are not defined,
the message would be delivered regardless of who the recipient is,
making this change backwards compatible for sites that aren't aware
of the optional parameters.
For privacy, postMessage should be designed not to reveal the domain
or URI of the receiving window, so if there is a mismatch, the message
should be silently dropped.
Providing the domain and URI for replies should be easy since these
values are already parameters of the event. Here is an example of code
that specifies the expected domain and URI for the recipient:
document.addEventListener('message', receiver, false);
function receiver(e) {
if (e.domain == 'example.com') {
if (e.data == 'Hello world') {
e.source.postMessage('Hello', e.domain, e.uri);
} else {
alert(e.data);
}
}
}
