Re: Comment on Content Security Policy 1.1, Draft of Dec 12 2012

I think an "or" relationship between script-src and script-nonce can be
very convenient for developers, but doesn't it pose a security problem with
dynamically added CSP rules meta tags? If I understand correctly, it would
violate the "only stricter policies can be applied dynamically" rule. (
http://lists.w3.org/Archives/Public/public-webappsec/2012Dec/0054.html)

Example:
A certain site has very strict CSP that only enable inline scripts with a
certain nonce.
Assuming that the nonce was compromised (not random enough, etc) and a
malicious script was able to run, that script can now add dynamic meta tags
that permit 'script-src' from its malicious host, permitting it to send
information (session id, cookies, etc) to its host and fetch more malicious
code if necessary.

I realize the above example may not be a very common case, and it can be
circumvented by imposing more restrictions on dynamically added CSP rules,
but wouldn't a "script-inline-nonce" policy that has no effect on
"script-src" be a better separation?

Yoav



On Sat, Jan 5, 2013 at 10:16 PM, Adam Barth <w3c@adambarth.com> wrote:

> At Google, we did some prototype implementations of CSP in several
> large web applications, and we found that the "or" behavior was very
> useful for whitelisting one or two critical inline script blocks that
> couldn't be moved out-of-line for performance reasons.
>
> As similar issue arises when using Google Analytics.  The script
> Google Analytics asks you to include in your page is roughly the
> following:
>
> var _gaq = _gaq || [];
> _gaq.push(['_setAccount', 'UA-XXXXXX-X']);
> _gaq.push(['_trackPageview']);
>
> (function() {
>   var ga = document.createElement('script'); ga.async = true;
>   ga.src = 'https://ssl.google-analytics.com/ga.js';
>   var s = document.getElementsByTagName('script')[0];
> s.parentNode.insertBefore(ga, s);
> })();
>
> The first stanza sets up an array that you can push commands onto, and
> then the actual script that executes scripts loads asynchronously (and
> then executes the commands once it loads).
>
> When using CSP, you still want to create the _gaq using an inline
> script block so that you can start pushing command immediately while
> still avoiding blocking the page to load an external script.  The
> script-nonce directive lets you do this without giving up your XSS
> protections.
>
> It's not really a problem to add https://ssl.google-analytics.com to
> your script-src directive.  However, it is annoying to need to add the
> nonce to every other script block, even the ones that you've already
> whitelisted via script-src (e.g., 'self').  With the "or" semantics,
> you can use CSP as you would before and just use the nonce to
> whitelist the one performance-critical inline script block.
>
> Adam
>
>
> On Tue, Dec 18, 2012 at 10:38 AM, Tanvi Vyas <tanvi@mozilla.com> wrote:
> > I think the "or" behavior would be helpful to sites that have sources
> they
> > don't know about until the last minute (i.e. ad placement).  The server
> > could inject a script nonce into the script tag and the csp header.
>  Then it
> > can later fill in the src attribute of the script tag once it knows
> which ad
> > is going to be placed on the site.  With the "and" behavior, the server
> > would have to wait until it has the advertisement before generating the
> csp
> > header (specifically the script-src directive).
> >
> > ~Tanvi
> >
> > On Dec 18, 2012, at 6:44 AM, Mike West <mkwst@google.com> wrote:
> >
> > Hi Flo, thanks for the feedback. I'll add an example to make the section
> > more clear.
> >
> > Regarding the behavior in general, I do think there's room for argument
> > about the interaction between the two directives. The currently specified
> > "and" behavior makes sense to me, and seems to have the best security
> > properties as it asks the developer to explicitly whitelist all possible
> > sources of script for a page via 'script-src', and then specifically
> allow
> > each in a given context via the nonce.
> >
> > It does seem to be surprising, however. You're certainly not the first to
> > note that the current behavior doesn't match your expectations.
> >
> > Changing the directive to more "or"ish behavior would mean that, given a
> > nonce, script from untrusted origins could be loaded. I don't think
> there's
> > a way to exploit that without already having script access to the page,
> but
> > I haven't thought about it enough to be sure.
> >
> > I'm interested in others' opinions. :)
> >
> > -mike
> >
> > --
> > Mike West <mkwst@google.com>, Developer Advocate
> > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> >
> >
> >
> > On Wed, Dec 12, 2012 at 4:51 AM, Florian Lasinger <florian@lasinger.org>
> > wrote:
> >>
> >> @chapter „4.12.2 Interaction with the script-src directive“
> >>
> >>
> >>
> >> The document contains one example for the case
> >>
> >> „nonce provided and correct / src not allowed by script-src directive“.
> >>
> >>
> >>
> >> There should be an example for the inverse case
> >>
> >> „no nonce provided / src allowed by script-src directive“.
> >>
> >>
> >>
> >> As it currently stands, the second case script would be rejected because
> >> it doesn’t have a nonce.
> >>
> >> Intuitively I would assume the script to be safe because it comes from a
> >> whitelisted origin.
> >>
> >>
> >>
> >> Therefore I would propose to restrict the relevant enforcing rule to
> only
> >> script tags with content.
> >>
> >>
> >>
> >>
> >>
> >> Sincerely,
> >>
> >> Flo
> >>
> >>
> >
> >
>
>