Re: Cross-Origin Resource Embedding Restrictions

[Daniel Veditz]

On 3/1/11 12:26 AM, Adam Barth wrote:
> From-Origin is closely related to one of the proposed CSP
> features, namely frame-ancestors, which also controls how the
> given resource can be embedded in other documents:

Also similar to X-Frame-Options; I'd hate to end up with all three
mechanisms. I'd be happy(ish) to jettison frame-ancestors from CSP
if there's another competent header that can take up that use-case.
Mainly we wanted to fix X-Frame-Options (without introducing the
incompatibilities of "embrace and extend") but didn't want to invent
yet another header to do it.

Depending on how it's eventually spec'd the Origin header could
satisfy the same use-case with server-side enforcement. For that to
happen it'd have to be sent with every request; not sure it's
specified that way currently.

Personally I'm more optimistic about client-enforced mechanisms
because you only need five or so correct browser implementations,
not tens or hundreds of app framework implementations. Either way
the site authors have to correctly specify their policy, of course,
and that's a big concern.

-Dan Veditz

Re: Cross-Origin Resource Embedding Restrictions

[Nathan]

Glenn Maynard wrote:

On Tue, Mar 1, 2011 at 3:33 PM, Nathan  wrote:

(rather than controlled only "by user agents which choose to follow the specs" 
offering
an artificial screen).


If user agents deliberately ignore the specs to allow embedding where
authors don't want it to, they can do it with any model--Referer,
Origin, From-Origin, etc.  They all depend on UA cooperation.

In practice, as long as most browsers support it and enable it by
default, that's enough to discourage people from embedding resources
from sites that don't want them to.


However, on this specific draft, is there any chance you can move to a
white-list/black-list model, where people can send either Allow-Origin or
Deny-Origin, for instance in many scenarios I want to allow everyone except
origins A and B who I know consistently "steal" bandwidth, or display my
resources beside unsavoury ones.


Sending whitelists in a header makes sense to me, but sending
blacklists with every request doesn't scale--such a list could easily
end up having dozens of entries, bloating the headers for every
request.  You may not actually want to expose your entire blacklist to
the public, either.

Blacklisting does seem like a fair use case, though; it often makes
sense to want to block particularly abusive sites, without blocking
everyone.


yes, hence suggesting to offer both, let the resource owners manage how 
they want :)

Re: Cross-Origin Resource Embedding Restrictions

[Glenn Maynard]

On Tue, Mar 1, 2011 at 3:33 PM, Nathan  wrote:
> (rather than controlled only "by user agents which choose to follow the 
> specs" offering
> an artificial screen).

If user agents deliberately ignore the specs to allow embedding where
authors don't want it to, they can do it with any model--Referer,
Origin, From-Origin, etc.  They all depend on UA cooperation.

In practice, as long as most browsers support it and enable it by
default, that's enough to discourage people from embedding resources
from sites that don't want them to.

> However, on this specific draft, is there any chance you can move to a
> white-list/black-list model, where people can send either Allow-Origin or
> Deny-Origin, for instance in many scenarios I want to allow everyone except
> origins A and B who I know consistently "steal" bandwidth, or display my
> resources beside unsavoury ones.

Sending whitelists in a header makes sense to me, but sending
blacklists with every request doesn't scale--such a list could easily
end up having dozens of entries, bloating the headers for every
request.  You may not actually want to expose your entire blacklist to
the public, either.

Blacklisting does seem like a fair use case, though; it often makes
sense to want to block particularly abusive sites, without blocking
everyone.

-- 
Glenn Maynard

Re: Cross-Origin Resource Embedding Restrictions

[Nathan]

Anne van Kesteren wrote:

http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html

And although it might end up being part of the Content Security Policy 
work I think it would be useful if publish a Working Draft of this work 
to gather more input, committing us nothing.


What do you think?


Half way there, I don't follow why a line of js invokes an "everything 
cross-origin blocked by default" security model, and a line of html 
invokes an "everything allowed by default" security model. Nor do I 
follow why "origin" isn't just sent as standard with every request and 
access controlled by the server based on origin (rather than controlled 
only "by user agents which choose to follow the specs" offering an 
artificial screen).


However, on this specific draft, is there any chance you can move to a 
white-list/black-list model, where people can send either Allow-Origin 
or Deny-Origin, for instance in many scenarios I want to allow everyone 
except origins A and B who I know consistently "steal" bandwidth, or 
display my resources beside unsavoury ones.


Best,

Nathan

Re: Cross-Origin Resource Embedding Restrictions

[=JeffH]

Adam wrote:
>
> There's been a bunch of discussion on the public-web-security mailing
> list about the scope of CSP.  Some folks think that CSP should be a
> narrow feature targeted at mitigating cross-site scripting.  Other
> folks (e.g., as articulated in
> ) would like to see CSP be
> more of a one-stop shop for configuring security-relevant policy for a
> web site.

Well, to be clear, we (AndyS and I) aren't calling (in the above-cited paper) 
for CSP per se to address all use cases -- rather, we see it as a non-trivial 
piece of necessarily multi-faceted approach to crafting a more coherent 
approach to web application security.


That said, we do feel that attenuation of the growth of the number of distinct 
http header fields would probably be a good thing, which would auger for trying 
to figure out how, e.g., CSP might address this use case.


=JeffH

Re: Cross-Origin Resource Embedding Restrictions

[Brandon Sterne]

I do think Content Security Policy offers a good opportunity to address
the use cases Anne brought up.

CSP already has a directive, frame-ancestors, that restricts the context
in which a resource can be embedded as a ,  or 
to a list of origins.  Perhaps we should expand the scope of the
directive to include other elements (and change the directive name to
something less frame-centric).

I'd personally support such a change.

-Brandon


On 03/01/2011 12:32 AM, Adam Barth wrote:
> +dveditz and +bsterne because they have strong opinions about CSP.
> 
> Adam
> 
> 
> On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth  wrote:
>> On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak  wrote:
>>> For what it's worth, I think this is a useful draft and a useful 
>>> technology. Hotlinking prevention is of considerable interest to Web 
>>> developers, and doing it via server-side Referer checks is inconvenient and 
>>> error-prone. I hope we can fit it into Web Apps WG, or if not, find another 
>>> goo home for it at the W3C.
>>>
>>> One thing I am not totally clear on is how this would fit into CSP. A big 
>>> focus for CSP is to enable site X to have a policy that prevents it from 
>>> accidentally including scripts from site Y, and things of that nature. In 
>>> other words, voluntarily limit the embedding capabilities of site X itself 
>>> But the desired feature is kind of the opposite of that. I think it would 
>>> be confusing to stretch CSP to this use case, much as it would have been 
>>> confusing to reuse CORS for this purpose.
>>
>> There's been a bunch of discussion on the public-web-security mailing
>> list about the scope of CSP.  Some folks think that CSP should be a
>> narrow feature targeted at mitigating cross-site scripting.  Other
>> folks (e.g., as articulated in
>> ) would like to see CSP be
>> more of a one-stop shop for configuring security-relevant policy for a
>> web site.
>>
>> From-Origin is closely related to one of the proposed CSP features,
>> namely frame-ancestors, which also controls how the given resource can
>> be embedded in other documents:
>>
>> https://wiki.mozilla.org/Security/CSP/Specification
>>
>> Aside from the aesthetic questions, I'd imagine folks will want to
>> include a list of permissible origins in the From-Origin header (or
>> else they'd have to give up caching their resources).  CSP already has
>> syntax, semantics, and processing models for lists of origins,
>> including wildcards.  At a minimum, we wouldn't want to create a
>> gratuitously different syntax for the same thing.
>>
>> Adam
>>
>>
>>> On Feb 28, 2011, at 11:35 PM, Anne van Kesteren wrote:
 The WebFonts WG is looking for a way to prevent cross-origin embedding of 
 fonts as certain font vendors want to license their fonts with such a 
 restriction. Some people think CORS is appropriate for this, some don't. 
 Here is some background material:

 http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
 http://annevankesteren.nl/2011/02/web-platform-consistency
 http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html


 More generally, having a way to prevent cross-origin embedding of 
 resources can be useful. In addition to license enforcement it can help 
 with:

 * Bandwidth "theft"
 * Clickjacking
 * Privacy leakage

 To that effect I wrote up a draft that complements CORS. Rather than 
 enabling sharing of resources, it allows for denying the sharing of 
 resources:

 http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html

 And although it might end up being part of the Content Security Policy 
 work I think it would be useful if publish a Working Draft of this work to 
 gather more input, committing us nothing.

 What do you think?

 Kind regards,


 --
 Anne van Kesteren
 http://annevankesteren.nl/

>>>
>>>
>>>
>>

Re: Cross-Origin Resource Embedding Restrictions

[Adam Barth]

+dveditz and +bsterne because they have strong opinions about CSP.

Adam


On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth  wrote:
> On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak  wrote:
>> For what it's worth, I think this is a useful draft and a useful technology. 
>> Hotlinking prevention is of considerable interest to Web developers, and 
>> doing it via server-side Referer checks is inconvenient and error-prone. I 
>> hope we can fit it into Web Apps WG, or if not, find another goo home for it 
>> at the W3C.
>>
>> One thing I am not totally clear on is how this would fit into CSP. A big 
>> focus for CSP is to enable site X to have a policy that prevents it from 
>> accidentally including scripts from site Y, and things of that nature. In 
>> other words, voluntarily limit the embedding capabilities of site X itself 
>> But the desired feature is kind of the opposite of that. I think it would be 
>> confusing to stretch CSP to this use case, much as it would have been 
>> confusing to reuse CORS for this purpose.
>
> There's been a bunch of discussion on the public-web-security mailing
> list about the scope of CSP.  Some folks think that CSP should be a
> narrow feature targeted at mitigating cross-site scripting.  Other
> folks (e.g., as articulated in
> ) would like to see CSP be
> more of a one-stop shop for configuring security-relevant policy for a
> web site.
>
> From-Origin is closely related to one of the proposed CSP features,
> namely frame-ancestors, which also controls how the given resource can
> be embedded in other documents:
>
> https://wiki.mozilla.org/Security/CSP/Specification
>
> Aside from the aesthetic questions, I'd imagine folks will want to
> include a list of permissible origins in the From-Origin header (or
> else they'd have to give up caching their resources).  CSP already has
> syntax, semantics, and processing models for lists of origins,
> including wildcards.  At a minimum, we wouldn't want to create a
> gratuitously different syntax for the same thing.
>
> Adam
>
>
>> On Feb 28, 2011, at 11:35 PM, Anne van Kesteren wrote:
>>> The WebFonts WG is looking for a way to prevent cross-origin embedding of 
>>> fonts as certain font vendors want to license their fonts with such a 
>>> restriction. Some people think CORS is appropriate for this, some don't. 
>>> Here is some background material:
>>>
>>> http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
>>> http://annevankesteren.nl/2011/02/web-platform-consistency
>>> http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html
>>>
>>>
>>> More generally, having a way to prevent cross-origin embedding of resources 
>>> can be useful. In addition to license enforcement it can help with:
>>>
>>> * Bandwidth "theft"
>>> * Clickjacking
>>> * Privacy leakage
>>>
>>> To that effect I wrote up a draft that complements CORS. Rather than 
>>> enabling sharing of resources, it allows for denying the sharing of 
>>> resources:
>>>
>>> http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
>>>
>>> And although it might end up being part of the Content Security Policy work 
>>> I think it would be useful if publish a Working Draft of this work to 
>>> gather more input, committing us nothing.
>>>
>>> What do you think?
>>>
>>> Kind regards,
>>>
>>>
>>> --
>>> Anne van Kesteren
>>> http://annevankesteren.nl/
>>>
>>
>>
>>
>

Re: Cross-Origin Resource Embedding Restrictions

[Adam Barth]

On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak  wrote:
> For what it's worth, I think this is a useful draft and a useful technology. 
> Hotlinking prevention is of considerable interest to Web developers, and 
> doing it via server-side Referer checks is inconvenient and error-prone. I 
> hope we can fit it into Web Apps WG, or if not, find another goo home for it 
> at the W3C.
>
> One thing I am not totally clear on is how this would fit into CSP. A big 
> focus for CSP is to enable site X to have a policy that prevents it from 
> accidentally including scripts from site Y, and things of that nature. In 
> other words, voluntarily limit the embedding capabilities of site X itself 
> But the desired feature is kind of the opposite of that. I think it would be 
> confusing to stretch CSP to this use case, much as it would have been 
> confusing to reuse CORS for this purpose.

There's been a bunch of discussion on the public-web-security mailing
list about the scope of CSP.  Some folks think that CSP should be a
narrow feature targeted at mitigating cross-site scripting.  Other
folks (e.g., as articulated in
) would like to see CSP be
more of a one-stop shop for configuring security-relevant policy for a
web site.

From-Origin is closely related to one of the proposed CSP features,
namely frame-ancestors, which also controls how the given resource can
be embedded in other documents:

https://wiki.mozilla.org/Security/CSP/Specification

Aside from the aesthetic questions, I'd imagine folks will want to
include a list of permissible origins in the From-Origin header (or
else they'd have to give up caching their resources).  CSP already has
syntax, semantics, and processing models for lists of origins,
including wildcards.  At a minimum, we wouldn't want to create a
gratuitously different syntax for the same thing.

Adam


> On Feb 28, 2011, at 11:35 PM, Anne van Kesteren wrote:
>> The WebFonts WG is looking for a way to prevent cross-origin embedding of 
>> fonts as certain font vendors want to license their fonts with such a 
>> restriction. Some people think CORS is appropriate for this, some don't. 
>> Here is some background material:
>>
>> http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
>> http://annevankesteren.nl/2011/02/web-platform-consistency
>> http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html
>>
>>
>> More generally, having a way to prevent cross-origin embedding of resources 
>> can be useful. In addition to license enforcement it can help with:
>>
>> * Bandwidth "theft"
>> * Clickjacking
>> * Privacy leakage
>>
>> To that effect I wrote up a draft that complements CORS. Rather than 
>> enabling sharing of resources, it allows for denying the sharing of 
>> resources:
>>
>> http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
>>
>> And although it might end up being part of the Content Security Policy work 
>> I think it would be useful if publish a Working Draft of this work to gather 
>> more input, committing us nothing.
>>
>> What do you think?
>>
>> Kind regards,
>>
>>
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>>
>
>
>

Re: Cross-Origin Resource Embedding Restrictions

[Maciej Stachowiak]

For what it's worth, I think this is a useful draft and a useful technology. 
Hotlinking prevention is of considerable interest to Web developers, and doing 
it via server-side Referer checks is inconvenient and error-prone. I hope we 
can fit it into Web Apps WG, or if not, find another goo home for it at the W3C.

One thing I am not totally clear on is how this would fit into CSP. A big focus 
for CSP is to enable site X to have a policy that prevents it from accidentally 
including scripts from site Y, and things of that nature. In other words, 
voluntarily limit the embedding capabilities of site X itself But the desired 
feature is kind of the opposite of that. I think it would be confusing to 
stretch CSP to this use case, much as it would have been confusing to reuse 
CORS for this purpose.

Regards,
Maciej

On Feb 28, 2011, at 11:35 PM, Anne van Kesteren wrote:

> Hi,
> 
> The WebFonts WG is looking for a way to prevent cross-origin embedding of 
> fonts as certain font vendors want to license their fonts with such a 
> restriction. Some people think CORS is appropriate for this, some don't. Here 
> is some background material:
> 
> http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
> http://annevankesteren.nl/2011/02/web-platform-consistency
> http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html
> 
> 
> More generally, having a way to prevent cross-origin embedding of resources 
> can be useful. In addition to license enforcement it can help with:
> 
> * Bandwidth "theft"
> * Clickjacking
> * Privacy leakage
> 
> To that effect I wrote up a draft that complements CORS. Rather than enabling 
> sharing of resources, it allows for denying the sharing of resources:
> 
> http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
> 
> And although it might end up being part of the Content Security Policy work I 
> think it would be useful if publish a Working Draft of this work to gather 
> more input, committing us nothing.
> 
> What do you think?
> 
> Kind regards,
> 
> 
> -- 
> Anne van Kesteren
> http://annevankesteren.nl/
> 

Cross-Origin Resource Embedding Restrictions

[Anne van Kesteren]

Hi,

The WebFonts WG is looking for a way to prevent cross-origin embedding of  
fonts as certain font vendors want to license their fonts with such a  
restriction. Some people think CORS is appropriate for this, some don't.  
Here is some background material:


http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
http://annevankesteren.nl/2011/02/web-platform-consistency
http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html


More generally, having a way to prevent cross-origin embedding of  
resources can be useful. In addition to license enforcement it can help  
with:


 * Bandwidth "theft"
 * Clickjacking
 * Privacy leakage

To that effect I wrote up a draft that complements CORS. Rather than  
enabling sharing of resources, it allows for denying the sharing of  
resources:


http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html

And although it might end up being part of the Content Security Policy  
work I think it would be useful if publish a Working Draft of this work to  
gather more input, committing us nothing.


What do you think?

Kind regards,


--
Anne van Kesteren
http://annevankesteren.nl/