W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2015

Re: [SRI] integrity + login looks broken

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sun, 17 May 2015 01:15:16 -0700
Message-ID: <CAPfop_0e9bmPLcH9q4U1o7Q8DKzxOTvz+yAfJynPK+M+GFS_ow@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi James!

thanks for all the comments!

> In fact, perhaps any response without a 2xx status should be ineligible;
> or restrict it to only 200 (Ok) responses.

I believe any 4xx or 5xx response would fail much earlier with a network
error, right?

> 2. Section 3.4 "Modifications to Fetch" step 4 (handling 401) seems
> disastrous. It breaks a browser's

We are actively discussing that section. Mind jumping over to
https://github.com/w3c/webappsec/issues/238 and adding your input?

3. A web server should be able to specify an integrity value when
> responding with a 3xx redirect. Hopefully this could be specified in a
> future revision , just like section 3.5 says future revisions are likely to
> add integrity to other HTML elements.

Yes, something to consider for future versions of the spec, I think. One
think we should clear in this spec is what to do with redirects. I have
filed https://github.com/w3c/webappsec/issues/357 for tracking.

> 4. Example 1 and example 2 should include a full hash, not have part
> elided with "...".
> 5. Example 1 and example 2 should have different hash values as they are
> for different resources.
> 6. I'm a little surprised to see potentially real domains in examples 1 &
> 2 (site53.cdn.net and analytics-r-us.com) instead of, say "cdn.example.net"
> and "analytics-r-us.example.com".

4-5-6 all seem to be editorial nits. I am happy to consider it if others
feel strongly, particularly if you or anyone else is willing to write a
pull request :)

> 7. Section 3.1 "Integrity metadata" says the format is the same as
> hash-source from CSP2. This is not quite right. hash-source is defined to
> start and end with a single quote. Instead, refer to section 3.6 "The
> integrity attribute" that references hash-algo (not hash-source) from CPS2.

you are right. https://github.com/w3c/webappsec/pull/356/ fixes that.

> 8. The example script "alert('Hello, world.');" in the text of section 3.1
> uses "smart-quotes", characters U+2018 and U+2019 (LEFT and RIGHT SINGLE
> QUOTATION MARK) whereas it is supposed to use ' U+0027 (APOSTROPHE). This
> matters because the bytes are hashed. Cut-n-pasting the example fails. The
> correct U+0027 is used when the script is repeated in the note.

Thanks for spotting this. https://github.com/w3c/webappsec/pull/354

> 9. The examples in section 3.2.1 "Agility" have the wrong hash values.
> They should match section 3.1 where the example script "alert('Hello,
> world.');" is mentioned. Instead, 3.2.1 hashes the 13 characters "Hello,
> world." despite supposedly being the content of a javascript file
> hello_world.js.
thanks! https://github.com/w3c/webappsec/pull/355 fixes this

> 10. Options in hash-with-options at first glance look like they use the
> well known URI query parameter syntax (?name=value&name=value). For
> instance, you might expect the following to be a valid integrity value:

> 11. The character restrictions on option-value look quite arbitrary. Where
> did the subset of 16

For this and other reasons, we have decided not to spec that part and
updated it to just be VCHAR.

I think this resolves both #10, #11, right?

Thanks again for the detailed feedback.

Received on Sunday, 17 May 2015 08:16:05 UTC

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