Re: Whitelisting external resources by hash (was Re: Finalizing the shape of CSP ‘unsafe-dynamic’)

CSP requires unsafe-inline for script-src for executing
onchange='jsfunc();'. jQuery event handlers are an alternative but there
are some mobile browsers that don't support jQuery event handlers.

"script-src 'self';" - Should this allow calling js functions with
onchange, onclick, etc?

On Wed, Jun 8, 2016 at 11:29 AM, Artur Janc <aaj@google.com> wrote:

> On Wed, Jun 8, 2016 at 1:50 AM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> (risk of looking stupid here)
>>
>> Why isn't a nonce isn't appropriate for truly static content?  Yes, it
>> doesn't change, but the content is static.  Is it to defend against the
>> case that the static content has DOMXSS that happens to do a
>> parser-inserted script and the attacker can control it to propagate the
>> nonce there?
>>
>
> Yes, this is the problem. Unfortunately XSS in static content is commonly
> caused by the use of APIs which parse markup and insert the result into the
> DOM, e.g. innerHTML and document.write().
>
>
>>
>> On Tue, Jun 7, 2016 at 12:59 PM Mike West <mkwst@google.com> wrote:
>>
>>> On Tue, Jun 7, 2016 at 8:27 PM, Artur Janc <aaj@google.com> wrote:
>>>
>>>> - You could whitelist specific URLs for script-src without risking
>>>> redirect-based whitelist bypasses. For example `script-src 'self'
>>>> ajax.googleapis.com/totally/safe.js` is an ineffective policy if there
>>>> is an open redirect in 'self' due to the ability to load other scripts from
>>>> ajax.googleapis.com caused by CSP's path-dropping behavior. A hash
>>>> would avoid this problem.
>>>>
>>>
>>> I think you might have something in mind other than just hashing the
>>> URL? It's not clear to me how a different spelling of the URL would
>>> mitigate the issues that lead to the path-dropping-after-redirect behavior.
>>> Denying redirects entirely, perhaps?
>>>
>>>
>>>> - It would allow more flexibility in whitelisting exact script URLs.
>>>> Using a traditional URL whitelist it's not possible to have a safe policy
>>>> in an application which uses JSONP (script-src /api/jsonp can be abused by
>>>> loading /api/jsonp?callback=evilFunction). With hashes you could allow
>>>> SHA256("/api/jsonp?callback=goodFunction") but an attacker could not use
>>>> such an interface to execute any other functions.
>>>>
>>>
>>> Is hashing important here? Would extending the source expression syntax
>>> to include query strings be enough?
>>>
>>>
>>>> - It would work with a policy based on 'unsafe-dynamic' /
>>>> 'drop-whitelist' -- even if the host-source is dropped, the hash would
>>>> offer a way to include specific external scripts.
>>>>
>>>> For CSP to become a useful XSS protection we will almost certainly have
>>>> to move away from the whitelist-based model.
>>>>
>>>
>>> I think we agree that Google will certainly need to move away from the
>>> whitelist-based model. Though I agree with you that a nonce-based model is
>>> simpler to deploy for many sites, GitHub seems to be a reasonable
>>> counter-example to general necessity.
>>>
>>>
>>>> Dynamic applications can often use nonces instead, but for static
>>>> content, or situations where using nonces would be difficult, I think
>>>> hashes are a good solution -- one of their main benefits is that they're
>>>> already in the spec and any expansion of their capabilities would be a
>>>> relatively small change. (Another upside is that they can be used in a
>>>> backwards-compatible way alongside a whitelist.)
>>>>
>>>
>>> I still don't understand why hashing a URL is useful. :(
>>>
>>> -mike
>>>
>>
>