RE: [webappsec] ACTION REQUIRED: Call for Consensus on new WebAppSec WG Charter

<hat="individual>

Fred,

  I think this is an area where starting with the smallest possible change that accomplishes something useful is much more important than being ambitious about use cases at the expense of extra complexity.  I think there is very little appetite among browser implementers for re-inventing anything like version control and a robust digital signature scheme as part of the browser's HTTP fetch algorithm.

  It's already possible, too, to provide a reasonable assertion of authorship while allowing transparent updating - that's pretty much what including a resource via HTTPS does today.

-Brad

From: Fred Andrews [mailto:fredandw@live.com]
Sent: Saturday, December 01, 2012 3:47 PM
To: Hill, Brad
Cc: public-webappsec@w3.org
Subject: RE: [webappsec] ACTION REQUIRED: Call for Consensus on new WebAppSec WG Charter

Dear Brad,

Might it be possible to achieve more with this deliverable.

A needed use case is a widget or even just a JS resource that is written by an
author that a user trusts but might be deployed widely on servers controlled by
authors the user is not familiar with and might not have as much trust in.  For
example a library such as jquery, or a social widget, or a payment widget.  These
might even be embedded in the HTML markup using a data URL.

This might share some similarity to some of your use cases.  The 'src' attribute
could be the trusted authors distribution URL and uniquely identify the resource
being trusted, the 'alt-src' attribute might be the deployed server's URL, and
rather than a hash, a signature generated by the trusted author might be used
so that the user could check that the resource is trusted.  It might also be useful
if versions of resource could be managed, but I'm not sure what this would mean
yet, but if a user trusts an author and a new version of a resource is released
then the UA might make it more convenient for the user to accept and transfer
trust, or perhaps even substitute a newer version.  For example if a user visits
a website with version 6 of a social widget and then visits a website with version 5
then perhaps the UA could be smart enough to use the latest - with some flags
on control this.  Perhaps this spec. would work with manifests to keep a set of
resources in sync.

Another option might be to support a server sending the UA certificates of servers
with linked resources that it trusts to help with MitM threats and to support a web
of trust.  UAs are already bundling some as part of HSTS.  If these were sent in
HTTP headers it might be generally accepted.  The user would visit a trusted website
and it could send back certificates of other trusted servers.  Assuming the user
already has the websites certificate to detect a MitM then this also protects against
MitM for linked servers for which the user may not have already had the certificate.

cheers
Fred

> From: bhill@paypal-inc.com<mailto:bhill@paypal-inc.com>
> To: art.barstow@nokia.com<mailto:art.barstow@nokia.com>
> CC: public-webappsec@w3.org<mailto:public-webappsec@w3.org>
> Date: Thu, 29 Nov 2012 18:45:13 +0000
> Subject: RE: [webappsec] ACTION REQUIRED: Call for Consensus on new WebAppSec WG Charter
>
> > To facilitate our internal review regarding the proposed "Sub-Resource
> > Integrity" deliverable, where can I find some additional information (beyond
> > the few sentences in the Draft charter) about this spec, f.ex. a Draft spec,
> > related work, etc.?
> >
> > -Thanks, AB
>
> I've been trying to avoid prejudicing the discussion thus far, especially before we have made any patent commitments, but my personal notes on the idea were the following. Please take this as a hand-wavey hypothetical only indicative of my own speculations. I hope that some of the groups that have been experimentally implementing these ideas will submit their work. The charter language is the definitive scope for the WG's actual deliverable, which might differ considerably from this sketch.
>
> -Brad
> ---------------------
> Somewhat similar to http://www.gerv.net/security/link-fingerprints/ but primarily for subresource loads, rather than just content-disposition: attachment to protect downloaded files.
>
> Use cases:
>
> 1. Resource with cache-friendly alternate, fall back to secure transport on failure:
>
> <link href="https://www.example.com/foo.css" digest="sha256:ab8e92231..." alt-href="http://cdn.example.com/foo.css">
>
> 2. Resource with only one src, implies hard-fail on digest mismatch:
>
> <script src="https://analytics.example.com/measure.js" digest="sha256:ab8e92231...">
>
> 3. Resource with cache-friendly alternate, fallback to secure transport, hard fail if digest mismatch on both:
>
> <script src="https://analytics.example.com/measure.js" digest="sha256:ab8e92231..." alt-src="http://cdn.example.com/measure.js" digest-policy="hardfail">
>
>
> 4. Could possibly have resource-level policy for all link digests as header/meta:
>
> <meta subresource-digest-policy="hardfail|fallback|report-only; report-uri: https://reports.example.com;"/<https://reports.example.com;%22/>>
>
> Digest would be calculated as in RFC 1864 (http://www.ietf.org/rfc/rfc1864.txt) except using SHA256, possibly SHA3 for the algorithm.
>
> Content hashing has been tried before with Digest-MD5 and the OAuth MAC headers and always was a deployment nightmare because of intermediaries that modify content - including "authorized" HTTPS MITMs. Soft-fallback solves some of this, but eliminates the use case of protecting against the resource-swapping, metastatic XSS possible with a compromise at Google Analytics, Omniture, jQuery, or similar. Because of this, we probably want a report only mode, like CSP. Thus deployers could expect a baseline level of noise from twiddling proxies, but can respond if *everyone* starts alerting due to an actual change in the resource at the origin. Can report failure, can't probably report the calculated digest without violating user privacy.
>
> We could also have a mode that allows "honest intermediaries" - that is, trust the transport layer if there is a Content-MD5 header that isn't a match for the actual content. (Per http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html proxies and gateways MUST NOT generate or modify Content-MD5.) Mismatch would indicate a compliant content-modifying proxy (false positive), but allowing to proceed would expose attack branch where a compromised remote server deliberately sends mismatched header. Again, can only report mismatch as a boolean, not calculated or delivered MD5.(and, yes, this creates a fingerprinting signal)
>
> I think to address some of the privacy leakage concerns, we should require the alt-src fetch to be anonymous, per CORS/UMP: no HTTP Auth, Cookies, Referer, Origin, etc. Could go so far as to require that resources so retrieved must declare a Uniform Access Policy via 'Access-Control-Allow-Origin: *', but that would really limit opportunistic deployment.
>
> Still attack scenarios present even in anonymous fetches - such as which tiles of a public map am I looking at, or which products on a shopping site - but TLS with commonly deployed app models don't protect against this today. Arguably better to make devs think about this explicitly than the status quo of false perception of security.
>
> > -----Original Message-----
> > From: Arthur Barstow [mailto:art.barstow@nokia.com]
> > Sent: Thursday, November 29, 2012 4:32 AM
> > To: Hill, Brad
> > Cc: public-webappsec@w3.org<mailto:public-webappsec@w3.org>
> > Subject: Re: [webappsec] ACTION REQUIRED: Call for Consensus on new
> > WebAppSec WG Charter
> >
> > On 11/27/12 5:30 PM, ext Hill, Brad wrote:
> > >
> > > Please take a look at the proposed new "Sub-Resource Integrity"
> > > deliverable and ensure that your organization is willing to continue
> > > to participate with this in scope for your patent licensing obligations.
> > >
> >
> > To facilitate our internal review regarding the proposed "Sub-Resource
> > Integrity" deliverable, where can I find some additional information (beyond
> > the few sentences in the Draft charter) about this spec, f.ex. a Draft spec,
> > related work, etc.?
> >
> > -Thanks, AB
> >
>
>