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

From: Adam Barth <[email-masked]>
Date: Mon, 21 Feb 2011 14:10:27 -0800

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.

Adam

---

From: John Kemp <[email-masked]>
Date: Mon, 21 Feb 2011 21:30:17 -0500

Hi Adam,

> will nitpick me over renaming URL to URI and MIME types to media

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?

i) Section 2. 'Trust': 

   * Is trust always specified by URL? Who is the trust specified by, and to whom is it granted? 
   * 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? 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? Is the content at the URL always "executed" by the user agent?
   * You mention the term 'principal' - ('principals export data to URLs') - do you mean "security principal", or "user", and are they always synonymous? 

ii) 2.1 Pitfalls

   * Is your only "pitfall" that someone might use the http URI scheme for both TLS and non-TLS protected resources? Might there not be other important trust distinctions visible in URLs? Perhaps some examples of distinguishing trust via URLs would be helpful here?

iii) 3. Origin

   * Some user agents do already treat each URL as a separate principal (at least in my understanding of a user agent)
   * Might be worth referencing the definition of origin as scheme, host and port

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'?
   * In general, what is the relationship between your content sniffing draft and this section on authority-as-conveyed-by-MIME-type?
   * How is the amount of authority designated? What constitutes full (or partial) authority? 

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?
   * 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.  
   * To whom is the "value proposition high enough" in making a cross-origin request? 
   * 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? 

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

Regards,

- John

> 
> Adam
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Adam Barth <[email-masked]>
Date: Mon, 21 Feb 2011 20:35:23 -0800

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.

>   * 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.

>   * 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.  :)

>   * 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 author…

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.

>   * 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 i…

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 o…

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

---

From: John Kemp <[email-masked]>
Date: Tue, 22 Feb 2011 08:47:32 -0500

Hey Adam,

> Thanks for the feedback.  Most of your comments revolve around scope.

Yes, and after reviewing your responses, I agree with that.

> complexity to spiral out of control.

Agreed.

>  It's taken us (where "us" here

Well, for example, trust is also granted by the recipient of an HTTP message with a particular Origin header to the sender of that message. 

> No.  Curl doesn't provide a web platform client execution environment.

Is a Javascript interpreter then required? A (standardized?) DOM? 

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

Even if the script is delivered to the user agent with a Content-type header with the value 'text/plain'?

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

Yes, it's also very specific, and not (in my opinion) illustrative even of the examples you discuss in the above-referenced paper.

You are also quite narrowly discussing how to prevent privilege escalation within a set of documents which are part of the same origin. That's a very specific (yes, important) kind of trust for the specific cases you mention.  

> leads quickly to disaster.

I think the examples you mention in your paper, regarding 'origin contamination' (EV certs, cookie path access etc.) support your case better FWIW.

> Omitting the MIME type is below the level of abstraction here.

How can that be - if authority is granted based on MIME type, what does it mean if no MIME type is given? 

> and create a vulnerability.

I understand that to be the very reason you wrote your sniffing draft, no? And servers can surely help here by not giving an indication of authority, should they not feel comfortable doing so, or to give an indication that the recipient should not grant the content any authority at all by specifying application/octet-stream. 

> That's defined by the specifications that describe the semantics of

Considering application/javascript or text/javascript, whose specifications seem to be in here: http://tools.ietf.org/html/rfc4329 there is no mention of 'authority' as a concept. Is the 'security considerations' section (http://tools.ietf.org/html/rfc4329#section-5) adequate for your purposes? Or am I looking in the wrong place?

> world-view, but I can assure you that this model is sensible in the

Well, you seem to be talking about trust granted by one software component to another. Which makes barely any sense to me at all, based on the general untrustworthiness exhibited by most software components I have used in my lifetime ;) But anyway, I understand where you are coming from, even if I would still argue that the trust of the user is important, and that trust of the various non-UA components is also important.

> cross-origin access.  Keep in mind that this document is descriptive,

Where is the user in all this? Don't API designers design their APIs so that developers can write applications for users to use?

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

Thanks.

> orbit famously don't quite fit).  However, it's still a useful model

I don't argue with any of that, but the question is about scope again, isn't it? Specifying a model becomes much easier when you know to what you should apply the model. Personally, I don't think of the whole Web as being limited to a particular class of user agents (whether they are called the "web platform" or not). I think the Web includes web servers. I think the Web includes users, crawlers and screen readers. Addressing the security model of a class of user agents is an excellent idea. But it is not a security model for the whole Web. 

Regards,

- John

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Feb 2011 14:22:45 -0700

> will nitpick me over renaming URL to URI and MIME types to media

Adam, what do you see as the relationship or division of work between
draft-ietf-websec-origin and draft-abarth-principles-of-origin?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Barth <[email-masked]>
Date: Thu, 24 Feb 2011 13:39:29 -0800

> draft-ietf-websec-origin and draft-abarth-principles-of-origin?

Just what it says in the charter:

[[
  The
  working group may split draft-abarth-origin into separate informative
  and standards track specifications, the former describing same-origin
  security model, and the latter specifying the nuts-and-bolts of working
  with origins (computing them from URLs, comparing them to each other,
  etc).
]]

Principles-of-origin is an informative document that explains the
underlying concepts of the security model.  Draft-ietf-websec-origin
is a normative document that explains the low-level details of how to
construct, compare, and serialize origins.  I don't feel strongly
about whether they're separate documents or the same document.  I just
thought it would be better to gather feedback in an individual draft
first in either case.

Adam

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Feb 2011 14:41:37 -0700

> thought it would be better to gather feedback in an individual draft

Thanks for the explanation, that's quite helpful. I'm going to read them
with that distinction in mind...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/