On Nov 20, 4:37 pm, bsterne <[EMAIL PROTECTED]> wrote: > On Nov 17, 2:19 pm, Bil Corry <[EMAIL PROTECTED]> wrote: > > > (1) Something that appears to be missing from the spec is a way for > > the browser to advertise to the server that it will support Content > > Security Policy, possibly with the CSP version. By having the browser > > send an additional header, it allows the server to make decisions > > about the browser, such as limiting access to certain resources, > > denying access, redirecting to an alternate site that tries to > > mitigate using other techniques, etc. Without the browser advertising > > if it will follow the CSP directives, one would have to test for > > browser compliance, much like how tests are done now for cookie and > > JavaScript support (maybe that isn't a bad thing?). > > This isn't a bad idea, as I have seen this sort of "compatibility > level" used successfully elsewhere. If future changes are made to the > model which would define restrictions for new types of content (e.g. > <video>), or which would affect the default behaviors for how content > is allowed to load, then it will be useful to servers to have their > clients' CSP version information. If we are going to add this to the > model, then we should do so from the beginning to avoid the > potentially messy browser compliance testing that would result after > the first set of changes.
I personally see value there for the website, but if 99.9% of websites will never do anything with the header, then it probably isn't worthwhile (or it may take version 2 before the need is evident). The big challenge here is making sure the CSP announcement header can not be spoofed via XHR, so to that end, I'd recommend prefixing the header name with "Sec-" such as "Sec-Content-Security-Policy" -- the latest draft of XHR2 specifies that any header beginning with "Sec-" is not allowed to be overwritten with setRequestHeader(): http://www.w3.org/TR/XMLHttpRequest2/#setrequestheader Of course, XHR2 would have to be implemented in the browsers first in order to take advantage of the requirement. > > (2) Currently the spec allows/denies based on the host name, it might > > be worthwhile to allow limiting it to a specific path as well. For > > example, say you use Google's custom search engine, one way to > > implement it is to use a script that sits > > onwww.google.com(e.g.http://www.google.com/coop/cse/brand?form=cse-search-box〈=en). > > By having an allowed path, you could prevent loading other scripts > > from thewww.google.comdomain. > > I don't have a strong opinion on this one. My initial reaction is > that it adds complexity to the model, but perhaps complexity that's > warranted if people feel it's a useful feature. Do you have some > specific use cases to share which would demonstrate the usefulness of > your suggestion? I don't have a specific use case, I'm thinking more of the edge cases where content is allowed from a domain that allows a multitude of third-party content. Maybe this is something to explore for v2 if warranted. > > (3) Currently the spec focuses on the "host items" -- has any thought > > be given to allowing CSP to extend to sites being referenced by "host > > items"? That is, allowing a site to specify that it can't be embedded > > on another site via frame or object, etc? I imagine it would be > > similar to the Access Control for XS-XHR[2]. > > I would agree with Gerv, that this feels a bit out of scope for this > particular proposal. Then maybe something to consider down the road. It would be useful to prevent hot linking and clickjacking . - Bil _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
