(copying the dev-security newsgroup) Hi Ignaz,
Thanks for the feedback. The "spoofed security indicators" from an injected CSP meta tag is a fair point and one I haven't thought of previously. I'm not sure if browsers will implement such visual indicators for CSP because it may confuse users. This is still a valid point, though, and we've struggled with the idea of <meta> tag policy from the beginning. The idea is to enable sites which can't set headers to use CSP, but the reward might not be worth the risk. In fact, Sid, one of the engineers implementing CSP has proposed removing this from the design: http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html If there are no major objections to doing so, it looks like you'll get your way :-) Cheers, Brandon ignazb wrote: > Hello, > > I just read some of the documentation about CSP and I must say it > looks promising. However, I think there are some "flaws" in the spec. > -) I think it is a bad idea to allow the use of a meta tag for CSP > policy-declaration. If, for example, you decided to show a symbol in > the browser that indicates that the site is CSP secured, it would not > be possible to tell whether the CSP policy comes from the server via a > HTTP header or from an attacker who just injected it (unless, of > course, you display where the CSP policy came from). So if a user > visits a site and sees it is CSP "secured" (although an attacker > inserted the tag allowing the execution of scripts from his site) she > could decide to turn on JavaScript although the site is inherently > unsafe. > -) There should probably also be a way to restrict the contents of > meta tags in a website. If, for example, an attacker inserts a meta > for a HTTP redirect, he could redirect users to his own website, even > with CSP enabled. > > -- Ignaz _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
