W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Security use cases for packaging

From: Yan Zhu <yzhu@yahoo-inc.com>
Date: Fri, 30 Jan 2015 06:50:43 +0000 (UTC)
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Ilya Grigorik <igrigorik@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Chris Palmer <palmer@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <1333433917.1739744.1422600643853.JavaMail.yahoo@mail.yahoo.com>

On Thursday, January 29, 2015 6:25 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

>On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
>> A signed manifest-like package description that lists the hash and
>> location of every resource seems fine as long as all the resources are
>> downloaded and verified before running the app. Perhaps this kills
>> some of the performance benefits motivating packaging in the first
>> place. :(
> Why would you need to fetch all the pieces before running the app?
> Consider a manifest includes an integrity check covering resources X, Y,
> and Z, but X is the only bit of code that runs first, and Y and Z aren't

> loaded.> If you can validate the manifest, then you know you only run X if you've
> verified the manifest and X's integrity.  If the user triggers an action
> that requires resource Y, then you fetch it but don't use it unless it
> matches the integrity check.

Say that resource Y is a javascript file that listens for users typing in password fields and shows them a warning if the password is weak. The user verifies and loads the HTML page that includes Y but an attacker then blocks the request to fetch Y, so the user picks a weak password.

My intuition is that most developers think about the security of their app as a whole, not the security of their app minus any-given-subset-of-resources.
Received on Friday, 30 January 2015 06:51:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC