CSRF Module (was Re: Comments on the Content Security Policy specification)
Adam Barth
> 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
Mike Ter Louw
> 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).
I agree. It seems anti-csrf (as currently defined) would be most
beneficial for defending against CSRF attacks that don't require any
user action beyond simply viewing the page (e.g., <img src="attack">).
Form actions would perhaps require some additional constraints, such as
only allowing submission to |self| or other whitelisted URIs.
Link activation is harder, because (I would assume) most websites want
to allow links to different-origin URIs. And as you stated, not sending
cookies here doesn't help because the link could go to attacker.com, and
the page can contain an image based CSRF (thus the threshold for
successful attack is still 1 click).
Thanks for the feedback,
Mike
Adam Barth
> I agree. It seems anti-csrf (as currently defined) would be most beneficial
> for defending against CSRF attacks that don't require any user action beyond
> simply viewing the page (e.g., <img src="attack">).
Maybe we should focus the module on this threat more specifically. My
understanding is that this is a big source of pain for folks who
operate forums, especially for user-supplied images that point back to
the forum itself. What if the directive was something like
"cookieless-images" and affected all images, regardless of where they
were loaded from?
Adam
Mike Ter Louw
I think this is a good start, and should be an option for sites that
don't want CSP to provide any other CSRF restrictions. I've added an
additional directive to the wiki, but it needs further definition.
Mike
Devdatta
> I agree. It seems anti-csrf (as currently defined) would be most beneficial
> for defending against CSRF attacks that don't require any user action beyond
> simply viewing the page (e.g., <img src="attack">).
>
> allowing submission to |self| or other whitelisted URIs.
>
I don't understand. In each of the cases above, the attacker site will
not enable the directives and img requests or form requests from his
page will cause a CSRF to occur.
-devdatta
2009/10/22 Mike Ter Louw <mte...@uic.edu>:
> Adam Barth wrote:
>>
>> 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).
>
> I agree. It seems anti-csrf (as currently defined) would be most beneficial
> for defending against CSRF attacks that don't require any user action beyond
> simply viewing the page (e.g., <img src="attack">).
>
> Form actions would perhaps require some additional constraints, such as only
> allowing submission to |self| or other whitelisted URIs.
>
> Link activation is harder, because (I would assume) most websites want to
> allow links to different-origin URIs. And as you stated, not sending
> cookies here doesn't help because the link could go to attacker.com, and the
> page can contain an image based CSRF (thus the threshold for successful
> attack is still 1 click).
>
> Thanks for the feedback,
>
> Mike
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Devdatta
> Maybe we should focus the module on this threat more specifically. My
> understanding is that this is a big source of pain for folks who
> operate forums, especially for user-supplied images that point back to
> the forum itself. What if the directive was something like
> "cookieless-images" and affected all images, regardless of where they
> were loaded from?
>
requiring it to implement this policy regardless of the running script
context would require the UA to maintain a cache of policies for each
site the user has visited. This is against the requirements of the
base module. And I for one am against any such type of caching
requirement in the UA.
cheers
devdatta
2009/10/22 Adam Barth <abarth-...@adambarth.com>:
> On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw <mte...@uic.edu> wrote:
>> I agree. It seems anti-csrf (as currently defined) would be most beneficial
>> for defending against CSRF attacks that don't require any user action beyond
>> simply viewing the page (e.g., <img src="attack">).
>
> Maybe we should focus the module on this threat more specifically. My
> understanding is that this is a big source of pain for folks who
> operate forums, especially for user-supplied images that point back to
> the forum itself. What if the directive was something like
> "cookieless-images" and affected all images, regardless of where they
> were loaded from?
>
> Adam
Mike Ter Louw
>> I agree. It seems anti-csrf (as currently defined) would be most beneficial
>> for defending against CSRF attacks that don't require any user action beyond
>> simply viewing the page (e.g., <img src="attack">).
>>
>> allowing submission to |self| or other whitelisted URIs.
>
> I don't understand. In each of the cases above, the attacker site will
> not enable the directives and img requests or form requests from his
> page will cause a CSRF to occur.
For image CSRF, some protection would be required against redirection.
Either redirection must be disallowed, or anti-csrf needs to be enforced
for all redirections until the resource is located. But I'm not sure if
the latter is going to work if CSP policies are not composeable, and any
of the redirections or the image itself defines a CSP policy.
Form requests to attacker.com would presumably be blocked, as
attacker.com isn't in |self| nor the whitelist. So the attacker won't
be able to direct the user to a page without anti-csrf protection using
forms. But again this requires some enforcement of the whitelist during
any redirects.
Any ideas for how best to address the redirect problem?
Mike
Adam Barth
> I think this is a good start, and should be an option for sites that don't
> want CSP to provide any other CSRF restrictions. I've added an additional
> directive to the wiki, but it needs further definition.
I think it might be better to focus this module on the "forum poster"
threat model. Instead of assuming the attacker can inject arbitrary
content, we should limit the attacker to injecting content that is
allowed by popular form sites (e.g., bbcode). At a first guess, I
would limit the attacker to text, hyperlinks, and images. (And maybe
bold / italics, if that matters.)
On Thu, Oct 22, 2009 at 10:16 AM, Devdatta <dev.a...@gmail.com> wrote:
> I don't understand. In each of the cases above, the attacker site will
> not enable the directives and img requests or form requests from his
> page will cause a CSRF to occur.
We might decide to concern ourselves only with "zero click" attacks.
Meaning that once the user has clicked on the attacker's content, all
bets are off. If we imagine a 1% click-through rate, they we've
mitigated 99% of the problem.
On Thu, Oct 22, 2009 at 10:19 AM, Devdatta <dev.a...@gmail.com> wrote:
> requiring it to implement this policy regardless of the running script
> context would require the UA to maintain a cache of policies for each
> site the user has visited. This is against the requirements of the
> base module. And I for one am against any such type of caching
> requirement in the UA.
I agree that directives should affect only the current page.
On Thu, Oct 22, 2009 at 10:31 AM, Mike Ter Louw <mte...@uic.edu> wrote:
> For image CSRF, some protection would be required against redirection.
> Either redirection must be disallowed, or anti-csrf needs to be enforced
> for all redirections until the resource is located. But I'm not sure if
> the latter is going to work if CSP policies are not composeable, and any
> of the redirections or the image itself defines a CSP policy.
I agree that cookieless-images should affect all redirects involved in
loading the image.
> Form requests to attacker.com would presumably be blocked, as
> attacker.com isn't in |self| nor the whitelist. So the attacker won't
> be able to direct the user to a page without anti-csrf protection using
> forms. But again this requires some enforcement of the whitelist during
> any redirects.
I think we should assume that the attacker cannot inject form elements
because this is uncommon in forum web sites.
Adam
Mike Ter Louw
>> Maybe we should focus the module on this threat more specifically. My
>> understanding is that this is a big source of pain for folks who
>> operate forums, especially for user-supplied images that point back to
>> the forum itself. What if the directive was something like
>> "cookieless-images" and affected all images, regardless of where they
>> were loaded from?
>
> context would require the UA to maintain a cache of policies for each
> site the user has visited. This is against the requirements of the
> base module. And I for one am against any such type of caching
> requirement in the UA.
I think what Adam is intending is for the image resource to be requested
without cookies being sent, regardless of the image URI origin (i.e.,
the no-cookies policy applies even if the image URI is contained in
|self|). This would apply for all images requested in the context of a
page that has cookieless-images enabled. To enforce this policy, there
wouldn't be a need to cache policies for sites the user has previously
visited.
Mike
Mike Ter Louw
> I think it might be better to focus this module on the "forum poster"
> threat model. Instead of assuming the attacker can inject arbitrary
> content, we should limit the attacker to injecting content that is
> allowed by popular form sites (e.g., bbcode). At a first guess, I
> would limit the attacker to text, hyperlinks, and images. (And maybe
> bold / italics, if that matters.)
There should be room for each directive to address slightly different
threat scenarios. For the forum threat you've described, the attack
mechanics (i.e., CSRF) and basic remediation strategy (disallow sending
cookies) are common to other threats the module aims to defend against.
Additionally, cookieless-images is complementary to anti-csrf because
it defines an additional constraint to images loaded from |self|. So
perhaps the module needs to be better positioned and each directive
better motivated.
> I think we should assume that the attacker cannot inject form elements
> because this is uncommon in forum web sites.
That is fine for motivating cookieless-images, but this assumption could
prove inadequate for other scenarios where the threat exists. It may be
OK to remove the language governing form actions from CSRFModule if the
issue is further deferred to another module (as does [1]), where this
(currently hypothetical) module entirely blocks form submission if the
action URI is not in a whitelist of trusted origins. (That would target
the form-based password theft threat, as well as the CSRF threat.)
There is a usability issue here: is it more usable (w.r.t. the web
developer) to:
(1) support a declaration of "anti-csrf" and enable the widest default
set of protections that could be offered against CSRF (without being too
strict as to break the most common use cases), but possibly having
multiple modules specifying (complementary) form policies, or
(2) group all form-related policies in a single module, even if the
policies address fundamentally different attacks?
In this case, this boils down to: should CSP directives be
threat-centric or content-type-centric? Alternatively, this may be an
example of CSP being too granular.
Mike
[1] https://wiki.mozilla.org/Security/CSP/XSSModule#Open_Issues
Mike Ter Louw
> There is a usability issue here: is it more usable (w.r.t. the web
> developer) to:
>
> (1) support a declaration of "anti-csrf" and enable the widest default
> set of protections that could be offered against CSRF (without being too
> strict as to break the most common use cases), but possibly having
> multiple modules specifying (complementary) form policies, or
>
> (2) group all form-related policies in a single module, even if the
> policies address fundamentally different attacks?
Is it acceptable (not too strict) to block all form submission to
non-self and non-whitelisted action URIs when the anti-csrf directive is
given? If so, then the above usability issue may be moot: we can have
anti-csrf imply an as-yet-undefined directive that blocks form submission.
Mike
Adam Barth
> In this case, this boils down to: should CSP directives be threat-centric or
> content-type-centric? Alternatively, this may be an example of CSP being
> too granular.
I suspect we'll need to experiment with different approaches before we
have a good idea how to answer this question. In intuition tells me
that we'd be better off with a threat-centric design, but it's hard to
know ahead of time.
On Thu, Oct 22, 2009 at 12:53 PM, Mike Ter Louw <mte...@uic.edu> wrote:
> Is it acceptable (not too strict) to block all form submission to non-self
> and non-whitelisted action URIs when the anti-csrf directive is given? If
> so, then the above usability issue may be moot: we can have anti-csrf imply
> an as-yet-undefined directive that blocks form submission.
Instead of bundling everything together into "anti-csrf", we might be
better off with a directive to control where you can submit forms,
e.g., "form-action", but we seem to be getting far afield of the
problem you're trying to solve.
At a high level, I'm glad that you took the time to add your ideas to
the wiki, and I hope that other folks will do the same. My personal
opinion is that the current design has room for improvement,
particularly around clarifying precisely what problem the module is
trying to solve, but my opinion is just one among many. I'd like to
encourage more people to contribute their ideas in the form of
experimental modules, and hopefully the best ideas will rise to the
top.
Adam
Brandon Sterne
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<mte...@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
Collin Jackson
> 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).
Would that mean that each module would have multiple directives, with
a separate threat model for each one? It seems like the directives
should be granular to the level of threat models, or else a site will
be forced to give up functionality to defend against threats it's not
concerned about.
> 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 think it makes sense to have modules that are required for browser
vendos to implement, but are not required for web authors to enable.
Is that what you mean? We could make the XSSModule "required" for
browser vendors to implement instead of just "recommended." I don't,
however, think that a web author should be required to use the
XSSModule in order to benefit from the ClickJackingModule (for
example).
> 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.
I understand the desire to have "by-default" security, but one problem
with opt-out CSP rules is that they're hard to change. You can't add
new opt-out rules in the future because it will break web sites that
didn't know they were supposed to opt out, so we'd be stuck with an
initial set of opt-out rules and any rules added in future versions of
the spec would have to be opt-in. Also, it's tricky to change an
opt-out rule to be an opt-in rule in the future because web sites may
be relying on the opt-out behavior.
If there are a set of behaviors that make sense when used together,
then maybe providing a concise opt-in directive that enables them all
would be easier, e.g. "core-xss".
> 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.
Could you elaborate a little more on why you feel this way? This seems
like a major extensibility limitation that would be impossible to
change in the future.
Brandon Sterne
> On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne <bst...@mozilla.com> wrote:
>> 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).
>
> Would that mean that each module would have multiple directives, with
> a separate threat model for each one? It seems like the directives
> should be granular to the level of threat models, or else a site will
> be forced to give up functionality to defend against threats it's not
> concerned about.
I imagine each module would have its own directives, though not
necessarily more than one. If the modules are based on browser
capabilities, then it is possible to map these capabilities to threat
mitigations. If we try to do the reverse, that is, map threat
mitigations to CSP modules, we run the risk of having particular browser
capabilities governed by multiple, potentially conflicting, modules.
Take XSS and history stealing for example. Assume these are seperate
modules and each is responsible for mitigating its respective threat.
Presumably the safe history module will prevent a site from being able
to do getComputedStyle (or equivalent) on a link from a different
origin. But an attacker could still steal history from any site that he
can inject script into by document.writing the list of URLs into the
page, testing if they are visited, and sending the results back to the
attacker's site. Granted, this is a contrived example and the attacker
could probably do worse than history stealing if we're allowing that he
can inject arbitrary script. But the point is that the threat of
history stealing is not fully mitigated by changes to CSS for
cross-origin links. A complete mitigation of the threat requires both
altering the behavior of getComputedStyle as well as disabling
non-trusted scripts in the document.
Given sufficient granularity in browser capabilities, it is fairly easy
to build a policy to address any particular threat model. Starting from
the threat and working backwards seems to me to force sites to accept
restrictions which may be unexpected or non-intuitive.
>> 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 think it makes sense to have modules that are required for browser
> vendos to implement, but are not required for web authors to enable.
> Is that what you mean? We could make the XSSModule "required" for
> browser vendors to implement instead of just "recommended." I don't,
> however, think that a web author should be required to use the
> XSSModule in order to benefit from the ClickJackingModule (for
> example).
I agree completely with this. "Required" module would apply to browser
vendors only. Sites would not be required to utilize any particular
module, but they would be guaranteed that any required module will be
present in every CSP implementation.
>> 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.
>
> I understand the desire to have "by-default" security, but one problem
> with opt-out CSP rules is that they're hard to change. You can't add
> new opt-out rules in the future because it will break web sites that
> didn't know they were supposed to opt out, so we'd be stuck with an
> initial set of opt-out rules and any rules added in future versions of
> the spec would have to be opt-in. Also, it's tricky to change an
> opt-out rule to be an opt-in rule in the future because web sites may
> be relying on the opt-out behavior.
"By-default" security is definitely the motivation for the opt-in
mechanism currently proposed. I see how a change from opt-in to opt-out
in the future would be impossible, because lots of sites who were once
safe suddenly lose protection. I also see that changing from opt-out to
opt-in would be slightly better: you would have some sites intending to
use inline scripts suddenly break, but they would likely be no less
secure by turning off the scripts. Why, though, would we ever want to
change from an opt-in to an opt-out model? If we agree now (and I'm not
assuming we all do) that opting-in to potentially dangerous features is
a better model, what could change in the Web environment that would make
that decision no longer appropriate?
> If there are a set of behaviors that make sense when used together,
> then maybe providing a concise opt-in directive that enables them all
> would be easier, e.g. "core-xss".
I think it's better to have sites be explicit with their policies, as it
forces them to understand the implications of each part of the policy.
If we provide pre-canned policies, sites may wind up with incorrect
assumptions about what is being restricted.
>> 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.
>
> Could you elaborate a little more on why you feel this way? This seems
> like a major extensibility limitation that would be impossible to
> change in the future.
As we discussed above, no site would be required to use the anti-XSS
features. They could opt not to use those features. The situation I
want to avoid is having browsers advertise (partial) CSP support and
have websites incorrectly assume that they are getting XSS protection
from those browsers. Also, it seems unlikely to me that successful
mitigations can be put in place for the other threats if XSS is still
possible (I can provide examples if people are interested, but I have
to run to catch a train, unfortunately). If we can agree that XSS is
the main threat that we want to address with CSP, then I think we can
also agree to make it a required module.
-Brandon
(Really appreciate everyone's feedback, BTW)
Mike Ter Louw
> 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:
>
> 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).
Part of the value of the threat-centric module approach is it
facilitates analysis of the defensive efficacy of CSP directives. This
can point us to additional policies that are needed for more complete
coverage, and reveal policies that are superfluous (I'm not saying any
existing proposed policy is useless) and browser vendors need not
implement. However, as Lucas rightly pointed out, the correctness of
this analysis is dependent on our awareness and understanding of threats.
If browser implementers are to pick and choose among CSP policies to
support (besides XSS related ones, we agree), there should ideally be
some reference that indicates the combined set of policies that are
needed to mitigate each threat. This can aid browser implementers in
deciding which policies to implement. For instance, if some browser
vendor wants to support CSP protection against CSRF attacks, the vendor
should know that it's of limited use to only strip cookies from form
submissions; form action URIs must also be constrained to a set of
trusted origins.
Perhaps the spec can have an appendix recommending sets of directives
for several significant threats, based on some thorough analysis of each
threat, citing known capabilities and limitations of each set. This can
benefit the spec writers, browser implementors and web developers.
Mike
Daniel Veditz
> Any ideas for how best to address the redirect problem?
In the existing parts of CSP the restrictions apply to redirects. That
is, if you only allow images from foo.com then try to load an image from
a redirector on foo.com it will fail if the redirection is to some other
site. (This has turned out to be an annoying part of CSP to implement as
redirects happen deep in the network library far from the places that
have the context to enforce this rule)
Likewise your anti-csrf rules should propagate through redirects for
consistency.
Adam Barth
> Take XSS and history stealing for example. Assume these are seperate
> modules and each is responsible for mitigating its respective threat.
> Presumably the safe history module will prevent a site from being able
> to do getComputedStyle (or equivalent) on a link from a different
> origin. But an attacker could still steal history from any site that he
> can inject script into by document.writing the list of URLs into the
> page, testing if they are visited, and sending the results back to the
> attacker's site. Granted, this is a contrived example and the attacker
> could probably do worse than history stealing if we're allowing that he
> can inject arbitrary script. But the point is that the threat of
> history stealing is not fully mitigated by changes to CSS for
> cross-origin links. A complete mitigation of the threat requires both
> altering the behavior of getComputedStyle as well as disabling
> non-trusted scripts in the document.
I don't think this argument makes sense. When people complain about
history stealing, e.g. on
https://bugzilla.mozilla.org/show_bug.cgi?id=147777, they're not
worried about the case when their site has XSS. They're worried about
a much weaker attacker who simply operates a web site.
> Why, though, would we ever want to
> change from an opt-in to an opt-out model?
I don't think we'll want to change in the future. We should pick the
better design now and stick with it (whichever design we decide is
better).
> I think it's better to have sites be explicit with their policies, as it
> forces them to understand the implications of each part of the policy.
> If we provide pre-canned policies, sites may wind up with incorrect
> assumptions about what is being restricted.
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?
> The situation I
> want to avoid is having browsers advertise (partial) CSP support and
> have websites incorrectly assume that they are getting XSS protection
> from those browsers.
I don't understand. There is no advertisement mechanism in CSP. Do
you mean in the press?
What's actually going to happen is that thought leaders will write
blog posts with sample code and non-experts will copy/paste it into
their web sites. Experts (e.g., PayPal) will read the spec and test
various implementations.
As for the press, I doubt anything we write in the spec will have much
impact on how the press spins the story. Personally, I don't care
about what the press says. We should design the best mechanism on a
technical level.
> Also, it seems unlikely to me that successful
> mitigations can be put in place for the other threats if XSS is still
> possible (I can provide examples if people are interested, but I have
> to run to catch a train, unfortunately).
It seems very reasonable to mitigate history stealing and ClickJacking
without using CSP to mitigate XSS. As a web developer, I can't do
anything about history stealing myself. I need help from the browser.
On the the other hand, I can do something about XSS myself.
> If we can agree that XSS is
> the main threat that we want to address with CSP, then I think we can
> also agree to make it a required module.
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 have a few more minor points, but we can get to those after we
settle the above two.
I think the way forward is for me (or someone else if they're
interested) to write up our current thinking on the wiki.
Adam
Brandon Sterne
> On Thu, Oct 22, 2009 at 5:22 PM, Brandon Sterne<bst...@mozilla.com> wrote:
>> But the point is that the threat of
>> history stealing is not fully mitigated by changes to CSS for
>> cross-origin links. A complete mitigation of the threat requires both
>> altering the behavior of getComputedStyle as well as disabling
>> non-trusted scripts in the document.
>
> I don't think this argument makes sense. When people complain about
> history stealing, e.g. on
> https://bugzilla.mozilla.org/show_bug.cgi?id=147777, they're not
> worried about the case when their site has XSS. They're worried about
> a much weaker attacker who simply operates a web site.
Granted, it was a contrived example. Here's another try: say we have
the theoretical CSRF module that does a perfect job of stopping the
browser from sending spurious requests to a site that originate from
some other site. The site would still be vulnerable to forged same-site
requests if an attacker is able to inject script or other content into
the site itself. You might say "well, *cross-site* request forgery is
mitigated so our obligation is met", but the broader forged request
threat isn't completely sealed off. A site will still need additional
policy to be secured against request forgery.
It's challenging to make this case for capability-based modules given
only the current set of known web app threats. We know that future
attacks will be based on the combination of browser capabilities. If we
can do a good job of enumerating those capabilities and providing policy
"levers" to restrict them we'll be able to address new threats that
arise in the future with new policies, which can be deployed overnight
by websites, rather than new modules which take at least one browser
release cycle plus a policy change by the websites to take advantage of
the module.
FWIW, I'm actually not hearing you object strongly to the
capability-based module system but rather that you're pointing out
(admitted) weakness in my earlier example. Do I have that right? Are
others still preferring a threat model based approach to the modules, or
can we close this issue?
>> Why, though, would we ever want to
>> change from an opt-in to an opt-out model?
>
> I don't think we'll want to change in the future. We should pick the
> better design now and stick with it (whichever design we decide is
> better).
Well, I personally think that safe-by-default (opt-in to inline scripts,
etc.) is a better design because it forces sites to be more explicit
with what they are permitting and it is consistent with the white list
approach used throughout the model. I've stated it elsewhere, but we
definitely want to avoid sites thinking they are protected when they are
not, in fact.
>> I think it's better to have sites be explicit with their policies, as it
>> forces them to understand the implications of each part of the policy.
>> If we provide pre-canned policies, sites may wind up with incorrect
>> assumptions about what is being restricted.
>
> 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?
I apologize, but I don't understand this question. What is the normal
behavior we are talking about changing in this example?
>> The situation I
>> want to avoid is having browsers advertise (partial) CSP support and
>> have websites incorrectly assume that they are getting XSS protection
>> from those browsers.
>
> I don't understand. There is no advertisement mechanism in CSP. Do
> you mean in the press?
Yes, in the press e.g. some table on a web developer site showing "CSP
support in all major browsers" but only a subset supporting the core XSS
part.
> What's actually going to happen is that thought leaders will write
> blog posts with sample code and non-experts will copy/paste it into
> their web sites. Experts (e.g., PayPal) will read the spec and test
> various implementations.
>
> As for the press, I doubt anything we write in the spec will have much
> impact on how the press spins the story. Personally, I don't care
> about what the press says. We should design the best mechanism on a
> technical level.
We're in total agreement here.
>> Also, it seems unlikely to me that successful
>> mitigations can be put in place for the other threats if XSS is still
>> possible (I can provide examples if people are interested, but I have
>> to run to catch a train, unfortunately).
>
> It seems very reasonable to mitigate history stealing and ClickJacking
> without using CSP to mitigate XSS. As a web developer, I can't do
> anything about history stealing myself. I need help from the browser.
> On the the other hand, I can do something about XSS myself.
>
>> If we can agree that XSS is
>> the main threat that we want to address with CSP, then I think we can
>> also agree to make it a required module.
>
> I think we're all agreed on this point.
Awesome :-)
> Our current disagreements appear to be:
>
> 1) Whether frame-src should be in the resources module or in the same
> module as frame-ancestor.
I think your suggestion to put in in the content loading module makes
more sense than a "frame loading" module.
> 2) Whether sites should have to opt-in or opt-out to disabling inline
> script and/or eval-like APIs.
I stated my opinion above. I'll wait to hear back from others.
> I have a few more minor points, but we can get to those after we
> settle the above two.
Look forward to hearing them.
> I think the way forward is for me (or someone else if they're
> interested) to write up our current thinking on the wiki.
This is a good idea. We're still coalescing a lot of what has been
discussed over the last two weeks, and that information is living in
several places currently. As we resolve these points, Sid and I will
definitely be updating the spec.
> Adam
Cheers,
Brandon
Daniel Veditz
> 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
Devdatta
+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
Adam Barth
> 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
Devdatta
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 <abarth-...@adambarth.com>:
> On Mon, Oct 26, 2009 at 6:11 PM, Daniel Veditz <dve...@mozilla.com> 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
Daniel Veditz
> I understand the seductive power of "secure-by-default" here.
If only she loved me back.
> 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.
I don't think we're having a technical argument, and we're not getting
the feedback we need to break the impasse in this limited forum. Either
syntax can be made to express the same set of current restrictions.
You're arguing for extensible syntax, and I'm arguing for what will best
encourage the most web authors to "do the right thing".
An argument about whether your syntax is or is not more extensible can
at least be made on technical merits, but what I really want is feedback
from potential web app authors about which approach is more intuitive
and useful to them. Those folks aren't here, and I don't know how to
reach them.
At a technical level your approach appears to be a blacklist. If I'm
understanding you correctly, if there's an empty CSP header then there's
no restriction whatsoever on the page. In our version it'd be a
locked-down page with a default inability to load source from anywhere.
If the web author has left something out they will know because the page
will not work. I'd rather have that than a web author thinking they're
safe when CSP isn't actually turned on for their page.
The bottom line, though, is I'm in favor of anything that gets more web
sites and more browsers to support the concept.
-Dan
Adam Barth
> I don't think we're having a technical argument, and we're not getting
> the feedback we need to break the impasse in this limited forum.
I agree that we're not making progress in this discussion.
At a high level, the approach of letting sites to restrict the
privileges of their own content is a rich space for security
mechanisms. My opinion is that the current CSP design is overly
complex for the use cases it supports and insufficiently flexible as a
platform for addressing future use cases. If I find the time, I'll
send along a full design that tries to improve these aspects along the
lines I've suggested in the foregoing discussion.
Adam
Brandon Sterne
> 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:
I couldn't find a comment that summarizes the model you are proposing so
I'll try to recreate your position from memory of our last phone
conversation. Please correct me where I'm wrong.
I believe you advocate a model where a site specifies the directives it
knows/cares about, and everything else is allowed. This model would
make the default "allow" directive unnecessary. The main idea is to
allow sites to restrict the things it knows about and not have to worry
about inadvertently blocking things it doesn't consider a risk.
My main objection to this approach is that it turns the whitelist
approach we started with into a hybrid whitelist/blacklist. The
proposal doesn't support the simple use case of a site saying:
"I only want the following things (e.g. script and images from myself).
Disallow everything else."
Under your proposal, this site needs to explicitly opt-out of every
directive, including any new directives that get added in the future.
We're essentially forcing sites to maintain an exhaustive blacklist for
all time in order to avoid us (browsers) accidentally blocking things in
the future that the site forgot to whitelist.
> 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.
Under your proposed model, a site will continue to "function correctly"
only in the sense that nothing will be blocked in newer implementations
of CSP that wouldn't also have been blocked in a legacy implementation.
From my perspective, the blocking occurs when something unexpected by
the site was included in the page. In our model, the newer
implementation, while potentially creating an inconsistency with the
older version, has also potentially blocked an attack.
Are you suggesting that a blocked resource is more likely to have come
from a web developer who forgot to update the CSP when s/he added new
content than it is to have been injected by an attacker? This seems
like a dangerous assumption. All we are getting, in this case, is
better consistency in behavior from CSP
implementation-to-implementation, but not better security.
> 2) Modularity. We would be free to group the directives into whatever
> modules we liked because there would be no technical interdependence.
I actually don't see how opt-in vs. opt-out has any bearing at all on
module interdependence. Maybe you can provide an example?
Let's also not forget that CSP modularity really only helps browser
vendors. From the perspective of websites, CSP modules are just one
more thing that they have to keep track of in terms of which browsers
support which modules. I support the idea of making it easier for other
browser vendors to implement CSP piecemeal, but our primary motivation
should remain making the lives of websites and their users better.
> 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.
In the case of an injected header, this is already the case now. We
intersect both policy sets, resulting in a combined policy more
restrictive than either of the two separate policies.
If we are talking about an attacker who can inject an additional
directive into an existing CSP header then, yes, the attacker could
"relax" the policy intended to be set by the site. I'm not sure how
much I care about this case.
> 4) Syntactic Simplicity. Instead of two combination operators, ";"
> for union and "," for intersection, we could simply use "," and match
> standard HTTP header syntax.
Okay, sure.
> 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".
Those seem equivalent to me, so I'm not sure which model your example
favors.
In general, I'm slightly skeptical of the view that we need to base our
design around the fact that admins will copy-paste from tutorials.
Sure, this will happen in practice, but what is the probability that
such a site is a high value target for an attacker, and by extension how
important is it that such a site gets CSP right? Remember, a site
cannot make their security profile any worse with CSP than without it.
I do want CSP to be easy to get right. I should do some homework and
collect some stats on real world websites to support the following
claim, but I still maintain that a HUGE number of sites will be able to
benefit greatly from a minimal policy such as "allow 'self'". Even
"allow *" would be a gigantic improvement in terms of blocking all the
common XSS vectors.
My contention is that CSP tutorials should (and will if we evangelize
properly) instruct sites to start with a minimal policy such as "allow
'self'" and incrementally add policy until the site behaves as expected.
This approach will result in minimal policy set and will tend to be
optimal in terms of bandwidth and risk profile.
Cheers,
Brandon
Gervase Markham
> 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:
CSP's precursor, Content Restrictions
http://www.gerv.net/security/content-restrictions/
was designed to be purely subtractive, for many of the technical reasons
you state. And I do continue to think that it's a better choice.
Why write the spec in terms of "restrictions" rather than "capabilities"?
Backwards-compatibility. Current user agents are fully capable. Any
restrictions we can place on content to possibly mitigate XSS is
therefore a bonus. Also, if it were in terms of capabilities, you might
require UI if the capabilities the page wanted conflicted with the
desires of the user. This is a UI-free specification, which is a feature.
Gerv
Gervase Markham
> On 27/10/09 09:33, Adam Barth wrote:
>> 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:
>
> CSP's precursor, Content Restrictions
> http://www.gerv.net/security/content-restrictions/
> was designed to be purely subtractive, for many of the technical reasons
> you state. And I do continue to think that it's a better choice.
Having said that, it doesn't preclude the very presence of the header
implying some restrictions. It just means that if the presence of the
header implies some restrictions, you shouldn't be able to remove those
restrictions by adding tokens to the header.
Gerv