how to test CSP
Hi, I have downloaded the CSP-enabled preview build for Windows. But I don't know how to use it in order to test the CSP in action. I can't understand the following line: Grab a preview build of Minefield and load this page to see how CSP works. For each individual test, a CSP-supporting browser will display PASS while a non-supporting browser will display FAIL. Each test also contains a comment showing the CSP header that was sent. Can you tell me how to really test these things? Regards, Nilesh ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: how to test CSP
Nilesh Kumar wrote: Hi, I have downloaded the CSP-enabled preview build for Windows. But I don't know how to use it in order to test the CSP in action. I can't understand the following line: Grab a preview build of Minefield and load this page to see how CSP works. For each individual test, a CSP-supporting browser will display PASS while a non-supporting browser will display FAIL. Each test also contains a comment showing the CSP header that was sent. Can you tell me how to really test these things? Regards, Nilesh ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security Not sure what your doing here. but with reading (correct me if I'm wrong) minefield might be just for Linux distros(x86_64). could be wrong though. Justin P. Mattock ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: how to test CSP
On 26/10/09 08:46, Nilesh Kumar wrote: Grab a preview build of Minefield Download a copy of the latest trunk builds of Firefox which have CSP support. The text you quote should have provided a link. and load this page to see how CSP works. For each individual test, a CSP-supporting browser will display PASS while a non-supporting browser will display FAIL. Each test also contains a comment showing the CSP header that was sent. The test page contains a load of tests. If they say PASS, CSP is working. If they say FAIL, it's not. Can you tell me how to really test these things? Is your question really how do I learn about the CSP syntax, add CSP to my own pages, and test whether it's working? Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CSRF Module (was Re: Comments on the Content Security Policy specification)
On 10/22/09 6:09 PM, Adam Barth wrote: I agree, but if you think sites should be explicit, doesn't that mean they should explicitly opt-in to changing the normal (i.e., non-CSP) behavior? They have already opted in by adding the CSP header. Once they've opted-in to our web-as-we-wish-it-were they have to opt-out of the restrictions that are too onerous for their site. It seems very reasonable to mitigate history stealing and ClickJacking without using CSP to mitigate XSS. It seems reasonable to mitigate both of those without using CSP at all. History stealing is going to come from attacker.com where they aren't going to add headers anyway. The proposed CSP frame-ancestors could just as easily go into an extended X-Frame-Options (and be a better fit). And it's really only a partial clickjacking defense anyway so maybe that aspect should go into whatever defense feature prevents the rest of clickjacking. NoScript's ClearClick seems to do a pretty good job (after a rough start) and gets to the heart of the issue without requiring site changes. I think we're all agreed on this point. Our current disagreements appear to be: 1) Whether frame-src should be in the resources module or in the same module as frame-ancestor. 2) Whether sites should have to opt-in or opt-out to disabling inline script and/or eval-like APIs. I don't think this is the right venue for deciding the latter, the audience here just doesn't have enough of the right people. We feel extraordinarily strongly that sites should have to explicitly say they want to run inline-script, like signing a waiver that you're going against medical advice. The only thing that is likely to deter us is releasing a test implementation and then crashing and burning while trying to implement a reasonable test site like AMO or MDC or the experiences of other web developers doing the same. The eval stuff I feel a lot less strongly about the default, but feel there's value in consistency of having site authors loosen restrictions rather than have some tighten and some loosen. -Dan ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CSRF Module (was Re: Comments on the Content Security Policy specification)
It seems reasonable to mitigate both of those without using CSP at all. +1. But the current spec was trying to address them. For e.g all the img-src, frame-src , frame-ancestor, font-src, style-src isn't really needed for preventing XSS (afaik). My view is that there is not problem with including them. The word 'content-security-policy' is very generic. If it is only going to apply for XSS then you should rename it to something more specific. clickjacking. NoScript's ClearClick seems to do a pretty good job (after a rough start) and gets to the heart of the issue without requiring site changes. Agreed. I am nott sure if it would be easy for browser vendors to actually implement something like ClearClick. Ideally ClearClick is the correct way to solve the threat (over frame ancestors). Cheers Devdatta ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
