Re: Cross-Origin Resource Embedding Restrictions

2011-03-01 Thread Adam Barth
On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak m...@apple.com 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
http://w2spconf.com/2010/papers/p11.pdf) 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

2011-03-01 Thread Adam Barth
+dveditz and +bsterne because they have strong opinions about CSP.

Adam


On Tue, Mar 1, 2011 at 12:26 AM, Adam Barth w...@adambarth.com wrote:
 On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak m...@apple.com 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
 http://w2spconf.com/2010/papers/p11.pdf) 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

2011-03-01 Thread 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 iframe, frame or object
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 w...@adambarth.com wrote:
 On Mon, Feb 28, 2011 at 11:57 PM, Maciej Stachowiak m...@apple.com 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
 http://w2spconf.com/2010/papers/p11.pdf) 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

2011-03-01 Thread =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
 http://w2spconf.com/2010/papers/p11.pdf) 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

2011-03-01 Thread 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

2011-03-01 Thread Glenn Maynard
On Tue, Mar 1, 2011 at 3:33 PM, Nathan nat...@webr3.org 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

2011-03-01 Thread Nathan

Glenn Maynard wrote:

On Tue, Mar 1, 2011 at 3:33 PM, Nathan nat...@webr3.org 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

2011-03-01 Thread 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



Cross-Origin Resource Embedding Restrictions

2011-02-28 Thread 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/



Re: Cross-Origin Resource Embedding Restrictions

2011-02-28 Thread 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/