Re: Hashes/Nonce Source and unsafe-inline

Woohoo, finally catching up.

Dev, this was discussed during the last call. The concerns were that
while this would help increase adoption to some degree, it's like
taking two steps forward and two steps back in the overall scheme of
things. An attacker who could inject any inline content could likely
add the nonce themselves (if a nonce is lying in the DOM somewhere
else) and there's no way to differentiate legit inline events vs
injected inline events (besides Pete's suggestion above). The group
also felt that this pattern is not very common (citation needed) and
could be achieved with external script in almost every case (citation
needed).  Lastly, adding this new source expression would be
significantly difficult to implement for the browser folk and adds a
small amount of complexity to the spec.

This change is backwards compatible with solid protection for
everyone, but unfortunately cannot handle that use case.

Please let me know if this doesn't make sense or answer your question
satisfactorily. The call was a long time ago :-/

(protip: if you have an action to send an email, do it as soon as you hang up)

On Tue, Dec 17, 2013 at 2:02 PM, Pete Freitag <pete@foundeo.com> wrote:
> I was thinking just the script would be hashed, eg: "breakEverything()"
>
>
>
>
> On Tue, Dec 17, 2013 at 4:50 PM, Garrett Robinson <grobinson@mozilla.com>
> wrote:
>>
>> On 12/16/2013 10:28 AM, Pete Freitag wrote:
>> > On Fri, Dec 13, 2013 at 4:47 PM, Dionysis Zindros <dionyziz@gmail.com
>> > <mailto:dionyziz@gmail.com>> wrote:
>> >
>> >     The current spec is explicit about allowing nonces and hashes for
>> > only
>> >     inline script use
>> >
>> >
>> > The current spec mentions hashes and nonce in the style-src section, but
>> > in the Valid Hashes
>> > section,
>> > https://dvcs.w3.org/hg/content-security-policy/raw-file/8db37e53da82/csp-specification.dev.html#valid-hashes
>> > it only mentions script. I would expect them to work in style-src as
>> > well as script-src does the valid-hashes section need to be updated or
>> > is the style-src section wrong?
>>
>> That's an accidental omission. Hashes can be used to whitelist *inline*
>> scripts *and* styles.
>>
>> > Also wouldn't it be possible in theory to solve Dev's problem by
>> > allowing hashes of inline event handers? This could also potentially
>> > help ease adoption in legacy applications. I don't know what kind of
>> > challenges that would present for the browser vendors to implement,
>> > obviously not anything I would want holding up CSP1.1.
>>
>> Could you be more specific? I'm pretty sure Dev is referring to
>> something akin to
>>
>> <button onclick="breakEverything()">Save</button>
>>
>> Are you suggesting that we hash the contents of <button>? It seems like
>> we need to whitelist the *executable* content, not content associated
>> with executable content, to get security. Otherwise, an attacker could do
>>
>> <button onclick="doSomethingEvil()">Save</button>
>>
>> and get it to run.
>>
>> Maybe we could do something like we do with setTimeout, where if the
>> contents of the event handler is just one function then we let it run?
>> But IMHO that is way over-complicated.
>>
>> -Garrett
>>
>> > --
>> > Pete Freitag
>> > http://foundeo.com
>> > http://content-security-policy.com/ - CSP Quick Reference
>>
>

Received on Tuesday, 14 January 2014 18:42:07 UTC