Re: 'strict-dynamic' syntax (was Re: On the Insecurity of Whitelists and the Future of CSP)

On 9/8/16 1:25 PM, Artur Janc wrote:
> - There is already an "ignore" mechanism in CSP, which works within a
> single directive, namely the presence of 'nonce-*' or 'sha*' ignores
> 'unsafe-inline' for backwards-compatibility.

... which was an ugly but necessary hack in CSP2. The directive-level
override was built-in from the beginning, with *-src directives
overriding default-src, and later frame-src overriding child-src.

> you need to pay attention to different directives deciding the same
> behavior, understand which wins out in which browser, etc. I'd argue
> it's just as confusing, if not more :(

Seems much easier to understand to me: use script policy-A in old
browsers and script policy-B in new browsers, one or the other, a choice
of two. with 'strict-dynamic' a keyword you are mentally understanding a
policy as one thing until you hit that keyword--which could be
anywhere--and then you have to backtrack to figure out what parts are
actually ignored.

> - A new directive likely wouldn't be able to completely ignore
> script-src, because it would need the nonce defined therein. Or
> otherwise we would force the developer to include the nonce in both
> places (script-src 'nonce-foo123' [something]; new-script-src
> 'nonce-foo123';) for backwards-compatibility, which seems fairly inelegant.

Yes, if you used the nonce in the CSP2-level policy you'd have to repeat
it. I agree it's more verbose but that's not necessarily inelegant.

> - I believe that so far we've had a one-to-one mapping between
> directives and resources (with this exception of default-src), but this
> would change in this model. Perhaps this is okay, but it also is a bit
> of a departure from the status quo.

I wouldn't call default-src an exception, it's fundamental. We also have
the possibility of iframe src being controlled by one of two different
policies (not counting default-src).

> many applications can avoid the whitelist altogether to get around
> the adoption/maintenance difficulties, and serve a policy such as
> "script-src 'nonce-foo' 'strict-dynamic' 'unsafe-inline' https:" where
> the last two entries will be ignored.

That policy does almost nothing to protect a site in a browser that does
not honor 'strict-dynamic'. The only real benefit would be not having to
UA-sniff in order to not offer a CSP policy at all to older browsers.

> Second, if the developer wants to
> maintain a whitelist for older browsers, it's easy to split this into
> two separate CSP policies, where the original one will be unchanged, and
> the new CSP header will only focus on nonce enforcement (same policy as
> above). We have some experience that suggests that even developers
> unfamiliar with CSP can grok this.

Yes, that works. Duplicating most of two entire policies seems more
'inelegant' to me than duplicating a nonce across two directives, but
that's the kind of clarity I was going for.

-Dan Veditz

Received on Friday, 9 September 2016 07:32:48 UTC