W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2014

Re: [Integrity] Comments/Questions on Subresource Integrity spec

From: Brad Hill <hillbrad@gmail.com>
Date: Wed, 9 Apr 2014 13:01:49 -0700
Message-ID: <CAEeYn8ipyR-UhvoDW3Hoyu1JD4K252vwqu0FFtCfuKbOoxy7vg@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
I always hesitate to reply only partially out of fear it will break
the thread, so I encourage others, especially editors, to reply to the
rest of Tanvi's concerns.

But a few thoughts:

> Are there common instances where a resource may not be publicly cachable but wouldn't have any private data or leak information?

I think there are may such instances, but unfortunately we have no way
to positively identify them.  Requiring cache or access control
headers is the only way we've arrived at so far to infer the resource
owner's intent about the privacy properties of a resource.

> Does the noncanonical (fallback) source have to match the integrity check?

I think you've mixed up the understanding of noncanonical vs.
canonical here.  The noncanonical source is the first-attempted, from
potentially a less-trusted source like HTTP or a CDN and it therefore
must match.  A canonical fallback over HTTPS may not have to match, to
avoid problems with, e.g. trusted MITM proxies that rewrite scripts.

> Why fall back to another HTTP source?

Probably a bad idea, agreed, but it may be useful in a report-only
mode to avoid some brittleness as you describe in your last general
question.

And regarding that general question - yes I think it's always been a
concern that this will increase the brittleness of applications, and
that it should be use carefully in well-vetted situations where
counterparties give appropriate assurances, especially at first, and
not sprinkled liberally over links that may be unstable.

-Brad

On Tue, Apr 8, 2014 at 9:43 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:
> Hi,
>
> I was on leave for a few months and away from the webappsec working group.
> I am back now and very pleased to see that we have a FPWD of Subresource
> Integrity!  The spec looks like it's in good shape.  I've missed some of the
> discussions, so forgive me if some of this has already been addressed.  I
> have the following comments and questions on the spec.
>
> 1.1 - Goals
> "2. The verification mechanism should extend to all resource types that a
> page may fetch in the course of its execution and rendering. Active content
> (scripts, style, iframe contents, etc) are, of course, critical, but
> inactive content such as images and fonts will also be covered."
> Here it says that fonts are covered, but I don't see anything about fonts in
> the spec.
>
> "5. (potentially) Relax mixed-content warnings for resources whose integrity
> is verified. If the integrity metadata for a resource is delivered over a
> secure channel, the user agent might choose to allow loading the resource
> over an insecure channel."
> We could allow mixed active content loads that pass an integrity check
> (instead of blocking them) and use the UI for mixed display content in these
> cases (instead of showing the lock).
>
> 2.1 - Key Concepts and Terminology
> "The SHA-256, SHA-384, and SHA-512 are part of the SHA-2 set of
> cryptographic hash functions defined..."
> Looks like SHA-384 isn't used anywhere in the spec.
>
> 3.3.2 - Is resource eligible for integrity validation
> "In order to mitigate an attacker's ability to read data cross-origin by
> brute-forcing values via integrity checks, resources are only eligible for
> such checks if they are same-origin, publicly cachable, or are the result of
> explicit access granted to the loading origin via CORS. [CORS]"
> Was there a discussion that these restrictions came out of?  I understand
> the need for them but am worried if about overly constraining the feature.
> Are there common instances where a resource may not be publicly cachable but
> wouldn't have any private data or leak information?
>
> 3.5 Verification of HTML document subresources
> "...a new integrity attribute is added to the list of content attributes for
> the a, audio, embed, iframe, link, object, script, source, track, and video
> elements."
> images are missing from this list.
>
> 3.5.2 - Noncanonical source
> Does the noncanonical (fallback) source have to match the integrity check?
> * If it does have to match the integrity check - what if it is over HTTPS?
> Does that make a difference or does it have to match either way?  Is there a
> case where we are in block mode (not report mode) and we don't have to match
> the integrity check?  Consider this case - a website includes third party
> javascript over HTTP instead of HTTPS for performance reasons.  The third
> party javascript library is updated and the HTTP version of the file hence
> fails the integrity check.  The site includes the HTTPS version as a
> fallback, but it to will fail the integrity check.  If the integrity check
> wasn't required for an HTTPS fallback, then the site would still function
> and the administrator would be alerted of the issue in the report.
>
> * If it does not have to match the integrity check - what would be the point
> of having a noncanonical source over HTTP?  Should we require it to be
> HTTPS?  If the original HTTP source doesn't match the integrity check, why
> fall back to another HTTP source?  If there is a MITM attack, the MITM can
> alter the fallback as well.  A case where an HTTP noncanonical source might
> be helpful is if there is a third-party server compromise that caused the
> mismatch and the noncanonical source is an HTTP link with the same origin as
> the top level page.
>
> 3.5.4 - Handling integrity violations
> Why have separate block and fallback modes?  If the site didn't want to
> fallback, they wouldn't have included a noncanonical source.
>
> 3.5.5.1 - The a element
> "If subject has an integrity attribute whose value is not the empty string,
> then:..."
> What does subject refer to here?
>
> "If response's integrity state is corrupt and the document's integrity
> policy is block, the user agent MUST report a violation, and MUST abort the
> download."
> This section doesn't say what to do if the document's integrity policy is
> report (while most other sections do).  Perhaps you can add a line here
> stating something like -
> 'If response's integrity state is corrupt and the document's integrity
> policy is report, the user agent MUST report a violation, and can continue
> with the download.'
>
> And finally a general question - what happens when third party resource is
> only available over HTTP and it changes?  If a website requires an integrity
> check for that resource, it will fail until the website views their reports,
> reviews the new code/resource, and updates the hash.  The resource may have
> been necessary for the site to function.  I'm worried that web
> administrators will be too scared to use integrity checks for third parties
> out of fear that the resource will slightly change and break their site.  Is
> there anything we can do to mitigate this risk and increase adoption?
>
> Thanks!
>
> ~Tanvi
>
>
>
Received on Wednesday, 9 April 2014 20:02:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC