W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2013

Re: Content Security Policy

From: Bryan McQuade <bmcquade@google.com>
Date: Mon, 17 Jun 2013 13:56:55 -0400
Message-ID: <CADLGQyC4bvzY5RP1smbdNXPh+yRv2ZSBa0ush1tEgPDHMX-DOQ@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Joel Weinberger <jww@chromium.org>, Yoav Weiss <yoav@yoav.ws>, Neil Matatall <neilm@twitter.com>, Евнгений Яременко <w3techplayground@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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.
Received on Monday, 17 June 2013 17:57:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:33 UTC