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

RE: Script-nonce policies

From: Hill, Brad <bhill@paypal-inc.com>
Date: Sun, 4 Nov 2012 17:08:01 +0000
To: Adam Barth <w3c@adambarth.com>, Joel Howard Willis Weinberger <jww@cs.berkeley.edu>
CC: Eric Rescorla <ekr@rtfm.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E2D818E@DEN-EXDDA-S12.corp.ebay.com>
If we move towards a generic nonce policy, we should review and consider prior work in this area, specifically Gareth Heyes' JSLR project (http://www.thespanner.co.uk/2012/06/05/jslr/) that builds on earlier, similar constructs by Eduardo Vela Nava and Mario Heiderich.

JSLR, in addition to providing a nonce, also requires secure randomization of identifiers for single and double quote characters to protect against injection in attribute contexts.

-Brad Hill

> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Friday, November 02, 2012 2:57 PM
> To: Joel Howard Willis Weinberger
> Cc: Eric Rescorla; public-webappsec@w3.org
> Subject: Re: Script-nonce policies
> 
> On Fri, Nov 2, 2012 at 11:14 AM, Joel Howard Willis Weinberger
> <jww@cs.berkeley.edu> wrote:
> > Perhaps I've missed this in previous conversations, but why is
> > script-nonce restricted only to scripts?
> 
> I don't think we've discussed that previously.  Up to this point, script-nonce
> has had two goals:
> 
> 1) Let web sites use inline scripts without giving up the XSS protections from
> CSP.
> 2) Give web sites finer-grained control over where they load scripts (finer-
> grained than origin).
> 
> Goal (1) seems valuable.  Goal (2) seems less valuable (to me) now that we
> have directory restrictions that let web sites have finer-grained control over
> where they load scripts by URL.
> 
> > Why not allow other (potentially arbitrary) uses of the nonces for
> > forms, for example? If one is worried about any particular type of
> > element injection, couldn't the nonce attribute be useful? Why not
> > have a more general 'nonce policy' that allows directives of not just 'all'
> > or 'inline', but also 'forms,' 'input', etc?
> 
> That's an interesting idea.  An extreme version of that idea would be to
> require a nonce to whitelist every element.  That might get a bit unwieldy, but
> you could imagine letting the web site specify which tag names would require
> nonces.
> 
> Adam
> 
> 
> > On Fri, Nov 2, 2012 at 10:41 AM, Adam Barth <w3c@adambarth.com> wrote:
> >>
> >> [-public-web-security, +public-webappsec]
> >>
> >> Maybe we should make script-nonce apply only to inline script elements?
> >>
> >> Adam
> >>
> >>
> >> On Fri, Nov 2, 2012 at 2:42 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> >> > As I mentioned in the meeting, script-nonce seems like it would be
> >> > more useful if there was a way to restrict its applicability to
> >> > inline scripts, so I can have a site with a static security policy
> >> > and a small number of inline scripts without having to rewrite
> >> > every page that loads jQuery.
> >> >
> >> > Concrete suggestion: augment script nonce with a "policy" parameter
> >> > such as:
> >> >
> >> > script-nonce <nonce>,<policy> where <policy> == "all" or "inline"
> >> > to mean that the nonce applies to both scripts or just inline scripts.
> >> >
> >> > -Ekr
> >> >
> >>
> >
Received on Sunday, 4 November 2012 17:08:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 4 November 2012 17:08:31 GMT