Required CSP modules (was Re: CSRF Module)
Adam Barth
On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne <bst...@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
Lucas Adamski
The threat-model centric approach won't work in the long run for a few
reasons:
a) threat models change over time.. nobody was even talking about
clickjacking until a few years ago, so had we designed this previously
we would have put frame controls under some other category (maybe
content loading)
b) API's change over time so they can drift between threat
groupings... frames are now a potential XSS concern due to postMessage
So now we're looking at framing being potentially controlled by
several different "modules": maybe clickjacking, CSRF, content
importing, and XSS
CSS is content importing.. oh but IE allows CSS "expressions" so its a
XSS vector too.
Threats just don't map to API's in a remotely neat 1 to many
relationship. Threat models are also too volatile. Which isn't to
say that we haven't been closely considering specific threat models
when designing CSP, because we have been. But we intentionally did
not build the actual directive names around the threats du jour.
If we are concerned about communication and documentation then we
should focus on that problem. Designing a security model primarily
around its digestive properties is the wrong goal IMHO. We have lots
of time to figure out the best ways of communicating, but we'll be
stuck with whatever implementation we come up with initially for a
long time. That's the nature of policy-centric mechanisms.. the
mechanism should be a generalized method for enforcing policies, and
then the effort is on developing sets of policies that achieve
particular goals, and with sufficient iteration and testing go on to
become common deployment patterns. Trying to bake those in from the
get-go seems to assume perfect knowledge of current and future threats.
So a good exercise might be, for a given threat (CSRF, clickjacking,
whatever), to document the specific threat model then see whether it
could be addressed via the current proposal (https://wiki.mozilla.org/Security/CSP/Spec
). Maybe that would help us develop the documentation and
specifications necessary to better explain the value of the model.
Of course, this is all just MHO. :)
Lucas.
P.S. Regarding making XSS a mandatory and opt-out module, those might
be related things. I think the question is really, when a given user
agent or website states that they have deployed CSP, does that really
mean anything in a concrete sense?
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
Ian G
> [putting on my IMHO hat]
>
> The threat-model centric approach won't work in the long run for a few
> reasons:
good post!
iang
Adam Barth
> The threat-model centric approach won't work in the long run for a few
> reasons:
I'm not sure what we're arguing about. Do you like Brandon's
groupings? They made sense to me. Are there concrete changes you
think we should make?
> a) threat models change over time.. nobody was even talking about
> clickjacking until a few years ago, so had we designed this previously we
> would have put frame controls under some other category (maybe content
> loading)
I'm not sure we would have thought to include frame-ancestors without
having ClickJacking in mind.
> b) API's change over time so they can drift between threat groupings...
> frames are now a potential XSS concern due to postMessage
I think it's safe to say that the ability to block inline and external
script is the most important use case for CSP. I believe that because
I'm motivated by wanting to mitigate XSS. Other folks might have
different reasons for thinking they're important. Those policy levers
are one or two order of magnitude more important than controlling
xhr-src, IMHO.
> CSS is content importing.. oh but IE allows CSS "expressions" so its a XSS
> vector too.
Right, but the issues are separable. It's much more important to
disable CSS expressions than it is disable all inline CSS, for the
same reason it's much more important to diable inline event handlers
than it is to disable all HTML attributes.
> But we intentionally did not build the actual directive names
> around the threats du jour.
I agree that anti-csrf is too narrow a directive name.
> If we are concerned about communication and documentation then we should
> focus on that problem.
I suspect folks are more likely to learn how to use CSP by copy and
pasting from Ajaxian than they are to read the spec.
> the mechanism should be a generalized method
> for enforcing policies, and then the effort is on developing sets of
> policies that achieve particular goals, and with sufficient iteration and
> testing go on to become common deployment patterns. Trying to bake those in
> from the get-go seems to assume perfect knowledge of current and future
> threats.
I didn't quite understand what you meant here. There's an unbounded
number of policy levers we could expose. We should prioritize them
based on which threats we think are most important. If the threat
landscape changes in the future, we can add more policy levers. Try
to predict the threats of the future is a tricky business indeed.
That's why I think modularity and extensibility is good for CSP.
> P.S. Regarding making XSS a mandatory and opt-out module, those might be
> related things. I think the question is really, when a given user agent or
> website states that they have deployed CSP, does that really mean anything
> in a concrete sense?
Mean anything to whom? The proof will be in the pudding, so to speak.
If browser X implements a bunch of useless modules, that won't be of
much help to web developers. Different vendors might have different
ideas about what's important, though. The market will sort out who's
right.
What I see as likely is that Firefox will implement most / all of the
modules, and the other browser vendors will implement some subset. If
some directives become popular among web developers, then the other
browser vendors will be incentivized to implement them too.
Adam
Devdatta
(long post, like lukas very imho)
The thing that I like about modularizing based on threats is that it
is much easier to explain to the web developer. I agree that this
might make Browser vendors sad because (as Lukas said) "Threats just
don't map to API's in a remotely neat 1 to many relationship."
But , this lack of clear mapping is okay -- because that is a problem
for browser vendors and spec writers, not of the Web Developers. The
set consisting of spec writers + browser vendors is much much smaller
than web developers.
Consider the approach Brandon proposed (based on Browser API) and say
the web site owner wants to protect against History enumeration. He
now has to look at each module and see if it says something about
History Enumeration and then come up with the subset of directives
that he thinks will ensure protection against it. Compare to just
saying 'safe-history' (or 'no-clickjacking' for click jacking etc.).
I agree that this can _theoretically_ solved by having good
documentation and explanations. But still , the final syntax the web
site owner has to write is more complicated and that adds to possible
errors , imho. You are also depending upon the documentation writers
(do not assume people will only use the documentation you have
written). Making the syntax and the explanation really simple is a
nice goal as I think it protects against bad documentation too( there
is really very few ways someone could misinterpret 'safe-history' in
documentation/explanation).
With a threat model based approach, the browser vendors and the spec
writers are the ones who have to worry about all the nitty gritty
details (what all things need to be done to prevent against 'history
enumeration'?) And the sum of all this is made into one module.
Ofcourse, this would require writing down the spec with more
thought.[1]
With regards, to new threats (that are somehow related or part of an
older threat) popping up in the future. There are two approaches : you
could give the threat a new name (e.g HistoryEnum2.0) and create a
new directive , or include protection against that threat in the spec.
Users of new browsers would be protected automatically. I like the
latter approach more. Realize that for threats you haven't thought of
at all, it doesn't matter how you have split CSP -- a user using an
old browser and a web developer unaware of the threat , can not be
protected. But with the latter approach, a user using a new browser
(even with a web developer unaware of the threat) is protected.
Regards
Devdatta
[1] An example : https://wiki.mozilla.org/Talk:Security/CSP/XSSModule
Daniel Veditz
> CSS is content importing.. oh but IE allows CSS "expressions" so its a
> XSS vector too.
IE8 has killed expressions off, our CSP spec says -moz-binding has to
come from chrome: or resource: (that is, be built in).
https://wiki.mozilla.org/Security/CSP/Spec#XBL_bindings_must_come_from_chrome:_or_resource:_URIs
That's a pretty vendor-specific thing to put in CSP, I think we just
want to kill or restrict -moz-binding in the product in general (as IE
has done) and not worry about it in CSP. Either way, though, we can
treat CSS only from the data-loading aspects. The implication of that is
that we don't need to worry about "inline-style" which has been raised
recently.