Re: Making it easier to deploy CSP.

On Wed, Feb 17, 2016 at 7:09 AM, Conrad Irwin <conrad.irwin@gmail.com>
wrote:

>
>
> On Tuesday, February 16, 2016, Artur Janc <aaj@google.com> wrote:
>
>> On Mon, Feb 15, 2016 at 1:46 AM, Conrad Irwin <conrad.irwin@gmail.com>
>> wrote:
>>
>>> The behaviour of `unsafe-dynamic` you propose seems pretty confusing to
>>> describe to me (you have to distinguish between "parser-inserted" and not),
>>> and I'm not sure how it integrates with other browser functionality.
>>>
>>
>> This could likely be simplified to: *scripts created with
>> document.createElement('script') *without much loss of generality.
>>
>
> I like this a lot more, would be happy with this being the definition and
> having the document responsible for blessing the script at element creation
> time; in general I don't think it's useful to transfer script elements
> between documents so it would be good to have the policy prevent scripts
> that are appended or copied around from running unless they were created by
> the same documents createElement.
>
>
>
>>
>> Interesting... I think either behavior would be acceptable for the
>> purposes of unsafe-dynamic so it's a question of what makes more sense for
>> the spec and implementations. If you explicitly call
>> appendChild([script-from-another-document]) then you are presumably doing
>> it intentionally so the script could be blessed to execute. At the same
>> time, we could stick to the very narrow definition of "script needs to be
>> created with document.createElement()" and in practice the value of
>> unsafe-dynamic wouldn't be diminished (the majority of JS APIs and widgets
>> will be covered).
>>
>>
>> These are both fair points. I mentioned some of our original rationale
>> for requiring nonces and ignoring the whitelist in my reply to Martin --
>> overall, there is precedent for adding new CSP directives in a
>> backwards-compatible way, e.g. nonce-source causes 'unsafe-inline' to be
>> ignored, so it seemed like continuing along the same vein might be
>> preferable.
>>
>> Do you see any alternative approach which would not require user-agent
>> detection? (I'm worried that it could be another non-trivial obstacle to
>> CSP adoption, on top of some already difficult challenges).
>>
>
> I can't think of an easy one, so this may be a case for pragmatism beats
> purity. The better approach is obviously the manual nonce one in all of
> your code :) this is very much a transitionary hack, so it would be nice if
> browsers don't have to support this long term anyway...
>

I totally agree, ideally this would not be needed and JS APIs would be
CSP-aware so that they would grab nonces from the page and pass them when
loading sub-scripts. Unfortunately, judging from the poor track record
we've had with making such libraries compatible with other parts of CSP
(e.g. unsafe-eval) I'm afraid that it would take years, and authors
couldn't adopt a nonce-based policy until this happens. A good way to get
traction with API owners for such work is to increase the adoption of CSP
-- with the use of unsafe-dynamic or otherwise -- because then it gets much
easier to convince them to make their libraries well-behaved and support
their users' CSP policies.

FWIW the interesting alternative approach mentioned by Devdatta (UA
detection + JS polyfill) would be functionally similar, but would also mean
that developers would bear the brunt of the implementation cost. In my
experience, it's more effective if we can "externalize" the legwork
necessary to adopt CSP, for example by building tools to determine a script
whitelist based on an application crawl, calculating hashes for any inline
scripts, automatically adding nonce attributes in template systems, etc.

If we could give developers a working, safe policy which requires minimal
application changes -- besides configuring their template system to inject
script nonces, which we realistically can't give up -- we'd be in a much
better position to make CSP successful in the long term. unsafe-dynamic
attempts to nudge things in this direction while also providing you with a
safer policy than one based on whitelists.


>
>
>>
>> Cheers,
>> -Artur
>>
>>
>>
>>> Sent via Superhuman <https://superhuman.com/?utm_source=signature>
>>>
>>> On Sun, Feb 14, 2016 at 3:58 PM, Martin Thomson<martin.thomson@gmail.com
>>> >wrote:
>>>
>>>> On 14 February 2016 at 16:39, Devdatta Akhawe <dev.akhawe@gmail.com>
>>>> wrote:
>>>>
>>>> Personally, my preference for increasing complexity is in the
>>>> order---web apps and then browsers and then standards.
>>>>
>>>> The priority of constituencies would (perfectly) disagree on this point.
>>>>
>>>> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>>>>
>>>> The thing I'm trying to wrap my head around is how this fits with the
>>>> general CSP design pattern. How does adding this directive narrow the set
>>>> of things that are permitted? It actually appears to do the opposite. The
>>>> purpose being to give dynamically inserted scripts an exemption.
>>>>
>>>
>>>
>>