Re: Subresource Integrity strawman.

In the case of CDNs, they aren't always under your control. We push
out our assets to Akamai. But in theory they could be compromised or
maliciously alter the contents of our scripts.

On Wed, Jan 8, 2014 at 10:52 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> Hey all. First off, I wouldn't qualify myself as a "security" person, so
> pardon my ignorance... A few high-level questions:
>
>> Authors must trust that the resource their content delivery network
>> delivers is in fact the same resource they expect. If an attacker can trick
>> a user into downloading content from a different server (via DNS poisioning,
>> or other such means), the author has no recourse. Likewise, an attacker who
>> can replace the file on the CDN server has the ability to inject arbitrary
>> content.
>
>
> Isn't this redundant with HTTPS + HSTS? MITM aside, the transport layer
> guarantees data integrity and (pinned) authentication. In light of that,
> does this spec provide anything extra? It seems like it would be much
> simpler to simply recommend using HTTPS + HSTS.
>
>> Provide authors with a mechanism of reducing the ambient authority of a
>> host (e.g. a content delivery network, or a social network that provides
>> widgets) from whom they wish to include JavaScript. Authors should be able
>> to grant authority to load a script, not any script, and compromise of the
>> third-party service should not automatically mean compromise of every site
>> which includes its scripts.
>
>
> Ok, to answer my own question: the extra bit of security is that you're
> effectively freezing a hash and if your pinned host is compromised and file
> is replaced, then UA will bail on execution - right? At which point, if you
> absolutely must have control over the target script, why not just freeze it
> on a local server? Some sites do that exactly that when deploying third
> party widgets / analytics / etc... some for security reasons, others for
> performance.
>
> Further, it seems like in practice the proposed example wouldn't actually
> fly:
> <script src="https://analytics-r-us.com/include.js"
>         integrity="ni:///sha-256;SDfwewFAE...wefjijfE"></script>
>
> The whole point of providing a generic "ga.js" or "include.js" is that it
> can be revved by a third party - e.g. updates and security fix deploys... If
> I add an integrity tag on these resources, I effectively guarantee that my
> site is broken next time analytics-r-us.com revs their JavaScript. Once
> again, it seems like if you must have this control, you're better off
> freezing a local copy on your server, auditing it, and being responsible for
> updating it manually.
>
> Long story short, it seems like this is an unnecessary layer if we assume
> HTTPS is place? Or, am I missing something obvious here? If we assume
> non-HTTPS world, then yeah we're talking about adding an integrity layer,
> but it seems rather clunky/complicated. I'd rather just push people to adopt
> HTTPS?
>
> ig

Received on Wednesday, 8 January 2014 19:00:54 UTC