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

[John Kemp <[e-mail]>]

Hi Adam,

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?

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec