Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Jan 9, 2013 11:59 PM, Adam Barth w...@adambarth.com wrote: To gather this information, I grepped the WebKit IDL files for CheckSecurity. Here's what I learned: [snip] I see no mention of document.domain handling in your description. How do you handle the case when script from one Window grabs a Node from another Window and then the document of one of the two Windows change its document.domain property? Also, in another email you mentioned that you had managed to implement the security restrictions on the Window object as a white-list rather than a black list by marking some interfaces as needs same-origin checks and then listing the functions that don't need it. Does this mean that you mark all interfaces that are implemented by the Window and Location objects as needs security checks? Including EventTarget? / Jonas
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Mon, Jan 14, 2013 at 5:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Jan 9, 2013 11:59 PM, Adam Barth w...@adambarth.com wrote: To gather this information, I grepped the WebKit IDL files for CheckSecurity. Here's what I learned: [snip] I see no mention of document.domain handling in your description. Yeah, document.domain is no fun. :) How do you handle the case when script from one Window grabs a Node from another Window and then the document of one of the two Windows change its document.domain property? There isn't any code in WebKit that does anything special in this situation. Because there are no access checks for Node, the script can continue to use the Node interface as before. Also, in another email you mentioned that you had managed to implement the security restrictions on the Window object as a white-list rather than a black list by marking some interfaces as needs same-origin checks and then listing the functions that don't need it. Correct. Does this mean that you mark all interfaces that are implemented by the Window and Location objects as needs security checks? Including EventTarget? In WebKit, neither Location nor Window implement any other interfaces. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Thu, Jan 10, 2013 at 10:29 PM, Adam Barth w...@adambarth.com wrote: Yes, agreed. For what it's worth, I believe Gecko recently made history not accessible cross-origin anymore, so with any luck you'll be able to make this change too if desired... Do you have a link to the bug where that change was made? It's something I would definitely like to do if compatibility permits. We'd probably start with a measurement experiment... https://bugzilla.mozilla.org/show_bug.cgi?id=801576 Note that we haven't shipped the change yet - it's currently on the beta channel. Gavin
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/11/13 1:29 AM, Adam Barth wrote: On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, agreed. For what it's worth, I believe Gecko recently made history not accessible cross-origin anymore Do you have a link to the bug where that change was made? https://bugzilla.mozilla.org/show_bug.cgi?id=801576 Returning null for these is probably fine. I think I'd support making this list of things return null cross-origin. Just to check, do you make this determination based on the origin or the effective script origin (in spec terms)? The effective script origin. Good, good. So implementing this is pretty straightforward; just have to watch out for compat issues. The fact that you guys do it already should help with that, hopefully. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: Adam, thank you for taking the time to put this together. I really appreciate it. There are lots of things here where we can converge behavior no matter what happens with other pieces of the platform. On 1/9/13 5:58 PM, Adam Barth wrote: Generally speaking, I'd recommend exposing as few things across origins as possible. Yes, agreed. For what it's worth, I believe Gecko recently made history not accessible cross-origin anymore, so with any luck you'll be able to make this change too if desired... Do you have a link to the bug where that change was made? It's something I would definitely like to do if compatibility permits. We'd probably start with a measurement experiment... 6) In addition, the following APIs have extra security checks. All these APIs return a Node. Before returning the Node, they check whether the Node's document's origin is the same origin as the script calling the API. If not, they return null instead of the node. (We could potentially throw an exception here, but I'm just describing what WebKit does, not what I think the optimum design is.) Returning null for these is probably fine. I think I'd support making this list of things return null cross-origin. Just to check, do you make this determination based on the origin or the effective script origin (in spec terms)? The effective script origin. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, Jan 8, 2013 at 5:56 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/8/13 8:14 AM, Boris Zbarsky wrote: On 1/8/13 2:09 AM, Ian Hickson wrote: In the spec's security model, origins are never relevant for elements except when we're looking at the element's data. Yes. I think the spec's security model is not viable long-term, for what it's worth, and think we should be designing a security model that is instead... Just to clarify this. You may want to talk to sicking and Mounir about what they discovered about security models in the course of getting partially-elevated-privileges web apps to work. I suspect we'll need more of that sort of thing as time goes on. Which means the security model will likely need to evolve. I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, but I don't know of anything in the web platform that forces other browsers to deal with these issues. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. Which in turn means that I believe we should not be designing APIs and other functionality around the current security model, especially if the dependency is non-obvious (and I would argue that any dependency not spelled out in the section describing the security model is non-obvious, because it's too easy to miss it when updating the security model). What I think we ahould be doing instead is designing with the assumption that some core set of things is true (and we can argue about what set that is), but making as few assumptions as possible in general. This paragraph was too abstract for me to understand. Do you have a concrete example? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The security model in the spec is the same one we implement in WebKit and it's been working well for WebKit for a while. If there are security vulnerabilities, hopefully Chromium's security bounty will encourage you to report them. :) More seriously, life gets complicated when you introduce an asymmetric access relation, which I understand exists in Gecko. However, the open web platform contains only a symmetric access relation, and I intent to argue against any attempt to introduce an asymmetric access relation into the platform. Reasoning about security in this context of a symmetric access relation is relatively straightforward, and to check that new APIs don't screw up the model consists only of checking that they don't contain objects that are visibile to multiple origins. We have a handful of legacy objects that are already visible to multiple origins, and it's true that they're annoying to deal with, but we've already invested the engineering effort required to make them secure in the current security model. Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. Grepping WebKit's IDL files for [CheckSecurityForNode], it looks like this check is needed for contentDocument attribute and the getSVGDocument() method on the various interfaces that contain them. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 3:11 AM, Adam Barth wrote: I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, Actually, what I'm talking about here has nothing to do with APIs but everything to do with wanting to write web applications that have slightly more privileges than your typical web page. Again, you may want to talk to Jonas and Mounir for details. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. My argument is that we should not lock ourselves out of adding such features in the future. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. I'm not saying we should force anyone to implement any particular security model. I'm saying we shouldn't design/spec things that become completely insecure if the security model ever changes in any way and hence prevent evolution of the security model. Which means that we should assume as little as possible about what the security model guarantees us when specifying things. In my opinion. This paragraph was too abstract for me to understand. Do you have a concrete example? For example, Ian's argument is that you can skip security checks in various places because the security model does that already. My counter-argument is that we should define the behavior of those places by referencing the security model explicitly, so that if the security model changes we won't have to hunt down all the places that had implicit dependencies on it. Does that make more sense? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The current security model describes most common cases, but not some edge cases (see above about a slightly-elevated-privileges web app that can, say, touch nodes from one and only one different origin). More seriously, life gets complicated when you introduce an asymmetric access relation I agree. I believe, however, that for many apps based on web technology you in fact might need this. Again, Sicking and Mounir would know more. https://bugzilla.mozilla.org/show_bug.cgi?id=734891 has some of the things in it, but I'm not sure it's all of them. However, the open web platform contains only a symmetric access relation Yes, I understand that's how it stands now. I'm questioning the viability of this going forward, and especially questioning to what extent we should be intentionally making it impossible to change away from this model. and I intent to argue against any attempt to introduce an asymmetric access That is, of course, your right. ;) Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. That's not enough. Window has the same problem: the document IDL getter needs to check that you're allowed to get the document of the relevant window, for example. Is the check you describe for contentDocument based on origin or effective script origin? -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
It seems like your arguments all originate from wanting to support an asymmetric access relation. Supporting an asymmetric access relation is a bad idea, and we shouldn't do it. I understand that Mozilla already has technology for implementing an asymmetric access relation and that you're using it to implement a number of current and future Mozilla-proprietary features. That's fine, of course, but if you're interested in having those features become part of the web platform, please don't be surprised when other browser vendors refuse to implement them because of their asymmetric access relation. As a consequence, I would recommend that you do not use asymmetric access relations in features that you would like other browser vendors to implement in the future. Adam On Wed, Jan 9, 2013 at 7:16 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 3:11 AM, Adam Barth wrote: I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, Actually, what I'm talking about here has nothing to do with APIs but everything to do with wanting to write web applications that have slightly more privileges than your typical web page. Again, you may want to talk to Jonas and Mounir for details. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. My argument is that we should not lock ourselves out of adding such features in the future. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. I'm not saying we should force anyone to implement any particular security model. I'm saying we shouldn't design/spec things that become completely insecure if the security model ever changes in any way and hence prevent evolution of the security model. Which means that we should assume as little as possible about what the security model guarantees us when specifying things. In my opinion. This paragraph was too abstract for me to understand. Do you have a concrete example? For example, Ian's argument is that you can skip security checks in various places because the security model does that already. My counter-argument is that we should define the behavior of those places by referencing the security model explicitly, so that if the security model changes we won't have to hunt down all the places that had implicit dependencies on it. Does that make more sense? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The current security model describes most common cases, but not some edge cases (see above about a slightly-elevated-privileges web app that can, say, touch nodes from one and only one different origin). More seriously, life gets complicated when you introduce an asymmetric access relation I agree. I believe, however, that for many apps based on web technology you in fact might need this. Again, Sicking and Mounir would know more. https://bugzilla.mozilla.org/show_bug.cgi?id=734891 has some of the things in it, but I'm not sure it's all of them. However, the open web platform contains only a symmetric access relation Yes, I understand that's how it stands now. I'm questioning the viability of this going forward, and especially questioning to what extent we should be intentionally making it impossible to change away from this model. and I intent to argue against any attempt to introduce an asymmetric access That is, of course, your right. ;) Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. That's not enough. Window has the same problem: the document IDL getter needs to check that you're allowed to get the document of the relevant window, for example. Is the check you describe for contentDocument based on origin or effective script origin? -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 2:30 PM, Adam Barth wrote: As a consequence, I would recommend that you do not use asymmetric access relations in features that you would like other browser vendors to implement in the future. Browsers have asymmetric access relations all the time; they just have some of the code in C++. The question is why this should be restricted to C++ code. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 3:12 PM, Adam Barth wrote:
As I've stated several times on this thread (any many times over the
years), my opinion is that we should not expose an asymmetric access
relation to the web platform.
OK, let's agree to disagree on this one for now.
Do we at least agree that this code:
window.addEventListener.call(otherWindow, click, function() {});
should throw if and only window and otherWindow are not same-origin (for
some definition of same-origin, now that we have several different
origins involved...)? And if we do, do we agree that this needs to be
specified somewhere?
-Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 12:23 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/9/13 3:12 PM, Adam Barth wrote:
As I've stated several times on this thread (any many times over the
years), my opinion is that we should not expose an asymmetric access
relation to the web platform.
OK, let's agree to disagree on this one for now.
Do we at least agree that this code:
window.addEventListener.call(otherWindow, click, function() {});
should throw if and only window and otherWindow are not same-origin (for
some definition of same-origin, now that we have several different origins
involved...)?
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
And if we do, do we agree that this needs to be specified somewhere?
Yes, but this example is unrelated to the example you started this
thread with. The WindowProxy and Location objects are special,
magical objects that work differently from other interfaces because
they are visible across origins. The Document interface (which is
what we started this thread discussing) is never visible across
origins and so does not have any of these complexities. Earlier in
this thread, you wrote that you didn't want to discuss Location:
---8---
I'm not touching Location with a 10-foot pole. That's all Bobby. ;)
Seriously, though, fitting Location into any sort of security setup is
somewhat hard.
---8---
The WindowProxy object is even more complex than the Location object.
I agree that fitting Location and WindowProxy into any sort of
security setup is difficult. That's why I don't want to infect the
rest of the platform with their complexity. (I again, I understand
that Gecko has already jumped of the cliff in this regard---I'm just
not interested in jump off as well.)
Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Adam Barth wrote: The Document interface (which is what we started this thread discussing) is never visible across origins and so does not have any of these complexities. Actually Document objects can be visible across origins per spec, but none of their properties ever are. The four magic interfaces are Window, Document, Storage, and Location. They each have slightly different magic. But as far as this thread goes, the solution for all four is basically the same; calling code on any of them should just run the same check as is run when access properties on them. I'm happy to spec this, but IMHO the right spec is for WebIDL to introduce some hook I can use to make sure I catch all the relevant places. I don't really want the HTML spec to enumerate all the things here like getters and setters and methods and so forth that are relevant, I'd like it to just hook all of them at once, providing the algorithm for each of the above four interfaces, just like we do now for direct accesses. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, Jan 8, 2013 at 7:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: Actually, that's not enough. You have to security-check arguments too. Otherwise this: document.createTreeWalker(crossFrameDoc, etc); would be bad. (Note that right now the DOM spec fails to handle this, which is about what I would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) You didn't file a bug on this I think. I did think HTML handled this already though which is why it is not addressed in the DOM specification. -- http://annevankesteren.nl/
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, Adam Barth wrote: The Document interface (which is what we started this thread discussing) is never visible across origins and so does not have any of these complexities. Actually Document objects can be visible across origins per spec, but none of their properties ever are. For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, click, function() {});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
Hmm. I may be able to convince that turning security errors like this
into silent no-ops returning undefined is ok, but throwing an exception
seems like a much better idea to me if you're going to completely not do
what you were asked to do... The other option introduces hard-to-debug
bugs.
Yes, but this example is unrelated to the example you started this
thread with.
How so? The example was that IDL methods need to do security checks on
their arguments in various cases.
The WindowProxy and Location objects are special,
magical objects that work differently from other interfaces because
they are visible across origins.
However you prefer to think of it.
The Document interface (which is
what we started this thread discussing) is never visible across
origins
It is in the current spec.
The WindowProxy object is even more complex than the Location object.
It's actually simpler, in the aspects that matter for WebIDL security,
because underlying it is an actual Window object that you're same-origin
with or not, and you can just do security checks on it as needed. And
since the WebIDL is defined to work on the Window, it has to be able to
get to the Window from the WindowProxy anyway.
-Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:33 PM, Adam Barth wrote: For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. The HTML spec requires that property access on documents use effective script origin for checks. Effective script origins are mutable. It is in fact possible to get your hands on a document in a different effective script origin in WebKit (thanks, document.domain). Just saying, Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:28 PM, Anne van Kesteren wrote: You didn't file a bug on this I think. Yes, because the DOM spec is not the right place to address it, imo. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 5:19 PM, Adam Barth wrote: Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. OK. So what checks do you believe are required, then? Just effective script origin checks on Window? I would really appreciate it if you would actually describe the security model you think the spec should have instead of us having to guess what parts you think are needed and which parts you think are not needed, with more gotchas and details all the time. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Boris Zbarsky wrote:
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, click, function() {});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
Hmm. I may be able to convince that turning security errors like this into
silent no-ops returning undefined is ok, but throwing an exception seems like
a much better idea to me if you're going to completely not do what you were
asked to do... The other option introduces hard-to-debug bugs.
FWIW I have run into this behaviour in WebKit in the context of using the
platform, and I considered it very user-hostile.
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 2:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 4:33 PM, Adam Barth wrote: For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. The HTML spec requires that property access on documents use effective script origin for checks. Effective script origins are mutable. It is in fact possible to get your hands on a document in a different effective script origin in WebKit (thanks, document.domain). Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 2:24 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 5:19 PM, Adam Barth wrote: Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. OK. So what checks do you believe are required, then? Just effective script origin checks on Window? I would really appreciate it if you would actually describe the security model you think the spec should have instead of us having to guess what parts you think are needed and which parts you think are not needed, with more gotchas and details all the time. Answering this question in detail would take a great deal of time. I can try to summarize how WebKit handles this issues. In general WebKit tries to follow the spec's approach to these security checks, although there are some difference for historical reasons (e.g., not throwing exceptions, exposing or not exposing certain properties across origins). Generally speaking, I'd recommend exposing as few things across origins as possible. For example, I view WebKit's not exposing Document across origins as better than the spec's exposing it, whereas I view WebKit's exposing window.history across origins as worse than the spec's not exposing it. IMHO, we should aim for exposing the minimal set of things across origins. To gather this information, I grepped the WebKit IDL files for CheckSecurity. Here's what I learned: 1) By default, DOMWindow (which might translate into Window or WindowProxy in the spec---I'd need to study that issue more carefully) needs to perform access checks. There are a number of properties that are white listed, similar to what's described in the spec (cross-origin readers get fresh copies of the underlying interfaces regardless of any changes made to the DOMWindow in JavaScript and these fresh copies have prototype chains that connect up with the *caller's* JavaScript prototypes, not the DOMWindow's JavaScript prototypes). 2) window.history, window.location, window.focus, window.blur, window.close, window.closed, window.length, window.window, window.frames, window.opener, window.parent, window.top, window.postMessage, and window.toString are whitelisted to be exposed across origins (often just the getters, not the setters). There's some additional complexity related to the names of nested browsing context and the indexed property getter, but I believe the description in the current spec is accurate. 3) The History interfaces works much like the DOMWindow interface (properties are blocked by default and certain whitelisted properties are visible across origins on the same fresh, pristine basis as the properties on DOMWindow). 4) history.back, history.forward, and history.go are whitelisted. 5) The Location interface works much like DOMWindow and History, but the only whitelisted property is the location.href setter. 6) In addition, the following APIs have extra security checks. All these APIs return a Node. Before returning the Node, they check whether the Node's document's origin is the same origin as the script calling the API. If not, they return null instead of the node. (We could potentially throw an exception here, but I'm just describing what WebKit does, not what I think the optimum design is.) A) HTMLEmbedObject#getSVGDocument() B) HTMLFrameElement#contentDocument C) HTMLFrameElement#getSVGDocument() D) HTMLIFrameElement#contentDocument E) HTMLIFrameElement#getSVGDocument() F) HTMLObjectElement#contentDocument G) HTMLObjectElement#getSVGDocument() H) DOMWindow#frameElement With regards to your original question about using Function.prototype.call to manipulate the this value passed to function, I don't remember the details of how we dealt with that issue. I'd have to write some careful test cases to study WebKit's behavior to give you a definitive answer. We might have either ignored the this value entirely (and always operated on the object that held the property originally) or we might have insisted on always checking whether the calling script was same-origin with the this parameter for the three interfaces (DOMWindow, Location, and History) where the caller could possibly have a reference to a cross-origin object to pass as this. In addition to everything described above, there are some additional security issues related to operator eval and function eval, but I've left them out here because they're not relevant for the HTML spec. I should also say that it's entirely possible we've screwed up our implementation of this security model. If you discover that we have, I'd prefer if you filed a security bug rather than telling the world on this public mailing list. :) Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Adam Barth wrote: On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, Adam Barth wrote: The Document interface (which is what we started this thread discussing) is never visible across origins and so does not have any of these complexities. Actually Document objects can be visible across origins per spec, but none of their properties ever are. For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. That's interesting. Would other browser vendors be willing to do that? I'm certainly eager to make it null if we can get away with it. Would reduce the number of objects that need magic from 4 to 3. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Boris Zbarsky wrote: On 1/9/13 4:33 PM, Adam Barth wrote: For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. The HTML spec requires that property access on documents use effective script origin for checks. Effective script origins are mutable. It is in fact possible to get your hands on a document in a different effective script origin in WebKit (thanks, document.domain). Yeah but in that particular situation it's not a big deal to not have the security check as far as I can tell. So if we can just return null instead, it would allow us to remove those checks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, James Graham wrote:
On Wed, 9 Jan 2013, Boris Zbarsky wrote:
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, click, function()
{});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
Hmm. I may be able to convince that turning security errors like this
into silent no-ops returning undefined is ok, but throwing an
exception seems like a much better idea to me if you're going to
completely not do what you were asked to do... The other option
introduces hard-to-debug bugs.
FWIW I have run into this behaviour in WebKit in the context of using
the platform, and I considered it very user-hostile.
Yeah, we should throw SecurityError exception in these cases IMHO.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Anne van Kesteren wrote: On Tue, Jan 8, 2013 at 7:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: Actually, that's not enough. You have to security-check arguments too. Otherwise this: document.createTreeWalker(crossFrameDoc, etc); would be bad. (Note that right now the DOM spec fails to handle this, which is about what I would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) You didn't file a bug on this I think. I did think HTML handled this already though which is why it is not addressed in the DOM specification. If we can make Window.document and contentDocument on iframe, frame, and object return null when cross-origin, we can drop the security checks on Document and createTreeWalker(), as far as I can tell. That would maybe simplify matters a little. It's an orthogonal move relative to what bz has been advocating for in terms of what security model we should have, and it's more like what Chrome has. But do Opera and Microsoft want to go in that direction? I'm not over the moon about changing the security model without more buy-in. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
Adam, thank you for taking the time to put this together. I really appreciate it. There are lots of things here where we can converge behavior no matter what happens with other pieces of the platform. On 1/9/13 5:58 PM, Adam Barth wrote: Generally speaking, I'd recommend exposing as few things across origins as possible. Yes, agreed. For what it's worth, I believe Gecko recently made history not accessible cross-origin anymore, so with any luck you'll be able to make this change too if desired... 6) In addition, the following APIs have extra security checks. All these APIs return a Node. Before returning the Node, they check whether the Node's document's origin is the same origin as the script calling the API. If not, they return null instead of the node. (We could potentially throw an exception here, but I'm just describing what WebKit does, not what I think the optimum design is.) Returning null for these is probably fine. I think I'd support making this list of things return null cross-origin. Just to check, do you make this determination based on the origin or the effective script origin (in spec terms)? I should also say that it's entirely possible we've screwed up our implementation of this security model. If you discover that we have, I'd prefer if you filed a security bug rather than telling the world on this public mailing list. :) Indeed. ;) -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 16/12/12 9:34 PM, David Bruant wrote: WebIDL needs to embed in some way the notion of origin to enable throwing for security reasons in the right places. One idea would be to add an [OriginAware] extended attribute: * On operations (like in Boris case), an origin check would be performed before calling the core of the operation Why would this need to be on specific operations and not just be enforced on every operation? Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? * On attributes, both the getter and setter would throw if this is not of the right origin. * On interfaces, it would apply to everything (might be necessary for Window and Document) For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from.
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, 8 Jan 2013, Cameron McCormack wrote: On 16/12/12 9:34 PM, David Bruant wrote: WebIDL needs to embed in some way the notion of origin to enable throwing for security reasons in the right places. One idea would be to add an [OriginAware] extended attribute: * On operations (like in Boris case), an origin check would be performed before calling the core of the operation Why would this need to be on specific operations and not just be enforced on every operation? Most things don't have an origin. Origin checks are only done in some very specific places where you try to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. (Note: This is not what Gecko does. Some Mozilla people have been petitioning me to change the model in the spec to be more like Gecko's model.) Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? Both. For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from. In the case of Location, it's not about the origin of the object, it's about the origin of the active Document of the Window. See the Security sections in the HTML spec for examples of what we have now (there's one for Window, one for Document, and one for Location -- I think that's it). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/7/13 6:20 PM, Cameron McCormack wrote: Why would this need to be on specific operations and not just be enforced on every operation? I believe Gecko currently enforces this sort of thing on every operation, for what it's worth. Or it it that only a limited set of objects is exposed cross origin anyway The set of objects exposed is not particularly limited once document.domain gets involved. Note that there is longstanding disagreemed on which cases of direct property access should perform same-origin checks. Again, Gecko I believe does it for all but a whitelist of properties like Window.top and such. For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from. For what it's worth, in Gecko the is same origin determination is one and the same as implements an interface determination: a cross-origin object simply claims to not implement any interfaces from the caller's point of view. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/7/13 6:41 PM, Ian Hickson wrote: Most things don't have an origin. Pretty much everything has an origin in practice: it's associated with some Window, hence can be treated as having the same origin as that Window. Origin checks are only done in some very specific places where you try to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. I'm not quite sure we're talking about the same thing here. Can you give an example of what you're thinking? What _I'm_ thinking is that there needs to be a security check when someone does Document.prototype.getElementsByTagName.call(subframe.contentDocument). This is not the same security check as the one performed by subframe.contentDocument.getElementsByTagName (note lack of call; it never gets that far in the cross-origin case). This is independent of whether we're doing security checks on all property access or on some of them. Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? Both. Implementing different security models on the IDL level is a footgun of enormous size. We should simply have IDL methods throw if called with not-same-origin this or arguments, except for a whitelist. In my opinion. Anything else is fragile and leads to security whack-a-mole. Not that we can have the argument about which interfaces are subject to this security check if you want to only limit it to some objects; or example you could argue that this is only needed on Window, EventTarget, Document, Node, and a few others. That's a separate argument from whether the security checks for those interfaces should be opt-in or opt-out. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Mon, 7 Jan 2013, Boris Zbarsky wrote: On 1/7/13 6:41 PM, Ian Hickson wrote: Most things don't have an origin. Pretty much everything has an origin in practice: it's associated with some Window, hence can be treated as having the same origin as that Window. Per spec, even Windows actually don't have an origin. Things that have origins are URLs, Documents, images, audio and video elements, fonts, and scripts. Many of those things can have origins that are not that of the most obvious related (or in some cases any) Document. Origin checks are only done in some very specific places where you try to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. I'm not quite sure we're talking about the same thing here. Can you give an example of what you're thinking? Suppose you try to get the property from a Document whose origin doesn't match your script's origin. Right now, this throws a SecurityError, because of: # User agents must throw a SecurityError exception whenever any properties # of a Document object are accessed by scripts whose effective script # origin is not the same as the Document's effective script origin. -- http://www.whatwg.org/specs/web-apps/current-work/#security-document The check we need to add is for when you actually invoke the properties, in case you got the property from another Document and then apply it to this one. The check is the same -- if the Document that is the this to which the property is being applied doesn't match the origin of the script that is doing the applying, throw SecurityError. What _I'm_ thinking is that there needs to be a security check when someone does Document.prototype.getElementsByTagName.call(subframe.contentDocument). This is not the same security check as the one performed by subframe.contentDocument.getElementsByTagName (note lack of call; it never gets that far in the cross-origin case). This is independent of whether we're doing security checks on all property access or on some of them. Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Implementing different security models on the IDL level is a footgun of enormous size. We should simply have IDL methods throw if called with not-same-origin this or arguments, except for a whitelist. Except for having to define the origin of things for this purpose, yes, that's what I'm essentially saying. Not that we can have the argument about which interfaces are subject to this security check if you want to only limit it to some objects; or example you could argue that this is only needed on Window, EventTarget, Document, Node, and a few others. That's a separate argument from whether the security checks for those interfaces should be opt-in or opt-out. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/7/13 11:28 PM, Ian Hickson wrote: Per spec, even Windows actually don't have an origin. Things that have origins are URLs, Documents, images, audio and video elements, fonts, and scripts. Many of those things can have origins that are not that of the most obvious related (or in some cases any) Document. Yes, I know what the spec says. What I'm saying is that the spec is not doing anyone any favors by using origin to mean different things for different objects. In particular, for images/audio/video the origin in the spec is the origin that's relevant for the _data_, not necessarily for the element itself. Suppose you try to get the property from a Document whose origin doesn't match your script's origin. Right now, this throws a SecurityError Right. We all agree on this part; there is no problem here. The check we need to add is for when you actually invoke the properties, in case you got the property from another Document and then apply it to this one. Yes. The check is the same -- if the Document that is the this to which the property is being applied doesn't match the origin of the script that is doing the applying, throw SecurityError. That's an option, yes. As I said, Gecko throws TypeError like it would for a non-document. That happens to require less code, and I'm not sure people really care about the exact exception here (though I know bholley disagrees with me on this). Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) It's not redundant, because nothing says that subframeDoc.getElementsByTagName is actually the WebIDL-defined method; it could be something the script in the subframe set up. So you have to block access to it no matter what. needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) I would vastly prefer that this check be in the definition of the [[Call]], because then it can be done on the binding level, when you're checking the this object anyway. So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. Is that actually needed? There are properties you can obtain on objects cross-origin (like window.top) that I see no need to allow via this backdoor since no content depends on it now. So I would prefer simply checking whether the origin of the caller matches the origin of this. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Or you could spec what Gecko does, which is that any WebIDL call gets such a check, and then it's just defined in WebIDL. ;) Of course that does mean defining an origin for every object (as opposed to data associated with the object). Except for having to define the origin of things for this purpose, yes, that's what I'm essentially saying. OK. So here's the thing. Given any script-exposed object, it already has to be associated with a specific global. WebIDL makes this a requirement, since you have to find the right prototype object for it. At that point, you have a Window to work with, and a Window has an associated Document, and that has an origin. For object-access checks (again, as opposed to data-access checks), this is the right origin to use. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). EventTarget isn't implemented. It's inherited from. The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. var myGetter = Object.getOwnPropertyDescriptor(Node.prototype, firstChild).get; var node = myGetter.call(crossOriginDoc); This should throw; we agree on that, right? So I'm not sure what we're disagreeing about here. Perhaps you're thinking of this as throwing because of something crossOriginDoc does, while I'm thinking of it as throwing because of something myGetter does? Again, right now this is implemented in Gecko as part of myGetter's [[Call]], so that's the way I'm thinking of it. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/8/13 1:42 AM, Boris Zbarsky wrote: On 1/7/13 11:28 PM, Ian Hickson wrote: The check is the same -- if the Document that is the this to which the property is being applied doesn't match the origin of the script that is doing the applying, throw SecurityError. Actually, that's not enough. You have to security-check arguments too. Otherwise this: document.createTreeWalker(crossFrameDoc, etc); would be bad. (Note that right now the DOM spec fails to handle this, which is about what I would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, 8 Jan 2013, Boris Zbarsky wrote: On 1/7/13 11:28 PM, Ian Hickson wrote: Per spec, even Windows actually don't have an origin. Things that have origins are URLs, Documents, images, audio and video elements, fonts, and scripts. Many of those things can have origins that are not that of the most obvious related (or in some cases any) Document. Yes, I know what the spec says. What I'm saying is that the spec is not doing anyone any favors by using origin to mean different things for different objects. I don't think it means different things, but I guess that's semantics. In particular, for images/audio/video the origin in the spec is the origin that's relevant for the _data_, not necessarily for the element itself. In the spec's security model, origins are never relevant for elements except when we're looking at the element's data. Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) It's not redundant, because nothing says that subframeDoc.getElementsByTagName is actually the WebIDL-defined method; it could be something the script in the subframe set up. So you have to block access to it no matter what. Agreed; by being redundant in many cases I didn't mean that we could do away with it, just that in many cases you effectively have to do the check twice (since in most cases the property isn't overridden). needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) I would vastly prefer that this check be in the definition of the [[Call]], because then it can be done on the binding level, when you're checking the this object anyway. Doing it in [[Call]] and the various equivalents for IDL attributes would be fine by me. So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. Is that actually needed? There are properties you can obtain on objects cross-origin (like window.top) that I see no need to allow via this backdoor since no content depends on it now. So I would prefer simply checking whether the origin of the caller matches the origin of this. Well right now this doesn't necessarily have an origin. Also, consider Location. If you have a Location object and then navigate its browsing context and then call something on it, you need to check that the calling script doesn't match the origin of the new active document, not the origin of the Location object's Window's Document. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Or you could spec what Gecko does, which is that any WebIDL call gets such a check, and then it's just defined in WebIDL. ;) Doing a check on _every_ call seems rather expensive for implementations that don't use Gecko's security model compared to only doing a check on those interfaces that matter. Given any script-exposed object, it already has to be associated with a specific global. WebIDL makes this a requirement, since you have to find the right prototype object for it. A Location object has multiple prototypes (one for each origin that accesses it). At that point, you have a Window to work with, and a Window has an associated Document, and that has an origin. For object-access checks (again, as opposed to data-access checks), this is the right origin to use. For Storage, the access check has to be the actual origin of the Document, not the effective script origin as it does for Window and Document. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). EventTarget isn't implemented. It's inherited from. You're right, my bad. The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. var myGetter = Object.getOwnPropertyDescriptor(Node.prototype, firstChild).get; var node = myGetter.call(crossOriginDoc); This should throw; we agree on that, right? Assuming the script's effective
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, 8 Jan 2013, Boris Zbarsky wrote: On 1/8/13 1:42 AM, Boris Zbarsky wrote: On 1/7/13 11:28 PM, Ian Hickson wrote: The check is the same -- if the Document that is the this to which the property is being applied doesn't match the origin of the script that is doing the applying, throw SecurityError. Actually, that's not enough. You have to security-check arguments too. Otherwise this: document.createTreeWalker(crossFrameDoc, etc); would be bad. (Note that right now the DOM spec fails to handle this, which is about what I would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) I don't know about Document, but I can definitely think of APIs where it makes sense to be passing Window objects from other origins. (For example, one could imagine a PortCollection analogue for Window.postMessage() where you push the destination Window objects into an opaque object and then have the browser iterate over them.) I would be fine with an annotation on Document and Window that says that you can't pass them in as arguments when they're cross-origin except if the method's argument has itself been annotated with a I know what I'm doing marker. (Dunno how this would work with Location and Storage.) But if there's only one API that takes any of these four object types currently (I couldn't find any that took Document or Window in the HTML spec in a cursory look) then maybe it's not worth the bother. Wack a mole isn't _so_ bad if it's one mole a decade. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 12/15/12 8:33 PM, Jonas Sicking wrote: An easy solution would be to just return null for .contentDocument in the case of cross-origin iframes. Even if that were web-compatible (which is not obvious), that doesn't solve the problem of doing the same sort of thing with .contentWindow. -Boris
