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).
2. The original goal of CSP was to mitigate XSS attacks. 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 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. 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.)
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'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.
Thoughts?
-Brandon
On 10/22/2009 09:37 AM, Adam Barth wrote:
On Thu, Oct 22, 2009 at 8:58 AM, Mike Ter Louw<mter...@uic.edu> wrote:
I've added a CSRF straw-man:
https://wiki.mozilla.org/Security/CSP/CSRFModule
This page borrows liberally from XSSModule. Comments are welcome!
Two comments:
1) The attacker goal is very syntactic. It would be better to explain
what the attacker is trying to achieve instead of how we imagine the
attack taking place.
2) It seems like an attacker can easily circumvent this module by
submitting a form to attacker.com and then generating the forged
request (which will be sent with cookies because attacker.com doesn't
enables the anti-csrf directive).
Adam
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
