On 3/28/09 7:10 PM, FunkyRes wrote:
I've been working on a php class that implements CSP as an output
filter on the web server before the content is ever sent to the
requesting browser. That way browsers that don't support CSP still can
have some measure of protection when a website decides to implement
CSP (and utilizes my class).
Neat! While I don't believe a server-side filter will be able to
implement CSP properly, like you said there is still a small bit of
protection afforded to CSP-agnostic clients. Server-side filtering
won't be able to catch run-time DOM changes that violate the policy, so
it's probably not a good replacement, but yet another layer is nice.
1) if style-src does not contain the host the page is being served
from, do in-line style need to be blocked?
I think that would be the right thing to do. We would also probably
want to block use of the style attribute in HTML tags.
2) Does the host expression list limit a wildcard to the beginning of
a host expression?
Yes. *.x.y is ok, x.*.y.z is not. <host-name> is defined this way in
the draft of the spec:
https://wiki.mozilla.org/Security/CSP/Spec#Formal_Policy_Syntax
3) Does CSP really block all event attributes?
We're working on a more detailed description that will address details
like this. We have to allow event handlers in one way or another or
like half the web will implode. It is my thought that we should allow
event handlers in the HTML served on the main page, but they aren't
extracted from data contexts after that; basically, once the load event
fires, event handlers are frozen (except in JavaScript) and attribute
manipulation won't register new ones. Look for an update on the details
page you referenced soon.
4) It looks to me like frame-ancestors is something that can only be
enforced client side. Is that correct?
Correct. You can only enforce this at the end of the line.
As I mentioned, we're working on a very detailed list of the basic
restrictions imposed on any CSP-implementing site (regardless of the
policy), and will be updating the wiki as well with more details as
discussion progresses. Thanks for the feedback!
-Sid
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
