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;"/>

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
> 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
>

Received on Thursday, 29 November 2012 18:45:46 UTC