- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Wed, 8 Jan 2014 23:31:19 -0800
- To: Michal Zalewski <lcamtuf@coredump.cx>
- Cc: Mike West <mkwst@google.com>, Mark Nottingham <mnot@mnot.net>, Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Frederik Braun <fbraun@mozilla.com>
I like the idea of unconditionally failing if none of the three conditions are met. Although, presumably, you want the application be able to distinguish this failure from the failure in integrity verification or network error. --dev On 8 January 2014 23:26, Michal Zalewski <lcamtuf@coredump.cx> wrote: >> What is the mitigation that you're agreeing with, Michal? Only performing >> integrity checks on resources delivered with explicitly public cache-control >> or CORS headers? > > Well, Eduardo's take is that we should just require CORS and not dance > around it. Maybe that would work, although it does require explicit > cooperation of the third-party site that hosts a particular download, > has a copy of jQuery, etc. I'd imagine this won't always be painless. > > An alternative would be to unconditionally fail if integrity= is > specified and none of the following three conditions are met: > > 1) The subresource is same-origin with the requestor, > > 2) The subresource is publicly cacheable by proxies (either due to > implicit caching rules, or due to Cache-Control), > > 3) There is a CORS header that explicitly permits this subresource to > be accessed across origins. > > /mz
Received on Thursday, 9 January 2014 07:32:06 UTC