On 10/7/10 12:45 PM, =JeffH wrote: > Ok, suppose I have this origin i wish to protect > "https://www.example.com";, the origins "http://example.com"; and > "https://example.com"; redirect to the former,
I'm not sure of the relevance of the re-directs here. You don't include plain example.com in any of your policies so attempts to load content from there will be blocked before it gets a chance to redirect. If you do load content from a host which redirects, each host in the redirect chain must show up in the whitelist. > X-Content-Security-Policy: \ allow 'self' > \ -- returns HTML https://sub1.example.com \ > -- " JS, CSS https://sub2.example.com \ -- > " IMGs Since your original host is HTTPS you don't need to specify it on the above, although the redundancy doesn't hurt. > foo.otherexample.com \ -- " IMGs > bar.yetanotherexample.com ; \ -- " IMGs These hosts inherit the https:// scheme. Not that I'm encouraging mixed-mode, but if these are intended to be http: servers you need to specify it. In practice the scheme issue is more likely to come up in an http: page that includes https: elements--the https: would have to be explicit in the policy. Also, https:'self' isn't valid. If you're loading resources from yourself securely and insecurely you'll have to spell out the host name at least once. If you know for a fact that JS will _ONLY_ come from sub1.example.com then I would strongly urge adding "script-src sub1.example.com;" to the policy to protect against HTML injection of a <script> tag pointing at one of the other hosts. You have (presumably) no control over foo.otherexample.com so why risk your site's security on their ability to secure their site? In fact, I'd strongly recommend every policy explicitly identify both script-src and object-src directives (and use 'none' if you can). Beyond that you can decide if you want to whitelist by type or be lazy (or positive spin: header-space conserving) and use a catch-all "allow" directive. In the policy above your site might only have HTML, JS, CSS and IMGs, but by using the allow policy you're allowing injection of <embed>, @font-face, <video> and frames to any of the list of specified domains. > 1. should one consider setting CSP policies for the other > origins one controls, eg sub1.example.com and/or sub1.example.com > ? Currently we're only looking at CSP for document loads (including frames). "Content Security Policy" is a broad term and we expect there will be interest in adding other kinds of policy in the future. > to prevent anything from "working" if one loads directly from one > of those origins ("just in case"), then one could imagine having > them emit a "allow 'none'" policy of their own. That would work if they're loaded as documents. The in-line content could still be framed unless you also add "ancestor-frames 'none';" (or https://www.example.com or whatever is appropriate). > 2. the other origins not under example.com's admin control might > for whatever reason emit their own CSP policies. They might, but they won't do anything except when loaded as framed documents. Apart from CSP those sites can also use X-Frame-Options: DENY to prevent framing, ancestor-frames is just the same feature with finer-grained control (we considered extending X-Frame-Options instead but that breaks interoperability with other browsers). Apart from framing sites can inspect Referer: and possibly Origin: to prevent resource use. If your page is including 3rd party content you should have some kind of an understanding with that content's host. > 3. how do any CSP policies emitted by these origins other than > "https://www.example.com"; interact with the latter's policy? The > CSP draft spec presently explicitly says (emphasis added).. > > "When multiple instances of the X-Content-Security-Policy HTTP > header are present in /an HTTP response/..." This doesn't apply to the case you're asking about. The policies on different resources aren't mixed, but a single resource might have multiple X-Content-Secuity-Policy headers. In the bad case maybe one or more of them is maliciously injected, so we want to tighten policies rather than loosen. Better header injection lead to Denial of Service than that it let an attacker enable XSS on your site. Multiple headers might arise legitimately if a web app specified a restrictive policy for an individual page while the site's server infrastructure imposed a looser blanket policy on everything loaded from that domain. I'm not sure how useful this will be in practice, but it was either intersect the policies or assume multiple headers are an attack and switch to "allow 'none';". -Dan Veditz _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
