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
Brandon Sterne wrot
(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.
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
On Apr 2, 5:12 pm, Brandon Sterne 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
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 supp
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
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 sit
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 implemen
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
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 sani
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
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
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
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
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
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
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
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
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
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.
>
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
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
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 th
On 4/7/09 4:25 AM, Gervase Markham wrote:
> What's the story on inline
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
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
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 de
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 An
* Brandon Sterne:
> On Apr 4, 10:39 am, Florian Weimer 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
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?
"a
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 wrote:
> Are we expecting to see some or all of this in Firefox 3.5, or Firefox-next?
Firefox-next.
> - "but a de
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).
-
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 t
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
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 fo
On Apr 4, 10:39 am, Florian Weimer 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 stic
* 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 handle
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
38 matches
Mail list logo
