Re: Content Security Policy

I would suggest that using the RFC 6920 syntax (
http://tools.ietf.org/html/rfc6920) as a source expression is a good fit
with the current pattern of using nonces as such.  Nicholas Green had a
start at a proposal, (
http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0052.html) but
I think it needs to be updated significantly given the direction we've
taken with nonces.  A partial list of what remains to be done to spec out
inline hashes is:

Specify which hash algorithms CSP 1.1 would require support for.

Specify whether and to what extent truncation is allowed.

Specify what to do with the content-type attribute of ni: URIs if we allow
this to be used for non-inline content... or shouldthis be used to
determine the type (css, js, vbs, etc..) of the inline resource?

Specify an algorithm to exactly determine the bytes-to-be-hashed in a
reliable and cross-browser manner.  I would suggest that this should be
defined in terms of the HTML5 parsing algorithm, with some restrictions
such as requiring any resource employing hash sources declare an explicit
encoding.

*shudder* Is canonicalization necessary?  I hope not.

Think about and determine what needs to be covered by the
bytes-to-be-hashed:
   - should attributes of the script tag be included?  (e.g. whether it is
javascript, vbscript, ruby or json?)

Specify algorithm agility behavior
   - what to do if a policy specifies only SHA4 hashes and a user agent
doesn't understand SHA4?  fail?  fallback to unsafe-inline?
   - possibly: if a policy specifies SHA1 and SHA3 hashes of the same
content what should user agent behavior be?  allow all as valid?  only
trust the strongest hashes it understands how to process in a given policy
string?  In the composite policy?

-Brad
<http://tools.ietf.org/html/rfc6920>


On Mon, Jun 17, 2013 at 10:56 AM, Bryan McQuade <bmcquade@google.com> wrote:

> Brad and I just chatted offline & concluded that an attack vector does
> exist for static HTML with unsafe-inline: it would be possible for an
> inline block with a vulnerability to be used to create another inline
> script block that executed some exploit.
>
>
>
> On Mon, Jun 17, 2013 at 1:40 PM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> Just to play devil's advocate, if the HTML is truly being served in a
>> completely static manner, is "unsafe-inline" actually unsafe?  (there
>> should be no inline-content injection vulnerabilities in such a resource)
>>
>>
>> On Mon, Jun 17, 2013 at 10:36 AM, Bryan McQuade <bmcquade@google.com>wrote:
>>
>>> Does CSP support inline scripts and styles in statically served HTML
>>> files? My impression was that nonce only works for dynamic serving. If
>>> that's the case then IMO hashes are warranted to support the static case
>>> alone.
>>>
>>>
>>>
>>> On Mon, Jun 17, 2013 at 1:22 PM, Joel Weinberger <jww@chromium.org>wrote:
>>>
>>>> I'm not particularly against, hashes, but I'm naturally hesitant to add
>>>> more constructs to CSP, especially since the use of nonces seem to
>>>> completely overlap with the use cases for hashes. I think the concern about
>>>> nonce abuse as Yoav pointed out are valid concerns, but I'd be hesitant to
>>>> add a new construct just to cover that particular concern. Put differently,
>>>> I don't see any dramatically different uses for hashes from nonces.
>>>> --Joel
>>>>
>>>>
>>>> On Mon, Jun 17, 2013 at 4:09 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>>
>>>>> +1 for discussing it further.
>>>>>
>>>>> The advantages I see:
>>>>> * The author is authorizing a *specific* script/style and can do so
>>>>> using static configuration
>>>>>   - No need for a dynamic backend that changes the nonce for each
>>>>> request..
>>>>>   - This can simplify deployment, resulting in more people using it
>>>>> * I'm afraid of authors abusing nonces, sending the same nonce over
>>>>> and over as means to "bypass" CSP
>>>>>   - Offering an alternative to nonce can reduce that risk
>>>>>
>>>>> The complications I can think of:
>>>>> * Make sure that either hashes don't break with small white-spaces
>>>>> removals, text encoding changes, etc.
>>>>>   - An alternative is tools that can give authors the resulting hash
>>>>> for a specific script/style. (e.g. inside the Web inspector tools). That
>>>>> may be more fragile, though.
>>>>>
>>>>> All in all, I think hashes can make it easier for "copy&paste" authors
>>>>> to integrate CSP. They can also make deployment of third party scripts
>>>>> easier.
>>>>>
>>>>>
>>>>> On Sat, Jun 15, 2013 at 8:00 AM, Neil Matatall <neilm@twitter.com>wrote:
>>>>>
>>>>>> This is the script-hash proposal. I would love it if we discussed
>>>>>> this more as it has numerous benefits over a nonce as well as complications
>>>>>> :)
>>>>>> On Jun 15, 2013 1:11 AM, "п∙п╡пҐпЁп╣пҐп╦п╧ п╞я─п╣п╪п╣пҐп╨п╬" <
>>>>>> w3techplayground@gmail.com> wrote:
>>>>>>
>>>>>>> Is it possible to verify(whitelist) inline script block via checksum
>>>>>>> of its logic(uniform) as alternative to "Nonce"?  ie send checksum of the
>>>>>>> allowed script via header and if inlined script checksum is the same it's
>>>>>>> allowed to execute.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>