Re: [websec] Principles of the Same-Origin Policy

[Adam Barth <[e-mail]>]

Hi John,

Thanks for the feedback.  Most of your comments revolve around scope.
This document is based on some text I wrote for an audience that was
pretty clear on the scope.  The web platform has a bunch of different
names.  Sometimes the W3C calls it the Open Web Platform, as in
<http://www.w3.org/QA/2010/10/html5_the_jewel_in_the_open_we.html>.
Historically, I think O'Reilly gets credit (at least according to
Wikipedia) for conceptualizing the "Web as Platform."  Certainly,
implementors think about shaping the direction of the web platform,
e.g., <http://www.chromium.org/developers/web-platform-status>.

We should certainly spend some time in the introduction setting
expectations about scope.  Part of the motivation for writing this
document is that many of these web technologies interact strongly in
the platform.  Without a coherent security model, it's easy for
complexity to spiral out of control.  It's taken us (where "us" here
is broadly defined) a while to converge on a coherent security model,
but this is pretty well-established stuff at this point, albeit
perhaps not clearly conceptualized and nominalized for folks who don't
work with this stuff on a daily basis.

Detailed responses inline.

On Mon, Feb 21, 2011 at 6:30 PM, John Kemp <[e-mail]> wrote:
> On Feb 21, 2011, at 5:10 PM, Adam Barth wrote:
>> Pursuant to the charter, I've posted an informational draft that
>> "describes the same-origin security model overall:"
>>
>> http://www.ietf.org/id/draft-abarth-principles-of-origin-00.txt
>>
>> I don't expect this document to be very controversial.  I'm sure folks
>> will nitpick me over renaming URL to URI and MIME types to media
>> types, however.  :)
>>
>> Feedback welcome.
>
> Some feedback which does not nitpick about your usage of URL or MIME:
>
> i) Introduction
>
>   * What is the "web platform", for the purposes of this discussion?

See above.

> i) Section 2. 'Trust':
>
>   * Is trust always specified by URL?

As far as I can tell, yes.  Do you have any examples that don't fit this theory?

> Who is the trust specified by,

Documents (or perhaps document authors if you don't want to ascribe
intention to documents).

> and to whom is it granted?

Whomever controls the resource designated by the URL.

>   * What do you consider to be a "user agent" - do you mean a Web browser, or the larger class of things which have often been called user agents?

If it's helpful for you to think about the user agent as a browser,
please feel free.  However, there are more user agents than just
browsers.  For example, the Adobe Air execution environment is a user
agent for the purposes of this document.  Essentially, the user agent
whatever provides the client execution environment in the web platform
(as distinct from the network and server execution environments).

> Wikipedia, for example (http://en.wikipedia.org/wiki/User_agent) mentions search engine crawlers and screen readers. Is 'curl' a user agent for the purposes of your statements about what a user agent does when accessing a script?

No.  Curl doesn't provide a web platform client execution environment.
 You might be able to twist your mind into thinking of it as a such in
some sort of degenerate way, but it's certainly not a particularly
interesting example from the point of view of this document.

> Is the content at the URL always "executed" by the user agent?

Yes.

>   * You mention the term 'principal' - ('principals export data to URLs') - do you mean "security principal", or "user", and are they always synonymous?

Principal is an abstract notion, which I believe originates from the
"orange book."  I suspect it's more akin to what you mean by a
security principal, and it's distinct from the user.

> ii) 2.1 Pitfalls
>
>   * Is your only "pitfall" that someone might use the http URI scheme for both TLS and non-TLS protected resources?

That's just an example.  There are lots of ways of screwing this up.
In fact, I wrote a whole paper about examples of people falling into
this pitfall:

http://www.adambarth.com/papers/2008/jackson-barth-b.pdf

The HTTP / HTTPS example is just one that's easy to explain and fairly
intuitive.

> Might there not be other important trust distinctions visible in URLs? Perhaps some examples of distinguishing trust via URLs would be helpful here?

The more interesting cases are when folks intent their to be trust
distinctions, but those distinctions *aren't* visible in URLs.  That
leads quickly to disaster.

> iii) 3. Origin
>
>   * Some user agents do already treat each URL as a separate principal (at least in my understanding of a user agent)

That might well be, but then they're not really participating in the
common security model of the web platform and are not relevant to this
discussion.

>   * Might be worth referencing the definition of origin as scheme, host and port

Sure.  Thankfully this working group is also working on precisely such
a document.  :)

> iv) 4. Authority
>
>   * You mention serving content as image/png instead of text/html - why not recommend either to serve the content without a Content-type header at all (as suggested by the W3C TAG finding on authoritative metadata - http://www.w3.org/2001/tag/doc/mime-respect) and have recipients follow your content sniffing algorithm (for example), or serve the content as 'application/octet-stream'?

That doesn't make sense.  This document is talking about what
authority the user agent bestows upon a resource.  It's making the
point that the authority depends on the MIME type of the resource.
Omitting the MIME type is below the level of abstraction here.

>   * In general, what is the relationship between your content sniffing draft and this section on authority-as-conveyed-by-MIME-type?

It's the reason why content sniffing is tricky.  If you aren't careful
about how you sniff, you might give too much authority to a resource
and create a vulnerability.

>   * How is the amount of authority designated?  What constitutes full (or partial) authority?

That's defined by the specifications that describe the semantics of
the various MIME types.

> v) 5. Policy
>
>   * Is it worth mentioning iframes and the iframe sandbox attribute here, in relation to scripts accessing objects belonging to the parent document?

That's too detailed.  This is an overview of the security model, not a
guide to all the various bells, whistles, and knobs.  Other documents,
such as <http://code.google.com/p/browsersec/>, are more appropriate
for that.

>   * You mention that blocking cross-origin requests would prevent users from following hyperlinks (and that this is core to web architecture). This highlighted (to me at least) that trust in URLs is *not* always origin-based. A user may trust content from multiple origins, and compose a page which contains such content.

We're not talking about what the user does or does not trust.  In
fact, we're not talking about the user at all.  We're talking about
the security model of the platform, independent of any user.  That
trips people up at first because they're used to a user-centric
world-view, but I can assure you that this model is sensible in the
absence of the user.

>   * To whom is the "value proposition high enough" in making a cross-origin request?

The designer and/or implementor of the API that permits the
cross-origin access.  Keep in mind that this document is descriptive,
not prescriptive.

>   * Can you explain, or provide an example, that illustrates your discussion about granting a privilege to one document and withholding it from another, even though this document is from the same origin?

Sure.  Please see the seven examples in Section 2 of
<http://www.adambarth.com/papers/2008/jackson-barth-b.pdf>.

> vi) 6. Conclusion
>
>   * I find it hard to believe that all trust relationships on the Web are designated via URLs, and that all security policy is associated with origins.

Keep in mind that this is a model.  Not everything in the world fits
the model.  Consider Newton's theory of gravity.  You would be correct
in being skeptical that not all the orbits of all the planets can be
described by Newtonian mechanics (in fact, observations of Mercury's
orbit famously don't quite fit).  However, it's still a useful model
and worth understanding.

In our case, the more modern pieces of the web platform are more
likely to follow this model.  It's mostly just the old crufty parts of
the platform that don't fit as well because we hadn't sorted all this
stuff out when we designed them.  Unsurprisingly, that's also where
most of the design-level vulnerabilities come from.

> Certainly it is one usable model, but there are others (you mention one yourself - "user agents could treat every URL as a separate principal").

Indeed, just as Newtonian mechanics is a really bad fit for Godel's
rotating universe.  However, in our universe, Newtonian mechanics is
often quite useful.

> Although the title of this document is 'Principles of the Same-Origin Policy', you have partially described a security model of the web based in origin. It feels as if you should either restrict this document to talk only about origin-based security policy, or more fully describe the web security model to which you allude. Do screen readers, crawlers and curl/wget fit into that model?

Which brings us back to clarifying the scope.  I agree that's an
important piece missing from the document.

Kind regards,
Adam