See inline. On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne <bste...@mozilla.com> wrote: > I'd like to take a quick step back before we proceed further with the > modularization discussion. I think it is fine to split CSP into modules, > but with the following caveats: > > 1. Splitting the modules based upon different threat models doesn't seem to > be the right approach. There are many areas where the threats we want to > mitigate overlap in terms of browser functionality. A better approach, > IMHO, is to create the modules based upon browser capabilities. With those > capability building blocks, sites can then construct policy sets to address > any given threat model (including ones we haven't thought of yet).
It's unclear to me which organization is better. I'd be in favor of picking one and giving it a try. > 2. The original goal of CSP was to mitigate XSS attacks. I agree that XSS mitigation is the most compelling use case for CSP. > The scope of the > proposal has grown substantially, which is fine, but I'm not at all > comfortable with a product that does not require the XSS protections as the > fundamental core of the model. I think if we go with the module approach, > the XSS protection needs to be required, and any additional modules can be > optionally implemented. I'm not sure it matters that much whether we label the XSS mitigations "recommended" or "required." I suspect every browser vendor that implements CSP will implement them. If you'd prefer to label them required, I'm fine with that. > I propose that the default behavior for CSP (no > optional modules implemented) is to block all inline scripts (opt-in still > possible) and to use a white list for all sources of external script files. This is a separable issue. I'm not sure whether it's better to opt-in or opt-out of this behavior. Opting-in makes policy combination easier to think about (the tokens just accumulate). I'd prefer if sites had to opt-in to the block-eval behaviors because I suspect complying with those directives will require substantial changes to sites. > The script-src directive under the current model serves this function > perfectly and doesn't need to be modified. (We can discuss how plugin > content and CSS, which can be vectors for script, should be governed by this > core XSS module.) That depends on whether we decide opt-in or opt-out is better for controlling inline script and eval-like APIs. > As a straw man, the optional modules could be: > * content loading (e.g. img-src, media-src, etc.) > * framing (e.g. frame-src, frame-ancestors) > * form action restriction > * reporting (e.g. report-uri) > * others? I'd but frame-src in with content loading, but otherwise this seems fine. > I'm definitely not opposed to splitting apart the spec into modules, > especially if it helps other browser implementers move forward with CSP. I > REALLY think, though, that the XSS protections need to be part of the base > module. I don't think it matters that much whether the XSS mitigations are part of the base module or whether they're in a separate required/recommended module. I think the main issue here is making the spec easy to read. Adam _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
