Re: fyi: Cross-Origin Resource Embedding Restrictions

Hi Noah,

On Mar 1, 2011, at 2:37 PM, Noah Mendelsohn wrote:

> On 3/1/2011 2:06 PM, Jonathan Rees wrote:
>> Until now the browser has been a user-agent, acting on
>> the user's behalf. This is true even when CORS is added. If I
>> understand it correctly, this proposal enlists the browser as a
>> server-agent as well, rather like DRM.
> 
> That's an interesting point, but I don't think the history is quite as clear as you imply. In many traditional Web interaction scenarios, the server depends, at least to some degree, on the correctness and good faith of the client. For example, is it really only the user who cares that certificates are checked when https-scheme URIs are derferenced? Clearly, any sufficiently knowledgeable user would care, but so might my bank, which might otherwise be somewhat more vulernable to man-in-the-middle attacks, I think.

If I were a bank, I wouldn't rely on the user not just clicking through when he was presented with an HTTPS certificate to approve from hotspot-gateway.com (when he actually went to my-bank.com). This has only a little to do with the client software itself - which simply can't say without user intervention whether someone with a certificate for hotspot-gateway.com is an entity with whom it should perform SSL (on behalf of the user). Humans have difficulty with this task too. 

If, as a server, I wished to (reasonably reliably) prevent an MITM in SSL, I would require an SSL client certificate (or equivalent mechanism of preventing a proxy, or MITM) when performing SSL with a requester. (and the user agent can help with this - I can trust it to present the relevant client certificate when challenged -- if the UA has been configured correctly)

I think the bank is vulnerable to MITM in this case regardless of the actions of the user agent. 

And I think that, similarly, using CORS is not a very strong means of protection from font license violations (as Maciej notes in http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html)

> In that case, I think both the use and (the application at) the server care.

They certainly both care, but neither can depend on the user agent to do much for them in the case you mention, without additional work by both the server and the user. 

Apropos this usage of CORS, Maciej's comments on providing a general mechanism for preventing "hotlinking" are interesting:

> == (2) The need for a general "anti-hotlinking" mechanism ==
> 
> The practice of directly embedding a resource from another origin is called "hotlinking". There are many valid uses for it, for example content distribution networks (CDNs) depend on this capability. But there are also valid reasons to restrict it. Here are some use cases:
> 
> A) Alice hosts an image, my-cute-kitten.jpg on her hosted site. She is happy to let people download it, but has a limited monthly bandwidth quota. Another site, content-farm.com, directly embeds the image. Due to powerful SEO, the page embedding the image is visited many times. The loads all hit Alice's server, putting her over her bandwidth quota and therefore taking her site down for the month. Alice is said. She wishes she could prevent image hotlinking like this.
> 
> B) Happy Fun Social Network has an account control web page, using cookie-based authentication. There are many buttons on this page that, if clicked by the user, will perform potentially regrettable side effects. evil.com embeds this page using the <iframe> element, and applies a technique called "clickjacking" to trick users into clicking on account settings. The unofficial X-Frame-Options header exists to address this, but it is relatively inflexible
> 
> It seems to me there is a clear need for a mechanism to prevent hotlinking of all kinds of resources. I think Opera's proposed "From-Origin" header is an excellent way to address the problem. (I would prefer a more explicit name, such as "Embed-Only-From-Origin" or something, but bikeshedding the name is not the key issue).


Regards,

- John

> 
> Noah
>

Received on Tuesday, 1 March 2011 21:57:39 UTC