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
> 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).
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.
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
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
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
> - 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
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
"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.
> 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.
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
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
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
>> 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
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
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
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
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
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
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
OK. Then we need to spec that redirects are not honoured.
Gerv
... (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
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
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
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
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
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
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
I proposed an alternative earlier in the thread:
- Bil
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
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.
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
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
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
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
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
Otherwise, +1 for removing meta tag support.
- Bil