On 07/07/09 19:18, Sid Stamm wrote:
I personally want to eradicate the META tag
(http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html). This
should be discussed more in depth to decide if we should remove META
support, if we should support multiple HTTP headers, etc.
My comment:
Why not allow multiple headers, and keep the intersection algorithm?
This way, the hosting company has to provide a special interface for
editing the header rather than the customer just being able to type it
into the page, but it still allows it to make non-negotiable
restrictions. They just serve their restrictions in the first header,
and make sure the customer-provided header comes afterwards.
This means you still need the policy intersection logic, so that part of
complexity isn't removed, but it still allows, at least in some ways,
the use case that you were worried about. A compromise, in other words.
However, I would now add that removing <meta> support (i.e. inline
policy) and sticking with headers makes CSP an HTTP-only technology. Is
that something we are happy with?
Spec updated to support relative URIs. I don't think CSP should interact
with the BASE tag at all.
I agree. Even with <meta>, it's just saying "hey, here's a header you
didn't get". So none of your <base> are belong to us.
What happens to CSP if I save a CSP-protected document to my local
disk? I’d assume it would be ignored (because many restrictions could
be broken) but this should be explicit. Also, when saving docs to
disk, HTTP headers are lost, so to preserve it, you’d need to
explicitly serialize to a META tag, which could get complicated if the
document already had a CSP META…
Under discussion.
Let's say content saved to disk should just lose its CSP. What would be
the disadvantages of that policy?
Updated spec to allow "https://self:443"; syntax. Self flexible and may
or may not include scheme and port. When absent from the expression,
scheme or port are inherited.
Good idea.
Apparently, ASP.NET controls are tightly bound to use of JavaScript:
protocol URIs, and this isn’t likely to be easily changed. For that
reason, it might be interesting to have a way to allow only those URIs
and not inline script blocks, event handlers, etc?
Under Discussion.
I think we need to figure out whether permitting this in fact blows all
protection out of the water, or not.
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
