Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Content Security Policy - final call for comments

27 views
Skip to first unread message

Brandon Sterne

unread,
Apr 2, 2009, 5:12:42 PM4/2/09
to
Hello all,

We have been working hard lately to finish documenting the Content
Security Policy proposal, which we plan to start implementing very
soon. For those of you who have followed the progression of CSP, you
have seen the model grow quite a bit in complexity. As one thinks
through the CSP model, it becomes clear that a certain amount of
complexity is in fact necessary for the model to be useful. I have
done my best to describe the model and provide justification for the
various restrictions here:
http://people.mozilla.org/~bsterne/content-security-policy/details.html

We now have a specification document to work from (thanks, Sid!) and
it and other supporting docs can be found on the Mozilla Wiki:
https://wiki.mozilla.org/Security/CSP/Spec

If you have feedback that you would like to share regarding Content
Security Policy, please do so ASAP as the window for making changes to
the model will soon be closing.

Cheers,
Brandon

Florian Weimer

unread,
Apr 4, 2009, 1:39:54 PM4/4/09
to dev-se...@lists.mozilla.org
* Brandon Sterne:

> We now have a specification document to work from (thanks, Sid!) and
> it and other supporting docs can be found on the Mozilla Wiki:
> https://wiki.mozilla.org/Security/CSP/Spec

The policy does not say explicitly what happens to javascript:
hyperlinks and the on* event handlers.

You shouldn't use an X- header because it's going to stick around and
preventing standardization (see X-Complaints-To on Usenet).

Brandon Sterne

unread,
Apr 5, 2009, 1:38:14 PM4/5/09
to
On Apr 4, 10:39 am, Florian Weimer <f...@deneb.enyo.de> wrote:
> The policy does not say explicitly what happens to javascript:
> hyperlinks and the on* event handlers.

http://people.mozilla.org/~bsterne/content-security-policy/details.html#no-inline-script

> You shouldn't use an X- header because it's going to stick around and
> preventing standardization (see X-Complaints-To on Usenet).

I think an X-header makes sense for CSP at this point, since it is not
yet standardized. A standards group like W3C's public-webapps is
probably the right venue for that conversation to take place.

Gervase Markham

unread,
Apr 6, 2009, 6:56:00 AM4/6/09
to
Hi Brandon,

Thanks for your continued hard work on this.

Are we expecting to see some or all of this in Firefox 3.5, or Firefox-next?

On 02/04/09 22:12, Brandon Sterne wrote:
> If you have feedback that you would like to share regarding Content
> Security Policy, please do so ASAP as the window for making changes to
> the model will soon be closing.

Here are some comments on https://wiki.mozilla.org/Security/CSP/Spec. In
general, I think it's excellent :-)

- When might we see the "Refinements" section with the JS/eval changes?
Or is that the other document?

- "When both a X-Content-Security-Policy HTTP header and meta tag are
present, the intersection of the two policies is enforced; essentially,
the browser enforces the most *relaxed* policy satisfying both the
policies specified in the meta tag and header."

Surely you mean "strict", not "relaxed"? The example seems to show that
the resulting policy is more strict than either of the two source policies.

- What happens if a Report-URI encounters a redirect? We should say
specifically in the spec what we do, and I think we should honour it.
This would allow us to do "all reports must be sent to the same host
that served the protected content" while still allowing people to set it
up so that the logging server was a separate machine.

- Would it not be more flexible, with negligible change in
implementation complexity, to make report-uri multi-valued? We have to
support multiple values anyway.

- "but a declared (unexpanded) policy always has the "allow" directive."
I think you need to make it more clear that "allow" is mandatory. But
what was the logic behind making it so? Why not assume "allow *", which
is what browsers do in the absence of CSP anyway?

- The formal syntax uses "<host-expr-list>" but it's undefined in that
formal section. Is that intentional?

- Should there be a space or other separator in the middle of
"<allow-directive><directive-list>"?

- The Violation Report Sample has:
"<blocked-uri>some_image.png</blocked-uri>". Given that the directive
blocked was a "self" directive, I would expect some_image.png to be on
another host, and therefore for a full URI to be provided. (This is
vital for trying to find out who is behind the content injection.) What
have I missed?

And the other document
http://people.mozilla.org/~bsterne/content-security-policy/details.html:

- "policy-uri documents must be served with the MIME type
text/content-security-policy to be valid" This probably needs an "x-"
until we've registered it, which we should do before deployment. It's
not a complex process, I hear.

- "Hostname, including an optional leading wildcard, e.g. *.mozilla.org"
Does that include foo.bar.baz.mozilla.org? If so, we should say so
explicitly (in both docs).

Again, great work :-)

Gerv

Johnathan Nightingale

unread,
Apr 6, 2009, 12:17:07 PM4/6/09
to Gervase Markham, dev-se...@lists.mozilla.org

On 6-Apr-09, at 6:56 AM, Gervase Markham wrote:
> - "When both a X-Content-Security-Policy HTTP header and meta tag
> are present, the intersection of the two policies is enforced;
> essentially, the browser enforces the most *relaxed* policy
> satisfying both the policies specified in the meta tag and header."
>
> Surely you mean "strict", not "relaxed"? The example seems to show
> that the resulting policy is more strict than either of the two
> source policies.

I think "relaxed" is the intent here, within the context of "the most
relaxed policy *satisfying both* ... the meta tag and header." So the
intersection is more strict than either on its own, but no more strict
than that intersection. I agree that the wording is a bit confusing.

Cheers,

J

---
Johnathan Nightingale
Human Shield
joh...@mozilla.com

Sid Stamm

unread,
Apr 6, 2009, 12:51:58 PM4/6/09
to
On 4/6/09 9:17 AM, Johnathan Nightingale wrote:
> I think "relaxed" is the intent here, within the context of "the most
> relaxed policy *satisfying both* ... the meta tag and header." So the
> intersection is more strict than either on its own, but no more strict
> than that intersection. I agree that the wording is a bit confusing.

Yeah, that's correct. I must have been over-caffeinated when I wrote
that. Here is the new, hopefully clearer text:

"essentially, the browser enforces a policy that is more strict than
both the policies specified in the meta tag and header, but only strict
enough to correspond to rules in both policies. Any web request that
satisfied both policies alone will be accepted by the new policy, but
any request rejected by either one or both of the two policies will be
rejected."

I also put a kind of formal description following it in the wiki.
https://wiki.mozilla.org/Security/CSP/Spec#Policy_Refinements_with_a_META_Tag

-Sid

Sid Stamm

unread,
Apr 6, 2009, 1:12:49 PM4/6/09
to
On 4/6/09 3:56 AM, Gervase Markham wrote:
> - When might we see the "Refinements" section with the JS/eval changes?
> Or is that the other document?
The content is in the other document, but most likely we'll be moving
that to the wiki too (I've linked to the description doc in the mean time).

> - What happens if a Report-URI encounters a redirect? We should say
> specifically in the spec what we do, and I think we should honour it.
> This would allow us to do "all reports must be sent to the same host
> that served the protected content" while still allowing people to set it
> up so that the logging server was a separate machine.

Personally, I don't like the idea of honoring redirects for logging...
if a meta tag can be injected into a page (with a CSP header or not) and
the site hosts an open redirect, suddenly cookies can be stolen from all
visitors to a site.

> - Would it not be more flexible, with negligible change in
> implementation complexity, to make report-uri multi-valued? We have to
> support multiple values anyway.

While it's true that this would be easy to implement, I think we need to
set a limit. We don't want to spawn off 100 requests every time a
policy is violated. If that happens, attackers could leverage the
reporting mechanism in CSP to flood a network with traffic. I'm not
convinced that widespread use will demand more than two report URIs, and
it's not difficult to set up that report URI recipient service to fork
copies to multiple other destinations.

> - "but a declared (unexpanded) policy always has the "allow" directive."
> I think you need to make it more clear that "allow" is mandatory. But
> what was the logic behind making it so? Why not assume "allow *", which
> is what browsers do in the absence of CSP anyway?

I think the intention for requiring the allow directive was to force the
policy-writer into writing out the default case to minimize possibility
for false assumptions. I'm not sure though.

> - The formal syntax uses "<host-expr-list>" but it's undefined in that
> formal section. Is that intentional?

Nope... that's a mistake, should be "<source-list>".

> - Should there be a space or other separator in the middle of
> "<allow-directive><directive-list>"?

Indeed. ";"

> - The Violation Report Sample has:
> "<blocked-uri>some_image.png</blocked-uri>". Given that the directive
> blocked was a "self" directive, I would expect some_image.png to be on
> another host, and therefore for a full URI to be provided. (This is
> vital for trying to find out who is behind the content injection.) What
> have I missed?

You're right, a full URI would be appropriate there. The wiki was
actually parsing out the http://evil.com/ part from both references to
"some_image.png" and omitting it... weird.

Thanks for the comments!
-Sid

Brandon Sterne

unread,
Apr 6, 2009, 7:52:28 PM4/6/09
to
Hi, Gerv. Thanks a lot for your comments. I'll address the comments
that weren't already covered by Johnathan or Sid, both of whom I agree
with.

On Apr 6, 3:56 am, Gervase Markham <g...@mozilla.org> wrote:
> Are we expecting to see some or all of this in Firefox 3.5, or Firefox-next?

Firefox-next.

> - "but a declared (unexpanded) policy always has the "allow" directive."
> I think you need to make it more clear that "allow" is mandatory. But
> what was the logic behind making it so? Why not assume "allow *", which
> is what browsers do in the absence of CSP anyway?

Sid did address this one, but I want to be clear in the rationale.
Once we see the Content Security Policy header (or meta tag), we want
to force sites to be explicit about what they are allowing. Yes,
"allow *" is the default browser behavior without CSP presently, but
we want to avoid cases where sites assume the default behavior of CSP
is more restrictive than it actually is. I could envision, for
example, a site presuming that "allow none" or "allow self" was the
default, and that additional policy could be specified from there. If
a site really wants to "allow *", then we want them to explicitly
state that.

> And the other document
> http://people.mozilla.org/~bsterne/content-security-policy/details.html:
>
> - "policy-uri documents must be served with the MIME type
> text/content-security-policy to be valid" This probably needs an "x-"
> until we've registered it, which we should do before deployment. It's
> not a complex process, I hear.

That sounds fair. I'll update the document with that change.

> - "Hostname, including an optional leading wildcard, e.g. *.mozilla.org"
> Does that include foo.bar.baz.mozilla.org? If so, we should say so
> explicitly (in both docs).

That's true too. I'll make the language more clear.

Cheers,
Brandon

Daniel Veditz

unread,
Apr 7, 2009, 2:36:02 AM4/7/09
to Gervase Markham
Gervase Markham wrote:
> - "but a declared (unexpanded) policy always has the "allow" directive."
> I think you need to make it more clear that "allow" is mandatory. But
> what was the logic behind making it so? Why not assume "allow *", which
> is what browsers do in the absence of CSP anyway?

"allow" is not mandatory, but if missing it's assumed to be "allow
none". If you explicitly specify the whitelisted hosts for each type of
load you might not need or want a global fallback which could only be
used to sneak through types you hadn't thought about. Future browser
features, for instance.

Maybe this does point out the need for some kind of version number in
the header, so future browsers can take appropriate action when
encountering an old header. For example, assuming "none" for any newly
added types.

> - "policy-uri documents must be served with the MIME type
> text/content-security-policy to be valid" This probably needs an "x-"
> until we've registered it, which we should do before deployment. It's
> not a complex process, I hear.

Until we get CSP onto a standards track they'd probably want us to use a
text/vnd.mozilla.something, and since we'd like other browsers to
support this I vote we go for the "x-" for now.

Florian Weimer

unread,
Apr 7, 2009, 3:52:25 AM4/7/09
to dev-se...@lists.mozilla.org
* Brandon Sterne:

> On Apr 4, 10:39 am, Florian Weimer <f...@deneb.enyo.de> wrote:
>> The policy does not say explicitly what happens to javascript:
>> hyperlinks and the on* event handlers.
>
> http://people.mozilla.org/~bsterne/content-security-policy/details.html#no-inline-script

Uhm, I meant to say, it's not in the spec.

Gervase Markham

unread,
Apr 7, 2009, 7:01:42 AM4/7/09
to
On 06/04/09 18:12, Sid Stamm wrote:
> Personally, I don't like the idea of honoring redirects for logging...
> if a meta tag can be injected into a page (with a CSP header or not) and
> the site hosts an open redirect, suddenly cookies can be stolen from all
> visitors to a site.

Surely not? If Site Angelic redirects to Site Be-Evil, We don't send
Angelic's cookies to Be-Evil, do we? Or have I missed something? You may
need to describe the attack scenario in more detail for my small brain.

> While it's true that this would be easy to implement, I think we need to
> set a limit. We don't want to spawn off 100 requests every time a policy
> is violated. If that happens, attackers could leverage the reporting
> mechanism in CSP to flood a network with traffic.

But are there not easier ways of doing this - injecting <img> tags for
100 images on the target server, for example? Given that the reports are
so small, I can't see how anyone would want to use it as a DOS mechanism.

We should set a limit. I'm just wondering whether "2" is the most
convenient limit.

> I'm not convinced that
> widespread use will demand more than two report URIs, and it's not
> difficult to set up that report URI recipient service to fork copies to
> multiple other destinations.

True. It's not a big deal.

> I think the intention for requiring the allow directive was to force the
> policy-writer into writing out the default case to minimize possibility
> for false assumptions. I'm not sure though.

Fair enough. As long as the JS console/error report says something
sensible if it's missing.

Gerv

Gervase Markham

unread,
Apr 7, 2009, 7:07:39 AM4/7/09
to Daniel Veditz
On 07/04/09 07:36, Daniel Veditz wrote:
> Maybe this does point out the need for some kind of version number in
> the header, so future browsers can take appropriate action when
> encountering an old header. For example, assuming "none" for any newly
> added types.

I much prefer forwardly-compatible designs to version numbers. I think
the current design is forwardly-compatible, as long as we maintain a
well-signposted public page listing which category all sorts of request
fall into, and add new request types well before they get implemented by
anyone.

For example, if a <3dvideo> tag, for which you needed red-blue glasses,
made it into a draft HTML5 spec, we would decide and say loudly that
this was included in "media-src" well before anyone actually implemented it.

Can you suggest a scenario in which version numbers would help?

Gerv

Gervase Markham

unread,
Apr 7, 2009, 7:25:26 AM4/7/09
to
On 02/04/09 22:12, Brandon Sterne wrote:
> We have been working hard lately to finish documenting the Content
> Security Policy proposal,

What's the story on inline <style> and style=""? At the moment the
definition of "style-src" says they are subject to it, but there's no
valid value for "in this document", and in the script case, all inline
script is disabled.

Have we decided that there's a risk with all inline CSS style, or can we
define and enforce a large safe subset of the language? Making people
move their JS to external files is one thing, making them move all the
style as well is yet another.

Gerv

Sid Stamm

unread,
Apr 7, 2009, 11:28:03 AM4/7/09
to
On 4/7/09 4:01 AM, Gervase Markham wrote:
> Surely not? If Site Angelic redirects to Site Be-Evil, We don't send
> Angelic's cookies to Be-Evil, do we? Or have I missed something? You may
> need to describe the attack scenario in more detail for my small brain.
Since the user's entire request header is in the report, any cookies
sent with the request header to Angelic get forwarded on. While Be-Evil
doesn't actually get forwarded cookies, the cookies are buried in the
content of the report that is forwarded under the <request-headers> field.

>> I think the intention for requiring the allow directive was to force the
>> policy-writer into writing out the default case to minimize possibility
>> for false assumptions. I'm not sure though.
>
> Fair enough. As long as the JS console/error report says something
> sensible if it's missing.

Of course. Any forgivable but bad policy syntax is going to be spat
into the error console. Terminal ("can't parse") errors will cause CSP
to fail closed ("allow self") and still raise an error.

-Sid

Brandon Sterne

unread,
Apr 7, 2009, 12:08:43 PM4/7/09
to dev-se...@lists.mozilla.org
On 4/7/09 4:25 AM, Gervase Markham wrote:
> What's the story on inline <style> and style=""? At the moment the
> definition of "style-src" says they are subject to it, but there's no
> valid value for "in this document", and in the script case, all inline
> script is disabled.

As you mentioned, the style-src section indicates "...as well as inline
<style> elements and style attributes of HTML elements." We are
basically treating CSS in the same manner as JavaScript.

> Have we decided that there's a risk with all inline CSS style, or can we
> define and enforce a large safe subset of the language? Making people
> move their JS to external files is one thing, making them move all the
> style as well is yet another.

Since style is a vector for JavaScript, via XBL, it needs to be subject
to the same restrictions.

-Brandon

Brandon Sterne

unread,
Apr 7, 2009, 12:22:19 PM4/7/09
to dev-se...@lists.mozilla.org
On 4/6/09 11:36 PM, Daniel Veditz wrote:
> "allow" is not mandatory, but if missing it's assumed to be "allow
> none". If you explicitly specify the whitelisted hosts for each type of
> load you might not need or want a global fallback which could only be
> used to sneak through types you hadn't thought about. Future browser
> features, for instance.

Not according to our proposed spec:
https://wiki.mozilla.org/Security/CSP/Spec#Directives
http://people.mozilla.org/~bsterne/content-security-policy/details.html#allow

See comments from me and Sid from yesterday explaining why allow is
required.

I somewhat agree with the spirit of Dan's comment. If allow is not
specified, then the _effect_ is to allow none, because the policy is
invalid and CSP will fail closed. However, strictly speaking, we don't
assume allow none if it isn't specified. We will treat that as invalid
policy, logging an error, and not loading any of the content types.

By falling back to "allow none" when invalid policy is sent, websites
will know right away that their pages are broken because no content,
other than textual elements will load. This is a more secure option
than failing open and having websites potentially believe their users
are protected.

-Brandon

Bil Corry

unread,
Apr 7, 2009, 12:42:57 PM4/7/09
to dev-se...@lists.mozilla.org
Gervase Markham wrote on 4/7/2009 6:07 AM:
> On 07/04/09 07:36, Daniel Veditz wrote:
>> Maybe this does point out the need for some kind of version number in
>> the header, so future browsers can take appropriate action when
>> encountering an old header. For example, assuming "none" for any newly
>> added types.
>
> I much prefer forwardly-compatible designs to version numbers.

It has to work both ways; old CSP clients need to be able to parse new CSP rules that are unknown to them and new CSP clients need to be able to parse old CSP rules. Where it will become a challenge is anytime something implicit has its meaning changed (e.g. the default is "x" in CSPv1 and "y" in CSPv2).


- Bil

Brandon Sterne

unread,
Apr 7, 2009, 1:02:12 PM4/7/09
to dev-se...@lists.mozilla.org
On 4/7/09 4:07 AM, Gervase Markham wrote:
> I much prefer forwardly-compatible designs to version numbers. I think
> the current design is forwardly-compatible, as long as we maintain a
> well-signposted public page listing which category all sorts of request
> fall into, and add new request types well before they get implemented by
> anyone.
>
> For example, if a <3dvideo> tag, for which you needed red-blue glasses,
> made it into a draft HTML5 spec, we would decide and say loudly that
> this was included in "media-src" well before anyone actually implemented
> it.
>
> Can you suggest a scenario in which version numbers would help?

I think the case for including a version number goes something like this
(and strong advocates, please chime in if I miss something):

1. Bugs may be present in the CSP design which require future
compatibility breakage. These obviously cannot be foreseen and, though
we desire it, we can't guarantee forward compatibility.

2. New types of content (per your example) or new web APIs may be added
in the future which don't shoehorn nicely into one of our current policy
buckets. If we have to add another policy directive in the future, then
it will violate the policy syntax in older versions which will cause
them to fail closed (according to the current design).

3. We arguably want to have a pref for users to turn off CSP (for
testing or otherwise). It would be useful to have the version number
available as a means to communicate to the site that, even though the
client supports CSP by default, CSP has been disabled on this client.

I looked at each of the HTTP Header Field Definitions and my preference
for communicating the CSP version is to add a product token [1] to the
User-Agent [2] string. This would add only a few bytes to the U-A and
it saves us the trouble of having to go through IETF processes of
creating a new request header.

Thoughts?

-Brandon

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43


Brandon Sterne

unread,
Apr 7, 2009, 3:27:16 PM4/7/09
to dev-se...@lists.mozilla.org
On 4/7/09 9:08 AM, Brandon Sterne wrote:
>> Have we decided that there's a risk with all inline CSS style, or can we
>> define and enforce a large safe subset of the language? Making people
>> move their JS to external files is one thing, making them move all the
>> style as well is yet another.
>
> Since style is a vector for JavaScript, via XBL, it needs to be subject
> to the same restrictions.

Actually, my reasoning is wrong here.

Style is no longer a vector for script under CSP because we added the
restriction that "XBL bindings must come from chrome: or resource: URIs"
for precisely this reason.

The other reason to make inline CSS subject to the style-src directive
(which I didn't state before because it didn't seem as strong a point)
is increased consistency in the model. It seems inconsistent to offer
controls on where style can come from if the restriction can be bypassed
by injecting CSS directly into the document. Granted, injected CSS
poses a much, much lower risk than injected script, but there is still
the issue of page defacement, etc.

I don't think the no-inline-style requirement is too punitive, though,
as sites can still use normal CSS selectors and apply their styles from
external, white-listed stylesheets.

Sorry for the confusion.

-Brandon

Bil Corry

unread,
Apr 7, 2009, 4:40:14 PM4/7/09
to dev-se...@lists.mozilla.org
Brandon Sterne wrote on 4/7/2009 12:02 PM:
> I looked at each of the HTTP Header Field Definitions and my preference
> for communicating the CSP version is to add a product token [1] to the
> User-Agent [2] string. This would add only a few bytes to the U-A and
> it saves us the trouble of having to go through IETF processes of
> creating a new request header.

I agree that creating a request header for just the CSP version is overkill. However, I am concerned that privacy add-ons, proxies, firewalls, etc may strip or replace the User-Agent string.

I propose a new request header is created, but instead of one that is specific to CSP, it is something more generic that can be used in the future by similar policy frameworks.

For example:

Accept-Header: X-Content-Security-Policy version=2 securityLevel=2; X-Application-Boundaries-Enforcer type=browser


FWIW, "X-Application-Boundaries-Enforcer" refers to ABE: http://hackademix.net/2008/12/20/introducing-abe/

I originally came up with Accept-Header during a conversation about revising the Cookie specification; it would alert the server that the client understood "version 3" of cookies:

Accept-Header: Set-Cookie version=3

So it does have a variety of uses that may make it worth the effort to register and define.


- Bil


Gervase Markham

unread,
Apr 8, 2009, 2:57:40 PM4/8/09
to
On 07/04/09 16:28, Sid Stamm wrote:
> Since the user's entire request header is in the report, any cookies
> sent with the request header to Angelic get forwarded on. While Be-Evil
> doesn't actually get forwarded cookies, the cookies are buried in the
> content of the report that is forwarded under the <request-headers> field.

OK. Then we need to spec that redirects are not honoured.

Gerv

Gervase Markham

unread,
Apr 8, 2009, 2:58:44 PM4/8/09
to
On 07/04/09 16:28, Sid Stamm wrote:
> Since the user's entire request header is in the report, any cookies
> sent with the request header to Angelic get forwarded on. While Be-Evil
> doesn't actually get forwarded cookies, the cookies are buried in the
> content of the report that is forwarded under the <request-headers> field.

... (following on from previous message) or we need to say that sites
with open redirects are already broken, and this is just another
symptom, and we should support redirects for the convenience and reduced
implementation complexity.

Gerv

Gervase Markham

unread,
Apr 8, 2009, 3:07:40 PM4/8/09
to
On 07/04/09 18:02, Brandon Sterne wrote:
> 1. Bugs may be present in the CSP design which require future
> compatibility breakage. These obviously cannot be foreseen and, though
> we desire it, we can't guarantee forward compatibility.

There are two sorts of possible breakage - syntax and functional. I
can't see us needing to throw away the syntax and, if we did, we'd just
define a new header. So no issues there. And functional breakage comes
into your second category anyway.

> 2. New types of content (per your example) or new web APIs may be added
> in the future which don't shoehorn nicely into one of our current policy
> buckets. If we have to add another policy directive in the future, then
> it will violate the policy syntax in older versions which will cause
> them to fail closed (according to the current design).

But the old browsers also won't support the new APIs/whatever. If we add
a <3dcanvas> element to Firefox and control it with 3dcanvas-src, then
old browsers won't understand the element, and so ignore it. And so if
the browser didn't understand 3dcanvas-src either, that's no big deal.

CSP should specify that unknown directives are ignored. That's a fairly
common way to deal with this problem (CSS, HTML etc.).

The only problem would be if an existing browser feature acquires
specific restrictions when it used to be covered by "all". In that case,
users of old browsers would get less protection - but they had that
anyway, because their CSP implementation doesn't support the extra
restriction.

> 3. We arguably want to have a pref for users to turn off CSP (for
> testing or otherwise). It would be useful to have the version number
> available as a means to communicate to the site that, even though the
> client supports CSP by default, CSP has been disabled on this client.

Why is that useful information?

I'm actually against making it easy for servers to "detect" if CSP is
supported, because if we make it particularly easy, content authors will
start relying on it as their only defence rather than using it as a
backup. "We don't need to check for XSS holes, we use CSP." That would
be bad. Of course, we can't stop them putting together fragile
User-Agent lists, but sites which do that are broken anyway, as the web
design community has been saying for years.

> I looked at each of the HTTP Header Field Definitions and my preference
> for communicating the CSP version is to add a product token [1] to the
> User-Agent [2] string. This would add only a few bytes to the U-A and
> it saves us the trouble of having to go through IETF processes of
> creating a new request header.

I'd much rather have a "\d+;" at the start of the header. Missing
implies version 1.

Gerv

Bil Corry

unread,
Apr 8, 2009, 3:45:23 PM4/8/09
to dev-se...@lists.mozilla.org
Gervase Markham wrote on 4/8/2009 2:07 PM:
> On 07/04/09 18:02, Brandon Sterne wrote:
> I'm actually against making it easy for servers to "detect" if CSP is
> supported, because if we make it particularly easy, content authors will
> start relying on it as their only defence rather than using it as a
> backup. "We don't need to check for XSS holes, we use CSP." That would
> be bad. Of course, we can't stop them putting together fragile
> User-Agent lists, but sites which do that are broken anyway, as the web
> design community has been saying for years.

It seems unlikely that responsible web developers would rely entirely on CSP, especially initially, since not all UAs will support it. And if the developer really does choose to rely entirely on CSP, there isn't much we can do -- any developer with two domains can easily test if the client supports CSP, request header or no header.

I think the stronger likelihood is that the developer won't use CSP at all -- their site will still work regardless. Providing a CSP header that can be measured to show it's worth the effort to learn and implement will be a much stronger incentive.

In summary, given the number of XSS holes out there, if the developer chooses to rely entirely on CSP to protect them, that's far better than not using CSP at all. The biggest threat to CSP is not over-reliance, but rather under-utilization.


- Bil

Brandon Sterne

unread,
Apr 8, 2009, 4:49:17 PM4/8/09
to Gervase Markham, dev-se...@lists.mozilla.org
On 4/8/09 12:07 PM, Gervase Markham wrote:
> On 07/04/09 18:02, Brandon Sterne wrote:
>> 1. Bugs may be present in the CSP design which require future
>> compatibility breakage. These obviously cannot be foreseen and, though
>> we desire it, we can't guarantee forward compatibility.
>
> There are two sorts of possible breakage - syntax and functional. I
> can't see us needing to throw away the syntax and, if we did, we'd just
> define a new header. So no issues there. And functional breakage comes
> into your second category anyway.

Defining a new header seems like a non-starter to me. We are going to
be hard-pressed to get one new header standardized, so throwing one away
seems very wasteful.

>> 3. We arguably want to have a pref for users to turn off CSP (for
>> testing or otherwise). It would be useful to have the version number
>> available as a means to communicate to the site that, even though the
>> client supports CSP by default, CSP has been disabled on this client.
>
> Why is that useful information?

If sites are relying on CSP for XSS protection, then perhaps they would
want to serve only "trusted content" to non-CSP users.

> I'm actually against making it easy for servers to "detect" if CSP is
> supported, because if we make it particularly easy, content authors will
> start relying on it as their only defence rather than using it as a
> backup. "We don't need to check for XSS holes, we use CSP." That would
> be bad. Of course, we can't stop them putting together fragile
> User-Agent lists, but sites which do that are broken anyway, as the web
> design community has been saying for years.

In reality, as CSP becomes more mature and well-understood, sites will
rely on it for XSS mitigation. It's inevitable that if we put a
reliable product out there sites will rely upon it. CSP won't cause
input sanitization, etc. to be removed from Security Best Practices, but
it will be a standard part of the browser security model, I imagine.

>> I looked at each of the HTTP Header Field Definitions and my preference
>> for communicating the CSP version is to add a product token [1] to the
>> User-Agent [2] string. This would add only a few bytes to the U-A and
>> it saves us the trouble of having to go through IETF processes of
>> creating a new request header.
>
> I'd much rather have a "\d+;" at the start of the header. Missing
> implies version 1.

But our header is only sent as a response header, so would not be useful
for sending version info with client requests. We're somewhat averse to
adding a request header that would only carry the version info, so
that's why we're looking for an existing request header that can carry
this info.

-Brandon

Sid Stamm

unread,
Apr 8, 2009, 6:09:22 PM4/8/09
to
On 4/8/09 1:49 PM, Brandon Sterne wrote:
> If sites are relying on CSP for XSS protection, then perhaps they would
> want to serve only "trusted content" to non-CSP users.
Additionally, knowing the portion of users whose browsers enforce CSP
(and thus are benefiting from the minimal effort put into serving a CSP
header) might be an interesting metric that web admins can present to
their managers. ;)

-Sid

Gervase Markham

unread,
Apr 10, 2009, 10:06:17 AM4/10/09
to Brandon Sterne
On 08/04/09 21:49, Brandon Sterne wrote:
> Defining a new header seems like a non-starter to me. We are going to
> be hard-pressed to get one new header standardized, so throwing one away
> seems very wasteful.

As I said, I think the possibility of needing a breaking change in
syntax is tiny.

> If sites are relying on CSP for XSS protection, then perhaps they would
> want to serve only "trusted content" to non-CSP users.

If you have a mechanism for making content "trusted", why not use it all
the time? You don't turn off your HTML sanitizer for CSP-supporting
browsers.

> In reality, as CSP becomes more mature and well-understood, sites will
> rely on it for XSS mitigation. It's inevitable that if we put a
> reliable product out there sites will rely upon it.

But by design, it can't be entirely reliable, because it can't read the
developer's mind. Or have you got the ESP module working properly now? :-)

> But our header is only sent as a response header, so would not be useful
> for sending version info with client requests.

Yeah, duh. Not sure what I was thinking there. Sorry.

> We're somewhat averse to
> adding a request header that would only carry the version info, so
> that's why we're looking for an existing request header that can carry
> this info.

I really don't think UA is the right choice. Microsoft are bloating UAs
with .NET versions, and that's making people unhappy.

Gerv

Gervase Markham

unread,
Apr 10, 2009, 10:21:25 AM4/10/09
to
On 08/04/09 23:09, Sid Stamm wrote:
> Additionally, knowing the portion of users whose browsers enforce CSP
> (and thus are benefiting from the minimal effort put into serving a CSP
> header) might be an interesting metric that web admins can present to
> their managers. ;)

I don't think you need a CSP version number to get those stats. As
Brandon says, there are other ways to measure support if you really want to.

Gerv

Brandon Sterne

unread,
Apr 10, 2009, 11:46:05 AM4/10/09
to dev-se...@lists.mozilla.org, Gervase Markham
On 4/10/09 7:06 AM, Gervase Markham wrote:
>> If sites are relying on CSP for XSS protection, then perhaps they would
>> want to serve only "trusted content" to non-CSP users.
>
> If you have a mechanism for making content "trusted", why not use it all
> the time? You don't turn off your HTML sanitizer for CSP-supporting
> browsers.

I think the point is that sites won't have 100% confidence in their HTML
sanitizer. The HTML scrubber might have bugs, which CSP provides
mitigation for. This raises the confidence level to a point where sites
can be comfortable serving user-generated content, etc. because they
know there are policies limiting what that content can do.

>> In reality, as CSP becomes more mature and well-understood, sites will
>> rely on it for XSS mitigation. It's inevitable that if we put a
>> reliable product out there sites will rely upon it.
>
> But by design, it can't be entirely reliable, because it can't read the
> developer's mind. Or have you got the ESP module working properly now? :-)

Not reliable in the sense that "we guarantee there will never be XSS in
your site". I site can still write code with vulnerabilities even under
CSP. By reliable, I meant that the behavior will be consistent and
patterns of effective use for XSS mitigation will develop.

>> We're somewhat averse to
>> adding a request header that would only carry the version info, so
>> that's why we're looking for an existing request header that can carry
>> this info.
>
> I really don't think UA is the right choice. Microsoft are bloating UAs
> with .NET versions, and that's making people unhappy.

I'm not 100% thrilled with the idea either, mostly because parsing the
U-A string could be challenging for some sites. But it does seems to be
the least bad idea I've heard. We can certainly minimize U-A bloat by
making our subproduct something like "CSP/1". I'm certainly open to
other suggestions, though.

-Brandon

Bil Corry

unread,
Apr 10, 2009, 12:50:51 PM4/10/09
to Brandon Sterne, dev-se...@lists.mozilla.org, Gervase Markham
Brandon Sterne wrote on 4/10/2009 10:46 AM:
> I'm not 100% thrilled with the idea either, mostly because parsing the
> U-A string could be challenging for some sites. But it does seems to be
> the least bad idea I've heard. We can certainly minimize U-A bloat by
> making our subproduct something like "CSP/1". I'm certainly open to
> other suggestions, though.

I proposed an alternative earlier in the thread:

http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/c0f1a44e4fb98859#anchor_ffeba39158c82a91


- Bil

Sid Stamm

unread,
Apr 10, 2009, 1:32:55 PM4/10/09
to
On 4/10/09 9:50 AM, Bil Corry wrote:
> http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/c0f1a44e4fb98859#anchor_ffeba39158c82a91

While I do like the idea of an Accept-Header header for
capability-advertising uses, it's not yet implemented. And I fear if it
were implemented, it may encourage adding too many X-headers to the
request ... which is orthogonal to our goal in avoiding a new header for
CSP versioning. There's already tremendous pressure to keep the number
of HTTP headers low. If we were already sending Accept-Header, I'd jump
right on it as a place to put the CSP version, but I don't really think
it's wise to add this new header with only CSP using it for now.

If we advertise the version at all (I'm still on the fence here), I
think maybe putting CSP version into the User-Agent header might be
appropriate, since CSP is technically a capability of the user agent.
http://tools.ietf.org/html/rfc2616#section-14.43

If indeed the UA gets scrubbed by someone concerned about privacy (or a
proxy/firewall/etc), it seems appropriate that this advertisement of a
user-agent's capability (the CSP version) should get scrubbed too.

So the UA string is harder to parse than a header containing only this
version, but the syntax is fairly straightforward in RFC 2616. Also,
I'm not seeing a Flash-Version header, or a header that alone advertises
any other browser capabilities, so unless we want to make a new header
and put *all* advertised capabilities in it, User-Agent seems the best
choice.

Cheers,
Sid

Lucas Adamski

unread,
Apr 10, 2009, 9:04:34 PM4/10/09
to Gervase Markham, dev-se...@lists.mozilla.org
That depends on your definition of reliable. CSP not a panacea, but
it is expected to be able to enforce a set of restrictions that are
reliable. Reliability is an aspect of any feature in the browser I
image so its not like we can dodge that. To rely on those particular
restrictions sites will have to try to determine if the UA supports
it, which it will try to do (poorly) by mapping UA versions to CSP
support.

I don't mean to try to short circuit the conversation around this but
I feel like we've gone several rounds on versioning and I'm trying to
figure out if there are any additional issues we haven't already
discussed. If the major objection is that developers may some day
actually rely on CSP to provide a set of security mitigation then I
can honestly say that's a problem I'd be happy to have. Thanks,
Lucas.

Gervase Markham

unread,
Apr 15, 2009, 4:32:46 AM4/15/09
to Brandon Sterne
On 10/04/09 16:46, Brandon Sterne wrote:
> I'm not 100% thrilled with the idea either, mostly because parsing the
> U-A string could be challenging for some sites. But it does seems to be
> the least bad idea I've heard. We can certainly minimize U-A bloat by
> making our subproduct something like "CSP/1". I'm certainly open to
> other suggestions, though.

Why does the CSP technology get to advertise and version itself in this
way when no other technology the browser supports does? If we allow CSP
to send version information in every HTTP request, what other
technologies are going to want it? "I support <video>". "I support
HTML5". Etc. I think the slippery slope argument has validity here.

Why not start versioning when we reach version 2 (i.e. there are two
versions to distinguish), if that ever happens?

Gerv

Brandon Sterne

unread,
Apr 15, 2009, 11:32:39 AM4/15/09
to Gervase Markham, dev-se...@lists.mozilla.org
On 4/15/09 1:32 AM, Gervase Markham wrote:
> Why does the CSP technology get to advertise and version itself in this
> way when no other technology the browser supports does? If we allow CSP
> to send version information in every HTTP request, what other
> technologies are going to want it? "I support <video>". "I support
> HTML5". Etc. I think the slippery slope argument has validity here.

The support of <video> or HTML5 by a client does not have the same
security implications as the support of CSP. If a client does not
support <video> and a site serves it to them, there is no risk to the
client, which can passively ignore the <video> content. If a client
does not support CSP and a site serves them untrusted content, there is
a higher XSS risk to that client than to one which does support CSP.

> Why not start versioning when we reach version 2 (i.e. there are two
> versions to distinguish), if that ever happens?

Another benefit of the version string that we've discussed is the
ability for a client to signal that CSP is disabled presently (by
removing the string). In those cases, a site may want to restrict which
content is served to that client.

-Brandon

TO

unread,
Apr 16, 2009, 4:20:15 PM4/16/09
to
On Apr 2, 5:12 pm, Brandon Sterne <bste...@mozilla.com> wrote:
> For those of you who have followed the progression of CSP, you
> have seen the model grow quite a bit in complexity.  

I'd really like to see some real-world examples to illustrate how
complex this policy actually gets in practice. What would the policy
be for, say, CNN.com? What code changes would be necessary to make
the site continue to work with CSP?

Terri

Brandon Sterne

unread,
May 12, 2009, 2:21:42 PM5/12/09
to dev-se...@lists.mozilla.org
Based on feedback and resulting discussions, I think it is best that we
proceed with the User-Agent [1] product token [2] approach for CSP
versioning. It will only add ~5 bytes, e.g. CSP/1, to the U-A string
and will be easily parsable by servers. I am going to update the CSP
spec to reflect this addition.

Cheers,
Brandon

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8


On 4/10/09 10:32 AM, Sid Stamm wrote:
> If we advertise the version at all (I'm still on the fence here), I
> think maybe putting CSP version into the User-Agent header might be
> appropriate, since CSP is technically a capability of the user agent.
> http://tools.ietf.org/html/rfc2616#section-14.43
>
> If indeed the UA gets scrubbed by someone concerned about privacy (or a
> proxy/firewall/etc), it seems appropriate that this advertisement of a
> user-agent's capability (the CSP version) should get scrubbed too.
>
> So the UA string is harder to parse than a header containing only this
> version, but the syntax is fairly straightforward in RFC 2616. Also,
> I'm not seeing a Flash-Version header, or a header that alone advertises
> any other browser capabilities, so unless we want to make a new header
> and put *all* advertised capabilities in it, User-Agent seems the best
> choice.
>
> Cheers,
> Sid
>

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

Brandon Sterne

unread,
Jun 30, 2009, 11:50:15 AM6/30/09
to ignazb, dev-se...@lists.mozilla.org
(copying the dev-security newsgroup)

Hi Ignaz,

Thanks for the feedback. The "spoofed security indicators" from an
injected CSP meta tag is a fair point and one I haven't thought of
previously. I'm not sure if browsers will implement such visual
indicators for CSP because it may confuse users. This is still a valid
point, though, and we've struggled with the idea of <meta> tag policy
from the beginning. The idea is to enable sites which can't set headers
to use CSP, but the reward might not be worth the risk. In fact, Sid,
one of the engineers implementing CSP has proposed removing this from
the design:
http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html

If there are no major objections to doing so, it looks like you'll get
your way :-)

Cheers,
Brandon


ignazb wrote:
> Hello,
>
> I just read some of the documentation about CSP and I must say it
> looks promising. However, I think there are some "flaws" in the spec.
> -) I think it is a bad idea to allow the use of a meta tag for CSP
> policy-declaration. If, for example, you decided to show a symbol in
> the browser that indicates that the site is CSP secured, it would not
> be possible to tell whether the CSP policy comes from the server via a
> HTTP header or from an attacker who just injected it (unless, of
> course, you display where the CSP policy came from). So if a user
> visits a site and sees it is CSP "secured" (although an attacker
> inserted the tag allowing the execution of scripts from his site) she
> could decide to turn on JavaScript although the site is inherently
> unsafe.
> -) There should probably also be a way to restrict the contents of
> meta tags in a website. If, for example, an attacker inserts a meta
> for a HTTP redirect, he could redirect users to his own website, even
> with CSP enabled.
>
> -- Ignaz

Bil Corry

unread,
Jun 30, 2009, 1:40:58 PM6/30/09
to Brandon Sterne, ignazb, dev-se...@lists.mozilla.org
One option is to meet in the middle: by default the meta tag is disabled, but the hosting provider can enable it via the X-Content-Security-Policy header; that way those who want the risk of it can still choose to use it.

Otherwise, +1 for removing meta tag support.


- Bil

0 new messages