Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters

On Tue, Jan 8, 2013 at 5:56 AM, Boris Zbarsky <bzbarsky@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

Received on Wednesday, 9 January 2013 08:12:05 UTC