Re: Updated script hash proposal (non spec text)

> If the CSP policy specifies both nonce and hash sources, is the nonce source ignored for inline scripts? That is, an inline script with the right nonce value but wrong hash value will be ignored because a hash-src was given? This is probably the right behavior but does seem at odds with how the rest of the CSP src directives work.

I don't really have an opinion on this.

> Can you elaborate on that? What was the complication? I am curious.

This is where I wish I saved my notes :( I don't remember what this
concern was, but I'm pretty sure someone else brought it up at some
point. Perhaps it was around not being able to sniff user agents and
sending a variety of hash combinations rather than "the strongest hash
the user agent knows about".

On Sat, Oct 19, 2013 at 8:00 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
>> Any inline script whose computed hash value
>> does not match a hash specified in the hash sources should not be
>> executed
>
> If the CSP policy specifies both nonce and hash sources, is the nonce
> source ignored for inline scripts? That is, an inline script with the
> right nonce value but wrong hash value will be ignored because a
> hash-src was given? This is probably the right behavior but does seem
> at odds with how the rest of the CSP src directives work.
>
>> If multiple hashing algorithms are specified in the CSP header, the
>> browser must compute all possible hashes for each inline script block.
>> If the computed hash matches any computed hash in the header with a
>> matching algorithm+digest length, the script should execute. There was
>> talk of limiting this to one algorithm per header, but CDNs complicate
>> things.
>
> Can you elaborate on that? What was the complication? I am curious.
>
> thanks
> Dev

Received on Monday, 21 October 2013 17:01:07 UTC