W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2012

Re: CSP and cross-frame communication

From: David Bruant <bruant.d@gmail.com>
Date: Mon, 05 Mar 2012 23:46:19 +0100
Message-ID: <4F55423B.4000207@gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Le 05/03/2012 22:23, Daniel Veditz a écrit :
> On 3/5/12 11:58 AM, David Bruant wrote:
>> Do you have an example of an XSS that can be avoided by the specific
>> prevention of eval? I'm obviously talking about a case where eval is
>> legitimate.
>> People who misuse eval will at best not be aware of CSP and at worst say
>> "it broke my code" and disable it right away when trying it.
> The web has built up a history of using eval() in sloppy and
> unnecessary ways. Eval can be used carefully, but the CSP default
> encourages thought about safer alternatives to many current uses.
or encourages to not use CSP (or at least this part). I agree with your
intention, but I disagree on the means. Since CSP is an opt-in, I don't
really understand what would be the benefit of opting in to purposefuly
break your own code unless there is some serious reward.
The change in the HTML script execution model is such a reward and puts
the web developer in control (for the first time since the invention of
JavaScript?) of what is executed and what isn't.

Disabling eval is just disabling one function. I agree it's been misused
with security issues as consequences, but people who care about security
either use eval carefully or don't use it. I still don't see the benefit
of this directive.

More broadly, has there been a survey of what web developers care about
in terms of security before starting CSP?
One sure thing with CSP opt-ins is that no one is going to be forced to
use them, so you might want to be sure that some people are interested
in using them.

> Let's say you're building a complex/commercial site. Even if -you-
> use eval safely in your own code, are you confident enough that all
> your 3rd-party script providers are as careful such that you're
> willing to roll the dice by enabling eval support? Maybe you are,
> and in that case enable eval in good health.
What if the third-party has scripts that contains eval?
Should I be:
* refusing 3rd-party scripts?
* disabling them?
* let CSP break them by default?
"sorry, I know we had a deal, but we broke your script because we
thought it might compromise our website" or "we refuse to go on business
with you because your code uses the wrong function" are rarely
acceptable marketing arguments

None of these solutions are acceptable to me. Once again, the all or
nothing sort of trade-off is not a good solution.

If I were to use 3-rd party scripts with potentially eval in it, I would:
1) figure out what I want the scripts to do
2) use a Caja-like rewriter to give them the capabilities they need
3) and nothing more (forcing myself to split 2 and 3, because each part
is important)
Specifically, for eval, I can provide them a limited version of it.

For language-based issues (like restricing usages of a function like
eval), I think that a language-based solution is better suited.
Likewise, for a platform-based issue (like script execution model), a
platform-based solution (like CSP) is the right fit.

Received on Monday, 5 March 2012 22:46:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:27 UTC