Hi There are two threads running in parallel here:
1) Should blocking XSS be default behaviour of adding a X-Content-Security-Policy? (instead of the straw man proposal where a additional 'block-xss' would be required ) 2) Should the result of blocking XSS also cause eval and inline scripts to be disabled? If 1 is the case, then blocking eval and inline scripts by default is imho unacceptable. The reasons are the same as Adam succinctly pointed out in his ' Forward and backward compatibility ' bullet in the previous mail. But if to enable XSS protection, the user types in block-xss, then I think Brandon argument makes sense. block-xss should block XSS , which requires us to disable eval and inline scripts. But if for compatibility the user wants to continue supporting them , he should explicity add support for them with say 'allow-eval'. With a block-eval directive, the correct policy would always be 'block-xss block-eval' which doesn't make sense to me if we are hoping that eval support would just be a stop gap while the web admins figure out how to get by without it. Regards Devdatta 2009/10/27 Adam Barth <[email protected]>: > On Mon, Oct 26, 2009 at 6:11 PM, Daniel Veditz <[email protected]> wrote: >> 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. > > I understand the seductive power of "secure-by-default" here. It's > important to understand what we're giving up in terms of complexity > and extensibility. > >> 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. > > This statement basically forecloses further discussion because it does > not advance a technical argument that I can respond to. In this > forum, you are the king and I am but a guest. > > My technical argument is as follows. I think that CSP would be better > off with a policy language where each directive was purely subtractive > because that design would have a number of simplifying effects: > > 1) Forward and backward compatibility. As long as sites did not use > the features blocked by their CSP directives, their sites would > function correctly in partial / future implementations of CSP. > > 2) Modularity. We would be free to group the directives into whatever > modules we liked because there would be no technical interdependence. > > 3) Trivial Combination. Instead of the current elaborate algorithm > for combining policies, we could simply concatenate the directives. > An attacker who could inject a Content-Security-Policy header could > then only further reduce his/her privileges. > > 4) Syntactic Simplicity. Instead of two combination operators, ";" > for union and "," for intersection, we could simply use "," and match > standard HTTP header syntax. > > Balancing against these pros, the con seem to be that we hope the > additive, opt-out syntax will prod web developers into realizing that > adding "script-src inline" to the tutorial code they copy-and-paste is > more dangerous than removing "block-xss". > > Adam > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
