Re: Content Security Policy feedback
Sid Stamm wrote on 1/12/2009 3:19 PM: > It seems to me that unless client browsers *never* send CSP-related > data to the server then the server can ultimately determine which > clients are using CSP. I agree, without the client advertising CSP-support, sites will test for CSP just as they test for JavaScript, cookies, etc. You could probably test for CSP by using policy-uri, if the browser requests it from your server, then it supports CSP. To prevent an attacker from causing a browser to load it ala CSRF, you could even add a nonce to the request: X-Content-Security-Policy: policy-uri /policy.csp?nonce=ABC123 - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
On Jan 12, 2:23 pm, Bil Corry wrote: > It already has this feature, see #6: Ah, sorry for my blindness Bil. It has been a while since I read that, and simply spaced on that feature. Gerv: what are your thoughts on (mis)use of the Report-URI to determine which browsers support CSP? For example, given a policy "X- Content-Security-Policy: allow self", Report-URI "http://self.com/ report" and a tag served "
Re: Content Security Policy feedback
Sid Stamm wrote on 1/12/2009 12:52 PM: > Or do we want phone-home features for CSP so the browser will > automatically tell a site when its policy is violated? It already has this feature, see #6: http://people.mozilla.org/~bsterne/content-security-policy/details.html - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
On Jan 12, 5:53 am, Gervase Markham wrote: > not all end-users have to use it for it to be helpful in the case of a > particular site which is using it. I say this because once the site > owner is warned of the problem, he can fix it. If no-one has CSP, it may > take much longer for people to notice the compromise. Of course, unless the site breaks in a noticeable way when violations of CSP occur, there is no additional help for the site developer... and I don't believe that CSP is intended to have a violation reporting mechanism. Additionally, it is my impression that a lot of attacks stopped by CSP would break un-noticed. For example, a cross-site exploit that simply embeds a
Re: Content Security Policy feedback
Gervase Markham wrote: Sid Stamm wrote: What worries me is that with no assurance that they're enforced, CSP policies won't be provided by web sites since it takes time (granted, not much of it) to compose them. It's likely that a profit-driven company might rather have their engineers spend time fuzzing or bug fixing than designing a good CSP string that may or may not ever be used. It really doesn't take long - it's not a complicated spec. I'm not sure we need to make it "more attractive" by promising what we can't deliver. One concern is the time and effort required to refactor existing code to use only external scripts (a non-trivial task). Development of new web code can take this restriction into account but still requires deliberate effort throughout the development cycle to maintain support for CSP. I think utilizing CSP will be a very conscious decision by web site operators, weighing the benefits CSP offers, the cost of implementing and maintaining CSP support, and the risks of not adding CSP to their web site. While it would be nice to have a low cost, effective, add-on layer of security, it seems the requirement of no inline script code adds significantly to the cost of CSP. Therefore site owners should be able to estimate the benefit CSP will give them by measuring the level of browser support among the site's visitors, so it can be weighed against the cost of CSP deployment. Is it correct that the rule against inline scripts is in effect for all CSP policies, even when script-src is not used? Mike ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
Sid Stamm wrote: > Gervase Markham wrote: >> Security is a multi-faceted beast. > Point taken, and I agree, it was a crappy analogy. > >> Again, CSP is here being used as a front line of >> defence, and it shouldn't be. > I agree with you... optimally, CSP should not be front-line defense. > But for it to be helpful in practice, there must be a motivation for > people to put it on their sites. > > What worries me is that with no assurance that they're enforced, CSP > policies won't be provided by web sites since it takes time (granted, > not much of it) to compose them. It's likely that a profit-driven > company might rather have their engineers spend time fuzzing or bug > fixing than designing a good CSP string that may or may not ever be > used. It really doesn't take long - it's not a complicated spec. I'm not sure we need to make it "more attractive" by promising what we can't deliver. >> Another feature of CSP is "herd immunity" - >> it doesn't have to be used by everyone to >> be helpful. Sorry, I realise that in hindsight I was ambiguous here. I meant that not all end-users have to use it for it to be helpful in the case of a particular site which is using it. I say this because once the site owner is warned of the problem, he can fix it. If no-one has CSP, it may take much longer for people to notice the compromise. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
