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

On Wed, Jan 9, 2013 at 2:24 PM, Boris Zbarsky <bzbarsky@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

Received on Wednesday, 9 January 2013 22:59:31 UTC